Cómo comprobar si Time Machine continúa o recrea el historial de copias de seguridad

Puedes verificar la continuidad comprobando la identidad del destino, el historial de copias de seguridad heredado, la lista de instantáneas recientes y si la primera ejecución nueva se comporta como una transferencia incremental o completa.

La decisión es importante cuando un Mac se vuelve a conectar a un NAS después de una migración, un cambio de nombre del recurso compartido, un cambio de credenciales o una reparación de sparsebundle. Los dos estados que compiten son que el historial existente se hereda y se amplía, y que se está creando un nuevo conjunto de copias de seguridad junto al antiguo. Comienza con una configuración guardada y datos desechables, observa una rama cada vez y detente si la prueba aumenta el riesgo de pérdida de datos, permisos o disponibilidad.

Define las condiciones detrás de la decisión sobre la continuidad del historial de Time Machine

Registra el entorno antes de cambiar nada: versiones de software y firmware, identidades de los dispositivos, ruta de montaje o red, espacio libre, permisos y síntoma observable. La línea base debe conservar suficiente detalle para reproducir una reconexión de un Mac a un NAS después de una migración, un cambio de nombre del recurso compartido, un cambio de credenciales o una reparación de sparsebundle.

La primera posibilidad es que el historial existente se herede y se amplíe. La segunda es que se esté creando un nuevo conjunto de copias de seguridad junto al antiguo. La comprobación de destinos de tmutil actual define el mecanismo o límite de comandos utilizado en la prueba; no sustituye la observación de este servidor doméstico específico.

Escribe la condición de aceptación y la condición de parada antes de ejecutar el discriminador. Una prueba superada debe cambiar la evidencia que predice una de las ramas, dejando sin cambios los servicios no relacionados; una prueba fallida debe devolver el sistema al estado guardado en lugar de desencadenar una cadena de correcciones especulativas.

Prueba la afirmación sin reducir el requisito original

Usa este discriminador: inspecciona el destino y el historial de instantáneas de tmutil, y después inicia una copia de seguridad controlada mientras supervisas el tamaño transferido y el paquete de destino. Mantén constantes la carga de trabajo, el cliente, la ruta, el conjunto de archivos y el momento, para que el resultado pueda atribuirse a la variable modificada.

Usa los destinos de Time Machine para seleccionar el campo que realmente pueda separar las ramas y captura su marca de tiempo, estado de salida, texto de error, identidad del dispositivo o de la instantánea, latencia, bytes transferidos, permisos y estado de recuperación. Un comando que finaliza correctamente no basta cuando la identidad, la durabilidad o el estado de la aplicación son la afirmación que se está probando.

Repite la prueba una vez después de un reinicio, una reconexión, un nuevo montaje o una caché fría cuando ese evento forme parte de la condición original. Si la primera ejecución es destructiva o el entorno no puede restaurarse, detente y reprodúcela en una copia desechable.

tmutil destinationinfo
tmutil listbackups
tmutil status

Interpreta los resultados de prueba superada, fallida y excepcional

APROBADA: las nuevas instantáneas locales se adjuntan al destino esperado y la ejecución transfiere solo los datos modificados. Registra la versión exacta, la identidad y la carga de trabajo que dieron resultado para que la conclusión siga siendo condicional en lugar de convertirse en una afirmación universal.

FALLIDA: aparece un nuevo sparsebundle, falta el historial o el tamaño transferido se aproxima a una línea base completa. Un fallo no demuestra automáticamente la rama opuesta cuando la red, la memoria, los permisos o la coherencia del origen pueden influir en ambas; aísla esas dependencias compartidas antes de escalar.

EXCEPCIÓN O RESULTADO AMBIGUO: detén la ejecución antes de que ambos historiales consuman la cuota y restaura la identidad de destino anterior. Conserva los registros y no ejecutes comandos de reparación, depuración, destrucción, reparticionado o cambio recursivo de propietario hasta que exista una copia recuperable.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Confirma la decisión con la carga de trabajo original

Aplica la acción correspondiente a la rama observada y después repite la condición original, no un sustituto reducido. La decisión solo se mantiene cuando las nuevas instantáneas locales se adjuntan al destino esperado y la ejecución transfiere únicamente los datos modificados durante dos ciclos o durante el reinicio, reposo, interrupción o transición de carga pertinente.

Usa las cuotas de Time Machine para comprobar el flujo de trabajo dependiente más cercano, pero mantén sin cambios el desencadenante original. Los conjuntos de datos, recursos compartidos, contenedores, usuarios y puntos de recuperación no relacionados deben conservar su acceso y sus tiempos anteriores.

El límite de parada es explícito: si aparece un nuevo sparsebundle, falta el historial o el tamaño transferido se aproxima a una línea base completa, vuelve a la última configuración verificada, conserva las pruebas y escala a una prueba más profunda de la plataforma o el hardware solo cuando la rama pueda reproducirse.

Cuando se mantenga el resultado objetivo, compáralo con la verificación de restauración para asegurarte de que la solución no traslada el riesgo a un servicio vecino. Una prueba objetivo superada con una copia de seguridad, identidad, tiempo de espera o fallo de disponibilidad nuevos sigue siendo un cambio fallido.

Preguntas frecuentes

En cuanto a la continuidad del historial de Time Machine, las búsquedas restantes suelen centrarse en si una primera ejecución grande siempre significa que se perdió el historial, si dos sparsebundles pueden tener nombres similares y si debe eliminarse el paquete antiguo después de que comience una nueva copia de seguridad. Las respuestas siguientes mantienen esos casos límite separados de la decisión principal.

El límite de aceptación no cambia: las nuevas instantáneas locales se adjuntan al destino esperado y la ejecución transfiere solo los datos modificados. Si una condición posterior cambia el sistema de archivos, la identidad, la ruta de red o la versión de la aplicación, repite únicamente el discriminador afectado por ese cambio.

Deja de ampliar el experimento cuando aparezca un nuevo sparsebundle, falte el historial o el tamaño transferido se aproxime a una línea base completa. En ese momento, detén la ejecución antes de que ambos historiales consuman la cuota y restaura la identidad de destino anterior; conserva las pruebas antes de escalar al responsable de la plataforma, el almacenamiento o el hardware.

¿Una primera ejecución grande siempre significa que se perdió el historial?

No. Las actualizaciones del sistema operativo, las exclusiones, los cambios del sistema de archivos o los intervalos prolongados pueden generar incrementales grandes; inspecciona la identidad del destino y la genealogía de las instantáneas.

¿Pueden dos sparsebundles tener nombres similares?

Sí. Usa la identidad de la máquina y los metadatos del destino, no solo el nombre del archivo.

¿Debe eliminarse el paquete antiguo después de que comience una nueva copia de seguridad?

No, hasta que se haya demostrado la continuidad o el nuevo historial completo haya superado una prueba de restauración.

En cuanto a la continuidad del historial de Time Machine, la respuesta práctica sigue siendo condicional: las nuevas instantáneas locales se adjuntan al destino esperado y la ejecución transfiere solo los datos modificados. Cuando aparezca un nuevo sparsebundle, falte el historial o el tamaño transferido se aproxime a una línea base completa, detén la ejecución antes de que ambos historiales consuman la cuota y restaura la identidad de destino anterior; un éxito parcial que no pueda soportar la carga de trabajo original no es compatibilidad.