Après quelques paniques du noyau et un débranchement à chaud accidentel de mon disque Firewire Time Machine, j'aimerais m'assurer que mon Time Machine corresponde exactement à mon disque dur Macintosh, un peu comme rsync -a . Existe-t-il un moyen de forcer Time Machine à effectuer une traversée en profondeur pour vérifier que la sauvegarde correspond ?
Savoir comment faire cela sur Leopard, Snow Leopard et Lion serait utile.
Le fait de ne pas définir la destination Time Machine, puis de la redéfinir au même endroit qu'auparavant, me force à effectuer une traversée en profondeur. Vous pouvez essayer de redémarrer entre le changement de destination et le réajout de celle-ci pour augmenter les chances de déclencher une traversée profonde.
Dans le pire des cas, nous pourrions intervenir en mode mono-utilisateur pour détruire le répertoire fseventsd à un moment sûr où le système ne compte pas sur lui pour être correct, ainsi vous avez forcé une nouvelle base de données qui ne correspondra pas. Vous pourriez vraisemblablement supprimer cela du côté TM, mais je supprimerais la copie de démarrage car elle est marginalement plus sûre et moins susceptible de détruire les données dont vous avez besoin ou d'endommager votre sauvegarde.
Si vous êtes enclin à utiliser la ligne de commande / le terminal, je commencerais avec tmutil compare avant 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 êtes inquiet qu'un instantané local soit comparé.
Le démarrage en mode mono-utilisateur peut provoquer une traversée profonde. Cela a été le cas pour moi une fois, mais pas les fois suivantes. Supprimer /.fseventsd le fera certainement. Il devrait être sûr de le faire en mode mono-utilisateur. La suppression de /.fseventd sur le système d'exploitation sauvegarde Le volume n'a pas déclenché de traversée profonde pour moi. (Mon système a continué comme si de rien n'était et ne l'a même pas recréé).
tmutil compare n'est que peu précis. Il semblait identifier avec précision les fichiers qui n'étaient pas sauvegardés au départ. J'ai déclenché une traversée profonde pour corriger cela, mais Time Machine ne sauvegarde toujours pas de nombreux fichiers. Pourtant, tmutil compare prétend 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 d'accès source ou destination. --itemize-changes nous permet de voir ce qui est différent ; '--checksum' nous indique rsync de comparer réellement le contenu des fichiers, plutôt que de se limiter aux heures de modification et à la taille des fichiers ; et --dry-run indique à rsync de ne pas faire de sauvegarde (donc il nous dit juste ce qu'il ferait). Le reste des arguments sont des drapeaux indiquant à rsync de rendre la destination identique à la source en tous points, y compris les métadonnées et le statut de compression HFS. Je crois que Time Machine ajoute des métadonnées de gestion qu'il supprime lors de la restauration. rsync peut trouver de faux changements de métadonnées.
Réponse courte pour au moins MacOS 10.13.6 :
Supprimez toute sauvegarde .inProgress du volume de sauvegarde. Cela peut nécessiter l'utilisation de Root /bin/rm -rf donc procéder à attention .
Utilisez le tmutil associatedisk pour lier à nouveau le volume de sauvegarde au volume principal. Par exemple :
sudo tmutil associatedisk -a / "/Volumes/Time Machine Backups/Backups.backupdb/Macintosh HD/Latest/Macintosh HD"
Ensuite, lancez une sauvegarde à partir de l'élément de menu Time Machine. Dans mon cas, au lieu de terminer l'analyse en 10 minutes (ce qui n'est clairement pas une analyse complète) et d'afficher un téraoctet à sauvegarder, l'analyse a pris plus de 30 minutes et la taille de la sauvegarde correspondait à ce que j'avais indiqué. tmutil compare avait dit.
Le contexte :
J'avais besoin de forcer une traversée en profondeur / un scan complet après qu'un installateur malveillant (Reallusion) ait changé les permissions sur tout ce qui se trouvait dans "/Users/Shared" (environ 1 terabyte de fichiers non modifiés). Je les ai toutes rétablies, et tmutil a confirmé que Time Machine n'avait plus besoin de sauvegarder ces fichiers, mais l'un des deux disques de sauvegarde insistait pour utiliser une analyse en cache qui disait le contraire.
Les choses qui n'a pas travail :
Suppression et réinsertion du volume de sauvegarde dans les préférences système
Effacement de /.fseventsd
Installation d'une mise à jour du système
Suppression de la sauvegarde .inProgress sans exécution tmutil associated disk
Running tmutil associated disk sans supprimer .inProgress
Démarrer en mode mono-utilisateur, monter / en lecture-écriture, et toucher un fichier
Dans la plupart des cas, les journaux de backupd prétendent effectuer une traversée en profondeur, mais ne prennent que quelques minutes et essaient ensuite de tout sauvegarder. Voici la commande à surveiller backupd en direct le 10.13 à plus tard :
log stream --style syslog --predicate 'senderImagePath contains[cd] "TimeMachine"' --info
Cela ne montrera que nouveau événements. Aux journaux des trois derniers jours :
log show --style syslog --predicate 'senderImagePath contains[cd] "TimeMachine"' --info --last 3d
LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.
