Comment forcer une traversée profonde de Time Machine?

Après quelques paniques du noyau et un débranchement à chaud accidentel de mon disque Firewire Time Machine, je voudrais m'assurer que ma Time Machine correspond exactement à mon Macintosh HD, un peu comme rsync -a. Existe-t-il un moyen de forcer Time Machine à effectuer une traversée profonde pour vérifier que la sauvegarde correspond?

Il serait utile de savoir comment le faire sur Leopard, Snow Leopard et Lion.

Définir la destination Time Machine sur rien puis la réinitialiser au même endroit qu'avant me force à traverser profondément. Vous pouvez essayer de redémarrer entre le changement de destination et son ajout pour augmenter les chances de déclenchement d'une traversée profonde.

Dans le pire des cas, nous pourrions fouiner en mode mono-utilisateur pour détruire le répertoire fseventsd à un moment sûr lorsque le système ne compte pas sur lui pour être correct, vous avez donc forcé une nouvelle base de données qui ne correspondra pas. Vous pouvez probablement supprimer cela du côté TM, mais je supprimerais la copie de démarrage comme étant légèrement plus sûre et moins susceptible de détruire les données dont vous avez besoin ou de gâcher votre sauvegarde.

Si vous êtes enclin à utiliser la ligne de commande / le terminal, je commencerais tmutil compareavant même de penser à forcer une traversée profonde. Il compare explicitement les choses telles qu'elles existent maintenant au dernier instantané et vous pouvez forcer les choses en spécifiant un instantané externe spécifique si vous avez peur qu'un instantané local soit comparé.

Le démarrage en mode mono-utilisateur peut provoquer une traversée profonde. Il l'a fait pour moi une fois, mais pas après. La suppression de /.fseventsd le sera certainement. Cela devrait être sûr de le faire en mode mono-utilisateur. La suppression de /.fseventd sur le volume de sauvegarde n'a pas déclenché de traversée profonde pour moi. (Mon système a continué comme d'habitude et ne l'a même jamais recréé.)

tmutil comparen'est que quelque peu précis. Il semblait identifier avec précision les fichiers qui n'avaient pas été sauvegardés au début. J'ai déclenché une traversée profonde pour corriger cela, mais Time Machine ne sauvegarde toujours pas de nombreux fichiers. Pourtant, tmutil compareaffirme maintenant qu'il n'y a pas de problème. Je ferais confiance:

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

Utilisez /Volumes/<your time machine volume>/Backups.backupdb/<your machine name>/Latest/comme chemin source ou destination. --itemize-changesnous permet de voir ce qui est différent; '--checksum' indique rsyncde comparer réellement le contenu du fichier, plutôt que simplement les temps de modification et la taille du fichier; et --dry-runindique à rsync de ne pas réellement sauvegarder (donc il nous dit simplement ce qu'il ferait). Les autres arguments sont des indicateurs indiquant à rsync de rendre la destination identique à la source dans tous les sens, y compris les métadonnées et l'état de compression HFS. Je pense que Time Machine ajoute des métadonnées de comptabilité qu'il supprime lors de la restauration, il rsyncpeut donc y avoir de faux changements de métadonnées.

Réponse courte pour au moins macOS 10.13.6:

1. Supprimez toute sauvegarde .inProgress du volume de sauvegarde. Cela peut nécessiter une utilisation root de /bin/rm -rfdonc procédez avec prudence .

2. Utilisez la tmutil associatediskcommande pour relier le volume de sauvegarde au volume principal. Par exemple:

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

Démarrez ensuite une sauvegarde à partir de l'élément de menu Time Machine. Dans mon cas, au lieu de terminer l'analyse en 10 minutes (clairement pas une analyse complète) et d'afficher un téraoctet à sauvegarder, l'analyse a pris plus de 30 et la taille de la sauvegarde correspondait à ce qui tmutil compareavait été dit.

Contexte:

J'avais besoin de forcer une traversée en profondeur / une analyse complète après qu'un programme d'installation malhonnête (Reallusion) ait modifié les autorisations sur tout dans "/ Users / Shared" (environ 1 téraoctet de fichiers autrement non modifiés). Je les ai tous modifiés en arrière et j'ai tmutilconfirmé que Time Machine n'avait plus besoin de sauvegarder ces fichiers, mais l'un des deux disques de sauvegarde a insisté pour utiliser une analyse en cache qui l'a dit.

Choses qui n'ont pas fonctionné:

• Supprimer et rajouter le volume de sauvegarde des préférences système

• Effacement /.fseventsd

• Installation d'une mise à jour système

• Suppression de la sauvegarde .inProgress sans exécution tmutil associated disk

• Exécution tmutil associated disksans supprimer .inProgress

• Démarrage en mode mono-utilisateur, montage / en lecture-écriture et toucher un fichier

Dans la plupart des cas, les journaux de backupd prétendent effectuer une traversée profonde, mais ne prennent que quelques minutes, puis essaient de tout sauvegarder. Voici la commande pour surveiller en backupddirect sur 10.13 plus tard:

flux de journaux --style syslog --predicate 'senderImagePath contient [cd] "TimeMachine"' --info

Cela ne montrera que de nouveaux événements. Pour les journaux des trois derniers jours:

log show --style syslog --predicate 'senderImagePath contient [cd] "TimeMachine"' --info --last 3d