Cómo conservar la identidad de la copia de seguridad de Time Machine antes de cambiar el nombre o reconstruir un recurso compartido NAS
Time Machine tiene menos probabilidades de abandonar un historial existente en el NAS cuando se conserva la identidad de la copia de seguridad del recurso compartido antes de cambiarle el nombre, reconstruirlo o migrarlo.
Un destino de Time Machine en red es más que una carpeta que contiene un sparsebundle. El Mac también puede depender del volumen de red anunciado, las capacidades SMB, la ruta del recurso compartido, las credenciales y un identificador de volumen del servicio. Antes de cambiar el NAS, captura esas señales de identidad y protege el sparsebundle existente. Después, reconstruye o cambia el nombre de una capa a la vez y verifica que el Mac siga reconociendo el destino previsto antes de permitir que comience una nueva copia de seguridad.
Registra el destino de red actual antes del mantenimiento
Guarda el nombre de host del NAS, la dirección SMB, el nombre del recurso compartido, la cuenta, el destino de Time Machine seleccionado, el nombre del sparsebundle y el tamaño actual de la copia de seguridad. Registra también cómo se descubre el recurso compartido, por ejemplo, mediante un anuncio de Bonjour o una ruta SMB montada manualmente.
Apple explica que un disco de Time Machine en red se selecciona como destino de red, no es simplemente cualquier carpeta que contenga archivos de copia de seguridad.
Realiza una instantánea del NAS o una copia independiente del sparsebundle antes de modificar la definición del recurso compartido. Esto te proporciona un punto de restauración si el servicio reconstruido crea otra identidad de destino o el Mac comienza un historial nuevo.
Conserva el UUID del volumen de Time Machine cuando el NAS lo admita
Si el NAS expone un UUID de volumen de Time Machine o un identificador persistente similar, regístralo antes de eliminar o volver a crear el recurso compartido SMB. No des por hecho que el mismo nombre visible del recurso compartido generará la misma identidad.
TrueNAS documenta que su UUID de Time Machine identifica el volumen, y que crear o actualizar un recurso compartido con un valor nulo puede generar un UUID nuevo.
Restaura el identificador anterior solo cuando el recurso compartido reconstruido represente realmente el mismo destino de copia de seguridad y la instancia anterior del servidor ya no esté activa. Duplicar un UUID en dos destinos activos crea su propia ambigüedad.
Mantén activada la capacidad SMB de Time Machine en el recurso compartido reconstruido
Volver a crear un recurso compartido SMB normal en la misma ruta del sistema de archivos no es suficiente. Confirma que el recurso compartido reconstruido siga anunciando compatibilidad con Time Machine y las extensiones SMB de Apple que espera el Mac.
El módulo vfs_fruit de Samba indica que la compatibilidad con Time Machine se anuncia mediante la capacidad FULLSYNC del recurso compartido y el registro mDNS cuando es compatible.
Compara la configuración antigua y la nueva del recurso compartido de Samba o del NAS antes de volver a conectar el Mac. Si la capacidad ha cambiado, corrige primero la presentación del servidor en lugar de eliminar o cambiar el nombre del sparsebundle.
No reutilices un identificador de volumen sin pensarlo
Un identificador de volumen de red conservado solo es útil cuando hace referencia al mismo destino lógico de copia de seguridad. Si clonas el recurso compartido antiguo en un segundo NAS activo, ambos servidores no deben fingir que son exactamente el mismo volumen de Time Machine.
Netatalk advierte que su UUID de volumen proporciona una desambiguación sólida y no debe editarse ni copiarse irreflexivamente en otro servidor.
Durante la migración, mantén un solo destino como autoridad en cada momento. Pon en línea el reemplazo con la identidad conservada solo después de que el servicio anterior esté desconectado y se haya completado la copia del sparsebundle.
Conserva Bonjour y la selección del recurso compartido durante el cambio
Registra qué carpeta compartida está designada explícitamente para Time Machine y si Bonjour anuncia esa carpeta. Después de reconstruir el NAS, verifica que se publique la misma carpeta antes de volver a seleccionarla en el Mac.
Las instrucciones actuales de Synology exigen que los administradores establezcan la carpeta de Time Machine y activen la difusión de Time Machine mediante Bonjour al utilizar esa ruta de descubrimiento.
Si es necesario cambiar el nombre de host del NAS, demuestra primero que se puede acceder al recurso compartido previsto mediante su nueva ruta SMB y que todavía contiene el sparsebundle protegido. No permitas que un recurso compartido de reemplazo vacío sea el primer destino que vea el Mac.
Prueba el historial existente antes de reanudar las copias de seguridad automáticas
Con las copias de seguridad automáticas pausadas, vuelve a conectarte al destino reconstruido, confirma que el sparsebundle antiguo sea visible y explora o restaura un archivo conocido del historial anterior. Observa el recurso compartido para comprobar si se crea un segundo sparsebundle durante la primera copia de seguridad controlada.
ASUSTOR recomienda SMB para las copias de seguridad de Time Machine en los sistemas NAS compatibles, lo que refuerza que la presentación SMB específica de Time Machine del servidor forma parte del destino.
El mantenimiento finaliza cuando Time Machine añade datos al historial existente y no aparece un segundo paquete. El artículo relacionado de ZimaSpace sobre un nuevo sparsebundle de Time Machine es la vía de recuperación si no se conservó la identidad y el Mac ya ha iniciado una nueva copia de seguridad.
Preguntas frecuentes
¿Basta con conservar el mismo nombre del recurso compartido SMB?
No. El nombre visible es solo una señal. El NAS puede volver a crear el recurso compartido con una capacidad de Time Machine, una publicidad del servicio, unas credenciales o una identidad de volumen diferentes.
¿Debo cambiar el nombre del sparsebundle existente para que coincida con el NAS reconstruido?
No como medida preventiva. Conserva primero el paquete y mantén estable la identidad del destino; cambiar el nombre de la imagen no actualiza automáticamente las relaciones que utiliza Time Machine.
¿Puedo probar el recurso compartido reconstruido mientras el servidor antiguo de Time Machine sigue activo?
Ten cuidado. Dos destinos activos que presenten la misma identidad lógica pueden confundir el descubrimiento y dificultar saber qué sparsebundle se está actualizando. Es preferible realizar un cambio controlado con un solo servidor como autoridad.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
