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

Después de algunos pánicos del kernel y una desconexión accidental accidental de mi unidad Firewire Time Machine, me gustaría asegurarme de que mi Time Machine coincida exactamente con mi Macintosh HD, al igual que rsync -a. ¿Hay alguna manera de obligar a Time Machine a hacer un recorrido profundo para verificar que la copia de seguridad coincida?

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

Establecer el destino de Time Machine en nada y luego volver a configurarlo en la misma ubicación que antes me obliga a 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 entrometerse en modo de usuario único para destruir el directorio fseventsd en un momento seguro cuando el sistema no cuenta con que sea correcto, por lo que ha forzado una nueva base de datos que no coincidirá. Probablemente podría eliminar esto del lado TM, pero eliminaría la copia de arranque como marginalmente más segura y menos propensa a destruir los datos que necesita o arruinar su copia de seguridad.

Si está dispuesto a usar la línea de comando / terminal, comenzaría tmutil compareantes de que usted siquiera piense en forzar un recorrido profundo. Compara explícitamente las cosas tal 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.

El arranque en modo de usuario único puede causar un recorrido profundo. Lo hizo por mí una vez, pero no en otras. Eliminar /.fseventsd definitivamente lo hará. Debería ser seguro hacer esto en modo de usuario único. Eliminar /.fseventd en el volumen de copia de seguridad no provocó un recorrido profundo para mí. (Mi sistema continuó como siempre y nunca lo volví a crear).

tmutil compareEs solo algo preciso. Parecía identificar con precisión los archivos que no estaban respaldados al principio. Activé un recorrido profundo para corregir esto, pero Time Machine todavía no está haciendo copias de seguridad de muchos archivos. Sin embargo, tmutil compareahora afirma que no hay problema. Confiaría en:

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

Úselo /Volumes/<your time machine volume>/Backups.backupdb/<your machine name>/Latest/como la ruta de origen o de destino. --itemize-changesveamos qué es diferente; '--checksum' le dice rsynca comparar el contenido del archivo, en lugar de solo los tiempos de modificación y el tamaño del archivo; y --dry-runle dice a rsync que no haga una copia de seguridad (así que solo nos dice qué 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 sentidos, incluidos los metadatos y el estado de compresión HFS. Creo que Time Machine agrega metadatos de contabilidad que elimina al restaurar, por lo que rsyncpuede encontrar cambios de metadatos espurios.

Respuesta corta para al menos macOS 10.13.6:

1. Elimine cualquier copia de seguridad .inProgress del volumen de la copia de seguridad. Esto puede requerir el uso de root, /bin/rm -rfasí que proceda con precaución .

2. Use el tmutil associatediskcomando para volver a vincular el volumen de respaldo al volumen principal. Por ejemplo:

sudo tmutil Associatedisk -a / "/ Volumes / Time Machine Backups / Backups.backupdb / Macintosh HD / Latest / Macintosh HD"

Luego, inicie una copia de seguridad desde el elemento del menú Time Machine. En mi caso, en lugar de terminar el escaneo en 10 minutos (claramente no es un escaneo completo) y mostrar un terabyte de respaldo, el escaneo tomó más de 30 y el tamaño de respaldo coincidió con lo que tmutil comparehabía estado diciendo.

Antecedentes:

Necesitaba forzar una exploración profunda / transversal completa después de que un instalador no autorizado (Reallusion) cambiara los permisos de todo en "/ Usuarios / Compartidos" (aproximadamente 1 terabyte de archivos no modificados). Volví a cambiarlos todos y tmutilconfirme que la máquina del tiempo ya no necesitaba hacer una copia de seguridad de esos archivos, pero uno de los dos discos de copia de seguridad insistió en usar un escaneo en caché que decía que sí.

Cosas que no funcionaron:

• Eliminar y volver a agregar el volumen de respaldo de las preferencias del sistema

• Borrar /.fseventsd

• Instalar una actualización del sistema

• Eliminar la copia de seguridad .inProgress sin ejecutar tmutil associated disk

• Ejecutar tmutil associated disksin eliminar .inProgress

• Arrancar en modo de usuario único, montar / como lectura-escritura y tocar un archivo

En la mayoría de los casos, los registros respaldados afirmarían estar haciendo un recorrido profundo, pero tomarían solo unos minutos y luego intentarían hacer una copia de seguridad de todo. Aquí está el comando para monitorear en backupdvivo el 10.13 en adelante:

secuencia de registro --style syslog --predicate 'senderImagePath contiene [cd] "TimeMachine"' --info

Eso solo mostrará nuevos eventos. Para registros de los últimos tres días:

log show --style syslog --predicate 'senderImagePath contiene [cd] "TimeMachine"' --info --última 3d