Time Machine mit einer Time Capsule verwenden – Backups funktionieren reibungslos. Das Problem besteht darin, mit „tmutil compare“ die Unterschiede zwischen zwei Backups anzuzeigen. MacOS Mojave 10.14.5 (dasselbe Problem bei vorheriger Betriebssystemversion).
Die Anwendung
Verwenden Sie Time Machine, um mehrere Macs im Netzwerk auf mehreren Backup-Laufwerken zu sichern. Dabei sollen regelmäßig „tmutil compare“-Vorgänge ausgeführt werden, um zu sehen, was gesichert wird, wie viele Dateien, wie viele Daten usw.
Apps wie BackupLoupe bieten hierfür eine grafische Benutzeroberfläche (GUI) – was nett ist –, aber Sie müssen jedes Sparsebundle manuell mounten. (Und übrigens scheint es mit Mojave nicht mehr zu funktionieren.)
Die Absicht bestand also darin, den Prozess zu automatisieren:
- Verwenden Sie tmutil destinationinfo, um eine Liste der Sicherungslaufwerke zu ermitteln.
- Mounten Sie alle Laufwerke (an separaten Mountpunkten).
- Untersuchen Sie jedes Laufwerk, um eine Liste der Macs zu erhalten (z. B. mymac1.sparsebundle, mymac2.sparsebundle, …).
- Mounten Sie für jeden Mac, für jedes Laufwerk (das ein Sparsebundle für diesen Mac hat), das Sparsebundle, stellen Sie sicher, dass es einen Backups.backupdb-Knoten hat, listen Sie alle Backups auf (2019-05-22-111213) und führen Sie einen „tmutil compare“ zwischen jedem Eintrag und dem vorhergehenden Eintrag aus.
Ein Cache wird automatisch verwaltet, sodass der Schritt „tmutil compare“ nur für neue Backups ausgeführt wird.
Da „tmutil compare“ sehr lange dauern kann, wurde Schritt (4) so konzipiert, dass jeder Mac verarbeitet wird und separate Threads gestartet werden – einer für jede Festplatte –, die parallel ausgeführt werden. Es wurde angenommen, dass das Starten weiterer Threads für zusätzliche Macs nur zu Engpässen beim Wettbewerb um den Zugriff auf dieselben Laufwerke führen würde.
Das funktioniert
Stellen Sie über den Finder eine Verbindung zur Time Capsule her (erstellt im Hintergrund /Volumes/mydisk). Suchen Sie im Finder nach dem gewünschten mymac.sparsebundle und öffnen Sie es mit DiskImageMounter (erstellt im Hintergrund /Volumes/Time Machine-Backups).
Gehen Sie zum Terminal und:
cd "/Volumes/Time Machine Backups/Backups.backupdb/mymac"
tmutil compare 2019-05-19-034451 2019-05-18-220446
Die Ausgabe ist genau wie erwartet.
Das schlägt fehl
Erstellen Sie 2 Verzeichnisse - ../mytemp/mount und ../mytemp/bundle (als Einhängepunkte). Führen Sie tmutils destinationinfo aus, um die Einhängezeichenfolgen abzurufen.
Ausführen: mount_afp -o rw "afp://tc:pwd@tc._afpovertcp._tcp.local./diskname" ../mytemp/mount
Ausführen: hdiutil attach ../mytemp/mount/mymac.sparsebundle -readwrite -mountroot ../mytemp/bundle
Ausführen: cd "../mytemp/bundle/Time Machine Backups/Backups.backupdb/mymac"
Diese funktionieren alle wie erwartet. Das mymac.sparsebundle ist in ../mytemp/bundle eingebunden. Sie können mit „cd“ in das eingebundene Sparsebundle wechseln. Ein „ls“ listet wie erwartet alle Sicherungsdateien auf.
ABER führen Sie „tmutil compare 2019-05-19-034451 2019-05-18-220446“ erneut aus und erhalten Sie Folgendes:
Must specify at least one item inside a backup.
Kann tatsächlich entweder in das Backup vom 19.05.034451 vom 2019 oder in das andere „cd“ wechseln, „ls“ zeigt genau das, was erwartet wird. Kann mehrere Ebenen nach unten „cd“, einige Dateien per „cat“ auf die Konsole übertragen usw.
Nach dem Mounten beider Wege bin ich auf die gleichen Ebenen heruntergegangen und habe „touch dummy.file.txt“ ausgegeben, um tatsächlich eine Datei zu erstellen. Dies schlug fehl, aber das Hinzufügen von „sudo“ war erfolgreich – unter beiden Mount-Szenarien. (Innerhalb eines bestimmten Backups schlug dies unter beiden Setups fehl.)
Habe bei Autorisierungsproblemen auch „sudo tmutil ...“ versucht, aber das Ergebnis war dasselbe. Habe auch einige „ls -la“-Befehle auf verschiedenen Ebenen ausgeführt, aber keine offensichtlichen Unterschiede in der „rwx“-Zuweisung.
Tmutil wurde zur Liste „Voller Festplattenzugriff“ in den Systemeigenschaften hinzugefügt.
Ausgeführt: log show --predicate 'process=="tmutil"'
zeigt aber im Erfolgs- und im Fehlerfall die gleiche Ausgabe an.
Am Ende meiner Kräfte! Was ist der Unterschied – Kontext, Autoritäten, ??? Was machen Finder und DiskImageMounter anders als mount_afp und hdiutil? Ist eine Ebene schreibgeschützt und tmutil versucht, ein Protokoll zu aktualisieren?
Für jede Hilfe und jeden Vorschlag bin ich sehr dankbar!
Aktualisieren
Teilen Sie die 2 Schritte auf - montieren Sie diefahrenmit mount_asp, dann mounten Sie diebündelnmit DiskImageManager - und das funktioniert. Das Problem liegt also in der Verwendung von hdiutil gegenüber DiskImageManager.
Aktualisierung 2
Immer noch in Arbeit, aber anscheinend „tmutil“erfordertdass das Paket innerhalb von /Volumes gemountet wird!
Habe versucht, es durch die Erstellung eines symbolischen Links auszutricksen:
/Volumes/Time Machine Backups -> my mount point
aber es schlägt immer noch fehl. Versuche andere Workarounds.
Weiß jemand, ob dies eine echte Anforderung von tmutil ist? Ist es irgendwo dokumentiert?
Gelöst (aber ein Hack!)
Habe versucht, einen Root-Mountpoint zu /Volumes hinzuzufügen, mit der Idee, dann mehrere Sparsebundles darunter zu mounten – aber das hat auch nicht funktioniert. Offensichtlich erwartet „tmutil“, dass das Bundle als unmittelbares Kind von /Volumes gemountet wird.
Der endgültige Hack sieht wie folgt aus:
- Erstellen Sie einen Einhängepunkt für die Laufwerke: ../mycache/drives
- Mounten Sie alle Laufwerke unterhalb dieses Knotens
- Alle einhängenBündelinnerhalb von /Volumes unter Verwendung des normalen Standardnamens - Time Machine Backups [n]
- Ermitteln Sie intern, welches Mount zu welchem Laufwerk passt, indem Sie alle Varianten von Time Machine-Backups [n] auflisten. Mounten Sie anschließend das Paket und holen Sie sich die Liste der Time Machine-Backups [n] erneut, um herauszufinden, welches das neue Mount ist.
- Führen Sie dann tmutil compare /Volumes/Time Machine Backups 2/Backups.backupdb/mymac/... aus.
Dies funktioniert einigermaßen gut. Schlägt fehl, wenn ein anderer Prozess ein Sparsebundle mit einem Time Machine Backups-Eintrag mountet – das würde die obige Logik durcheinanderbringen.