¿Cómo forzar un recorrido profundo de Time Machine?

11

Después de algunos errores del kernel y un desenchufado en caliente accidental de mi unidad Firewire Time Machine, me gustaría asegurarme de que mi Time Machine coincida exactamente con mi Macintosh HD, como rsync -a . ¿Hay alguna manera de forzar a Time Machine a hacer un recorrido profundo para verificar que la copia de seguridad coincida?

Sería útil saber cómo hacer esto en Leopard, Snow Leopard y Lion.

    
pregunta Blair Zajac 14.03.2012 - 06:54

2 respuestas

7

Configurar el destino de Time Machine a nada y luego volver a configurarlo en la misma ubicación que antes me obliga a realizar un recorrido profundo. Puede intentar reiniciar entre cambiar el destino y volver a agregarlo para aumentar la posibilidad de que se active un recorrido profundo.

En el peor de los casos, podríamos revolver en modo de usuario único para destruir el directorio fseventsd en un momento seguro cuando el sistema no cuente con que sea correcto, por lo que ha forzado una nueva base de datos que no coincidirá. Probablemente podría eliminar esto del lado de la TM, pero eliminaría la copia de inicio por ser un poco más segura y menos propensa a destruir los datos que necesita o arruinar su copia de seguridad.

Si estás inclinado a usar la línea de comandos / terminal, comenzaría con tmutil compare antes de que fueras a forzar un recorrido profundo. Compara explícitamente las cosas como existen ahora con la última instantánea y puede forzarlas especificando una instantánea externa específica si le preocupa que se compare una instantánea local.

    
respondido por el bmike 29.05.2012 - 19:28
1

El arranque en modo de un solo usuario puede causar un recorrido profundo. Lo hizo por mí una vez, pero no en los siguientes. Eliminar /.fseventsd definitivamente lo hará. Debería ser seguro hacerlo en modo de usuario único. Eliminar /.fseventd en el volumen backup no provocó un recorrido profundo para mí. (Mi sistema continuó de forma normal y nunca lo volvió a crear).

tmutil compare es solo un poco exacto. Parecía identificar con precisión los archivos que no fueron respaldados al principio. Desencadené un recorrido profundo para corregir esto, pero Time Machine todavía no hace copias de seguridad de muchos archivos. Sin embargo, tmutil compare ahora afirma que no hay un problema. Yo confiaría:

rsync --dry-run --itemize-changes --checksum --protect-args -aNHAXx --protect-decmpfs --fileflags --force-change --delete path/to/source_dir/ path/to/destination_dir/

Use /Volumes/<your time machine volume>/Backups.backupdb/<your machine name>/Latest/ como la ruta de origen o de destino. --itemize-changes nos permite ver qué es diferente; '--checksum' le dice a rsync que compare los contenidos del archivo, en lugar de solo los tiempos de modificación y el tamaño del archivo; y --dry-run le dice a rsync que no haga copias de seguridad (así que solo nos dice lo que haría). El resto de los argumentos son indicadores que le dicen a rsync que haga que el destino sea idéntico al origen en todos los aspectos, incluidos los metadatos y el estado de compresión HFS. Creo que Time Machine agrega metadatos de contabilidad que elimina cuando se restaura, por lo que rsync puede encontrar cambios de metadatos falsos.

    
respondido por el yig 29.01.2015 - 03:26

Lea otras preguntas en las etiquetas