Nach einigen Kernel-Paniken und einem versehentlichen Hot-Unplugging meines Firewire Time Machine-Laufwerks möchte ich sicherstellen, dass meine Time Machine genau mit meiner Macintosh HD übereinstimmt, ähnlich wie rsync -a. Gibt es eine Möglichkeit, Time Machine zu zwingen, eine tiefe Traversierung durchzuführen, um zu überprüfen, ob die Sicherung übereinstimmt?
Es wäre hilfreich zu wissen, wie man dies bei Leopard, Snow Leopard und Lion macht.
Das Setzen des Time Machine-Ziels auf nichts und das erneute Setzen auf den gleichen Ort wie zuvor erzwingt für mich eine tiefe Durchquerung. Sie können versuchen, zwischen dem Ändern des Ziels und dem erneuten Hinzufügen einen Neustart durchzuführen, um die Wahrscheinlichkeit zu erhöhen, dass eine Deep Traversal ausgelöst wird.
Im schlimmsten Fall könnten wir im Einzelbenutzermodus herumalbern, um das fseventsd-Verzeichnis zu einem sicheren Zeitpunkt zu zerstören, wenn das System nicht damit rechnet, dass es korrekt ist, sodass Sie eine neue Datenbank erzwungen haben, die nicht passt. Sie könnten dies vermutlich von der TM-Seite löschen, aber ich würde die Boot-Kopie entfernen, da sie geringfügig sicherer und weniger anfällig dafür ist, benötigte Daten zu zerstören oder Ihr Backup durcheinander zu bringen.
Wenn Sie dazu neigen, die Befehlszeile / das Terminal zu verwenden, würde ich damit beginnen, tmutil comparebevor Sie überhaupt daran denken, eine tiefe Traversierung zu erzwingen. Es vergleicht Dinge, wie sie jetzt existieren, explizit mit dem letzten Snapshot, und Sie können Dinge erzwingen, indem Sie einen bestimmten externen Snapshot angeben, wenn Sie sich Sorgen darüber machen, dass ein lokaler Snapshot verglichen wird.
tmutil setdestinationerfordert einen Pfad als Argument, nicht wahr? (Oder ich schätze, wählen Sie einfach die Backup-Festplatte aus und klicken Sie dann auf „Festplatte entfernen“, um sie abzuwählen?) Ich stecke in einer schrecklichen Situation fest. Time Machine erstellt ein neues Backup, wenn ich versuche, ein Backup zu erstellen (ich breche es ab, bevor es meine alten Backups löscht), also möchte ich es zwingen, eine tiefgreifende Traversierung durchzuführen, damit es sieht, dass sich die meisten Dateien seit dem letzten nicht geändert haben Sicherung.Das Booten im Einzelbenutzermodus kann zu einer tiefen Traversierung führen. Bei mir hat es einmal funktioniert, aber später nicht mehr. Das Löschen von /.fseventsd wird es definitiv tun. Dies sollte im Einzelbenutzermodus sicher sein. Das Löschen von /.fseventd auf dem Backup- Volume hat bei mir keine Deep Traversal ausgelöst. (Mein System lief ganz normal weiter und hat es nicht einmal neu erstellt.)
tmutil compareist nur bedingt zutreffend. Es schien Dateien, die zunächst nicht gesichert wurden, genau zu identifizieren. Ich habe eine Tiefentraversierung ausgelöst, um dies zu korrigieren, aber Time Machine sichert immer noch nicht viele Dateien. Doch tmutil comparejetzt behauptet, dass es kein Problem gibt. Ich würde vertrauen:
rsync --dry-run --itemize-changes --checksum --protect-args -aNHAXx --protect-decmpfs --fileflags --force-change --delete path/to/source_dir/ path/to/destination_dir/
Verwenden Sie ihn /Volumes/<your time machine volume>/Backups.backupdb/<your machine name>/Latest/entweder als Quell- oder als Zielpfad. --itemize-changeslässt uns sehen, was anders ist; '--checksum' weist rsyncdarauf hin, dass Dateiinhalte tatsächlich verglichen werden sollen, anstatt nur Änderungszeiten und Dateigröße; und --dry-runweist rsync an, nicht tatsächlich zu sichern (also sagt es uns nur, was es tun würde). Der Rest der Argumente sind Flags, die rsync anweisen, das Ziel in jeder Hinsicht mit der Quelle identisch zu machen, einschließlich Metadaten und HFS-Komprimierungsstatus. Ich glaube, dass Time Machine Buchhaltungs-Metadaten hinzufügt, die beim Wiederherstellen entfernt werden, sodass rsyncmöglicherweise falsche Metadatenänderungen auftreten.
Kurze Antwort für mindestens macOS 10.13.6:
Entfernen Sie alle .inProgress-Backups vom Backup-Volume. Dies kann die Verwendung von als Root erfordern /bin/rm -rf, gehen Sie also mit Vorsicht vor .
Verwenden Sie den tmutil associatediskBefehl, um das Sicherungsvolume erneut an das Hauptvolume zu binden. Zum Beispiel:
sudo tmutil associatedisk -a / "/Volumes/Time Machine Backups/Backups.backupdb/Macintosh HD/Latest/Macintosh HD"
Starten Sie dann ein Backup über das Time Machine-Menüelement. In meinem Fall dauerte der Scan über 30, anstatt den Scan in 10 Minuten abzuschließen (eindeutig kein vollständiger Scan) und ein Terabyte für die Sicherung anzuzeigen, und die Sicherungsgröße stimmte mit dem überein, was tmutil comparegesagt worden war.
Hintergrund:
Ich musste einen Deep Traversal / Full Scan erzwingen, nachdem ein betrügerisches Installationsprogramm (Reallusion) die Berechtigungen für alles in „/Users/Shared“ (etwa 1 Terabyte ansonsten unveränderter Dateien) geändert hatte. Ich änderte sie alle zurück und tmutilbestätigte, dass Time Machine diese Dateien nicht mehr sichern musste, aber eine von zwei Sicherungsfestplatten bestand darauf, einen zwischengespeicherten Scan zu verwenden, der dies bestätigte.
Dinge, die nicht funktioniert haben:
Entfernen und erneutes Hinzufügen des Backup-Volumes aus den Systemeinstellungen
Löschen von /.fseventsd
Installation eines Systemupdates
Entfernen der .inProgress-Sicherung ohne Ausführungtmutil associated disk
tmutil associated diskWird ausgeführt, ohne .inProgress zu entfernen
In den Einzelbenutzermodus booten, / als Lese-/Schreibzugriff einhängen und eine Datei berühren
In den meisten Fällen würden die gesicherten Protokolle behaupten, eine tiefgreifende Traversierung durchzuführen, aber nur wenige Minuten dauern und dann versuchen, alles zu sichern. Hier ist der Befehl, um backupdspäter am 13.10. live zu überwachen:
log stream --style syslog --predicate 'senderImagePath contains[cd] "TimeMachine"' --info
Dadurch werden nur neue Ereignisse angezeigt. Zu den Protokollen der letzten drei Tage:
log show --style syslog --predicate 'senderImagePath contains[cd] "TimeMachine"' --info --last 3d
Thilo