Eignung von HFS Plus

Während Time Machine für die meisten Dinge HFS Plus verwenden muss, ist es erwähnenswert, dass das Dateisystem nicht ideal für diese Aufgabe geeignet ist .

Ein Beispiel

Zufall: Ein paar Stunden nach meiner ersten Ausgabe dieser Antwort erlitt mein eigenes Time Machine Backups- Volume (ein Sparse-Bundle-Disk-Image) einen Dateisystemfehler. Ich bin mir sicher, dass der zugrunde liegende Speicher in Ordnung ist – ein ZFS-Pool, der vor und nach dem Ausfall von HFS Plus fehlerfrei bereinigt wurde. Für das Protokoll:

2013-06-07 18:02:54.332 com.apple.backupd[18433]    Starting automatic backup
2013-06-07 18:02:56.292 com.apple.backupd[18433]    Resizing backup disk image from 2.65 TB to 2.6 TB
2013-06-07 18:03:34.119 com.apple.backupd[18433]    Disk image /Volumes/tall/com.apple.backupd/GPES3E-gjp4-1.sparsebundle mounted at: /Volumes/Time Machine Backups
2013-06-07 18:03:35.244 com.apple.backupd[18433]    Backing up to: /Volumes/Time Machine Backups/Backups.backupdb
2013-06-07 18:03:44.013 com.apple.backupd[18433]    Inherited root volume OS, UUID: C5C41F95-133B-3EB0-9013-F94DAAA0D99B
2013-06-07 18:03:44.147 com.apple.backupd[18433]    Forcing deep traversal on source: "OS" (mount: '/' fsUUID: 03AF4C8A-66E8-3DE2-B30F-176C0C2337C3 eventDBUUID: BDCB9532-A4A8-4B94-A6C1-928FD741B07A)
2013-06-07 18:03:44.148 com.apple.backupd[18433]    Event store UUIDs don't match for volume: spare
2013-06-07 18:03:44.150 com.apple.backupd[18433]    Event store UUIDs don't match for volume: disk0s3
2013-06-07 18:03:47.612 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-103948 does not contain spare.  Skipping it.
2013-06-07 18:03:47.663 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-215311 does not contain spare.  Skipping it.
2013-06-07 18:03:47.714 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-075155 does not contain spare.  Skipping it.
2013-06-07 18:03:47.764 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-055748 does not contain spare.  Skipping it.
2013-06-07 18:03:47.827 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-220121 does not contain spare.  Skipping it.
2013-06-07 18:03:47.888 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-081211 does not contain spare.  Skipping it.
2013-06-07 18:03:47.966 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-215312 does not contain spare.  Skipping it.
2013-06-07 18:03:48.025 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-235752 does not contain spare.  Skipping it.
2013-06-07 18:03:48.087 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-140311 does not contain spare.  Skipping it.
2013-06-07 18:03:48.145 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-215718 does not contain spare.  Skipping it.
2013-06-07 18:03:48.202 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-005749 does not contain spare.  Skipping it.
2013-06-07 18:03:48.261 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-235753 does not contain spare.  Skipping it.
2013-06-07 18:03:48.321 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-160310 does not contain spare.  Skipping it.
2013-06-07 18:03:48.558 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-074020 does not contain spare.  Skipping it.
2013-06-07 18:03:48.619 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-025748 does not contain spare.  Skipping it.
2013-06-07 18:03:48.709 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-015751 does not contain spare.  Skipping it.
2013-06-07 18:03:48.904 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-025749 does not contain spare.  Skipping it.
2013-06-07 18:03:48.954 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-015752 does not contain spare.  Skipping it.
2013-06-07 18:03:49.004 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-130310 does not contain spare.  Skipping it.
2013-06-07 18:03:49.055 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-045748 does not contain spare.  Skipping it.
2013-06-07 18:03:49.162 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-215950 does not contain spare.  Skipping it.
2013-06-07 18:03:49.211 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-092036 does not contain spare.  Skipping it.
2013-06-07 18:03:49.273 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-035751 does not contain spare.  Skipping it.
2013-06-07 18:03:49.321 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-225752 does not contain spare.  Skipping it.
2013-06-07 18:03:49.371 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-065747 does not contain spare.  Skipping it.
2013-06-07 18:03:49.420 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-045749 does not contain spare.  Skipping it.
2013-06-07 18:03:49.470 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-213710 does not contain spare.  Skipping it.
2013-06-07 18:03:49.519 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-091305 does not contain spare.  Skipping it.
2013-06-07 18:03:49.589 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-150310 does not contain spare.  Skipping it.
2013-06-07 18:03:49.639 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-065748 does not contain spare.  Skipping it.
2013-06-07 18:03:49.688 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-074521 does not contain spare.  Skipping it.
2013-06-07 18:03:49.776 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-220105 does not contain spare.  Skipping it.
2013-06-07 18:03:49.838 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-225749 does not contain spare.  Skipping it.
2013-06-07 18:03:49.899 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-092118 does not contain spare.  Skipping it.
2013-06-07 18:03:50.119 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-120311 does not contain spare.  Skipping it.
2013-06-07 18:03:50.388 com.apple.backupd[18433]    Mobile backup /Volumes/MobileBackups/Backups.backupdb/GPES3E-gjp4-1/2013-06-07-035749 does not contain spare.  Skipping it.
2013-06-07 18:03:51.141 com.apple.backupd[18433]    Deep event scan at path:/ reason:must scan subdirs|require scan|
2013-06-07 18:03:51.141 com.apple.backupd[18433]    Finished scan
2013-06-07 18:16:29.077 com.apple.backupd[18433]    Deep event scan at path:/Volumes/spare reason:must scan subdirs|new event db|
2013-06-07 18:16:29.086 com.apple.backupd[18433]    Finished scan
2013-06-07 18:16:29.570 com.apple.backupd[18433]    Deep event scan at path:/Volumes/disk0s3 reason:must scan subdirs|new event db|
2013-06-07 18:16:29.786 com.apple.backupd[18433]    Finished scan
2013-06-07 18:16:30.310 com.apple.backupd[18433]    Found 1695685 files (84.93 GB) needing backup
2013-06-07 18:16:31.053 com.apple.backupd[18433]    109.44 GB required (including padding), 2 TB available
2013-06-07 18:54:10.918 com.apple.backupd[18433]    Unexpected result from MDBackupIndexFile (1) for: /Applications/Freenet/datastore/CHK-cache.hd, /Volumes/Time Machine Backups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-215332.inProgress/9086512E-E386-475E-AE99-34BAA1D2E485/OS/Applications/Freenet/datastore/CHK-cache.hd
2013-06-07 18:54:24.848 com.apple.backupd[18433]    Unexpected result from MDBackupIndexFile (1) for: /Applications/Freenet/datastore/CHK-store.hd, /Volumes/Time Machine Backups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-215332.inProgress/9086512E-E386-475E-AE99-34BAA1D2E485/OS/Applications/Freenet/datastore/CHK-store.hd
2013-06-07 19:03:44.609 com.apple.backupd[18433]    Copied 18.81 GB of 84.93 GB, 460244 of 1695685 items
2013-06-07 20:03:44.827 com.apple.backupd[18433]    Copied 34.12 GB of 84.93 GB, 815234 of 1695685 items
2013-06-07 21:03:54.004 com.apple.backupd[18433]    Copied 40.73 GB of 84.93 GB, 1013214 of 1695685 items
2013-06-07 22:03:54.678 com.apple.backupd[18433]    Copied 67.55 GB of 84.93 GB, 1508426 of 1695685 items
2013-06-07 22:28:43.226 com.apple.backupd[18433]    Copied 1786731 files (77.59 GB) from volume OS.
2013-06-07 22:28:49.157 com.apple.backupd[18433]    Unexpected result from MDBackupIndexFile (1) for: /Volumes/spare/Tocar y Luchar JAA.cdr, /Volumes/Time Machine Backups/Backups.backupdb/GPES3E-gjp4-1/2013-06-06-215332.inProgress/9086512E-E386-475E-AE99-34BAA1D2E485/spare/Tocar y Luchar JAA.cdr
2013-06-07 22:28:51.508 com.apple.backupd[18433]    Error: Flushing index to disk returned an error: 1
2013-06-07 22:28:51.508 com.apple.backupd[18433]    Copied 1786746 files (77.59 GB) from volume spare.
2013-06-07 22:29:11.108 com.apple.backupd[18433]    Backup canceled.
2013-06-07 22:29:23.227 com.apple.backupd[18433]    Ejected Time Machine disk image: /Volumes/tall/com.apple.backupd/GPES3E-gjp4-1.sparsebundle
2013-06-07 23:10:44.791 com.apple.backupd[28884]    Starting automatic backup
2013-06-07 23:10:45.269 com.apple.backupd[28884]    Backup failed with error: 1002
2013-06-07 23:10:45.382 com.apple.backupd[28884]    Starting automatic backup
2013-06-07 23:10:46.446 com.apple.backupd[28884]    Resizing backup disk image from 2.6 TB to 2.6 TB
2013-06-07 23:10:50.162 com.apple.backupd[28884]    Runtime corruption detected on /Volumes/tall/com.apple.backupd/GPES3E-gjp4-1.sparsebundle (fsck_hfs -q termination status: 3)

• Die Nachricht am 07.06.2013 22:28:49 ist auffällig, wird aber in meinem Fall erwartet (Symptom eines Fehlers mit HFS Plus; eine Beschädigung, die AppleFSCompression betrifft) – im Kontext dieser Antwort wahrscheinlich vernachlässigbar

• Die Meldung am 07.06.2013 22:28:51 ist möglicherweise relevanter für den Dateisystemfehler.

/private/var/log/fsck_hfs.logzeigte dann:

/dev/rdisk7s2: fsck_hfs run at Fri Jun  7 23:10:48 2013
/dev/rdisk7s2: ** /dev/rdisk7s2 (NO WRITE)
/dev/rdisk7s2:    Executing fsck_hfs (version diskdev_cmds-557.3.1~5).
QUICKCHECK ONLY; FILESYSTEM DIRTY

/dev/rdisk7s2: fsck_hfs run at Fri Jun  7 23:10:49 2013
/dev/rdisk7s2: ** /dev/rdisk7s2 (NO WRITE)
/dev/rdisk7s2:    Executing fsck_hfs (version diskdev_cmds-557.3.1~5).
QUICKCHECK ONLY; FILESYSTEM DIRTY

Bestätigen, dass zu diesem Zeitpunkt kein Fehler den zugrunde liegenden Speicher beeinflusst hat:

GPES3E-gjp4-1:~ gjp22$ date
Sat  8 Jun 2013 06:57:46 BST
GPES3E-gjp4-1:~ gjp22$ uptime
 6:57  up 21:51, 5 users, load averages: 0.92 1.27 1.37
GPES3E-gjp4-1:~ gjp22$ zpool status
  pool: gjp22
 state: ONLINE
 scan: scrub repaired 0 in 24h8m with 0 errors on Sat May 25 23:25:38 2013
config:

    NAME                                         STATE     READ WRITE CKSUM
    gjp22                                        ONLINE       0     0     0
      GPTE_71B8BDA2-3EBA-4B91-9E1C-2AE2B1DAAD06  ONLINE       0     0     0  at disk3s2
    cache
      GPTE_2605CCB0-67B7-4C93-A4B1-83EF764CE617  OFFLINE        1.48Ki     0

errors: No known data errors

  pool: tall
 state: ONLINE
 scan: scrub repaired 0 in 28h10m with 0 errors on Sun May 26 18:47:22 2013
config:

    NAME                                         STATE     READ WRITE CKSUM
    tall                                         ONLINE       0     0     0
      GPTE_78301A52-4AFF-4D96-8DE9-E76ABC14909C  ONLINE       0     0     0  at disk2s2
      GPTE_99056308-F5E2-4314-852C-4DA04732A2D0  ONLINE       0     0     0  at disk6s2

errors: No known data errors
GPES3E-gjp4-1:~ gjp22$ 

In einfachen Worten

Obwohl wir gerne eine Lösung hätten, scheinen Dateisystemfehler wie diese zu sein:

• unberechenbar
• unvermeidlich
• manchmal irreparabel.

In Ermangelung einer guten Lösung ist mein bester Rat, sich nicht auf ein einziges Time Machine-Backup zu verlassen. Das Risiko eines eventuellen Ausfalls und der Unmöglichkeit der Reparatur ist einfach zu hoch.

Grade des Scheiterns

In der Vergangenheit habe ich manchmal fsck_hfs(8) gezwungen , b-tree-Dateien neu zu erstellen … mit begrenztem Erfolg, aber nicht mit Sicherheit. Während ein Dateisystem in Ordnung zu sein scheint (im Festplatten-Dienstprogramm und dergleichen), würde ich ihm nicht mehr für Sicherungs- oder Wiederherstellungszwecke von Time Machine vertrauen.

Im jüngsten Fall (oben) haben mehrfache Zwangsmaßnahmen (mehrfacher Neuaufbau des Katalog-B-Baums, ein Neuaufbau des erweiterten Attribute-B-Baums und ein Neuaufbau des Extents-B-Baums) nicht zu einem verifizierbaren Dateisystem geführt. Ich habe Debug-Protokolle von diesen Versuchen, die ich hier nicht zusammenfassen werde; sie sind massiv.

Bei lokal angeschlossenen Festplatten (USB 2.0) können Versuche, Time Machine-Sicherungsvolumes zu reparieren, außerordentlich zeitaufwändig sein. Drahtlos – über AFP – kann die benötigte Zeit unerträglich sein .

Time Machine – Fehlerbehebung – C13. „…Time Machine muss ein neues Backup für Sie erstellen.“ (James Pond) enthält viele nützliche Informationen. Im Wesentlichen:

… Sicherungen beschädigt sind, die vom Festplattendienstprogramm nicht behoben werden können …

Wenn OS X meldet, dass ein HFS Plus -Dateisystem in Ordnung zu sein scheint, kann es erhebliche Probleme mit der Festplatte geben – Probleme, die OS X einfach nicht erkennen kann.

Da die Beschädigung mehr als einmal aufgetreten ist, kann es ein Problem geben mit:

• Hardware, Firmware und/oder Software des NAS.

Welche Marke und welches Modell ist das NAS?

Festplatten des NAS

Wenn das Betriebssystem des NAS es Ihnen erlaubt, die Integrität von Blöcken auf seinen Festplatten zu überprüfen : tun Sie dies bitte.

Wenn dem Betriebssystem des NAS diese Fähigkeit fehlt, versuchen Sie, die Hardware mit einem anderen Betriebssystem zu booten, das zum Testen besser geeignet ist. Zu den Optionen könnten Ubuntu und eine Reihe von Badblocks gehören .

Überprüfungen dieser Art:

• wird zeitaufwändig sein; sondern
• sollte Ihnen dabei helfen festzustellen, ob der Zustand der Festplatte(n) zu den mehreren Ausfällen beigetragen hat.

Um die Warnung von @GrahamPerrin zu ergänzen, möchte ich meinen Plan dafür teilen.

Auf meinem NAS läuft FreeNAS mit ZFS .

Ich war mir des Problems „Time Machine muss ein neues Backup erstellen“ bewusst, bevor ich die Dinge einrichte, und habe das TimeMachine-Host-Volume auf dem NAS zu einem separaten ZFS-Volume gemacht, das nur dafür verwendet wird. Dann habe ich tägliche Datei -Überblicke festgelegt . Wenn der Inhalt des ZPool1/Backups/TimeMachineVolumes aufgrund von Netzwerkfehlern oder der allgemeinen Unzuverlässigkeit des virtuellen HFS+-Laufwerks in einem anderen Volume beschädigt wird, kann ich es auf dem NAS zurücksetzen. Ich nenne das manchmal das Meta-Backup .

Deutlich sein,

• das Host-Volume ist der NAS-SpeicherZPool1/Backups/TimeMachine
• Es enthält eine virtuelle HFS+-Festplatte als Verzeichnis des Hosts, "John's MacBook Pro.sparsebundle"das selbst über ein bandsUnterverzeichnis verfügt, das den vollständig bereitgestellten virtuellen Laufwerksspeicher in Form von 951 Dateien mit Namen wie e8(Hex-Zahlen, die von 0 aufwärts zählen) enthält.
• Über die virtuelle Festplatte verarbeitet Time Machine automatisch ein Zielvolume, das nicht HFS+ ist. Aber ich habe es im Voraus erstellt, um Chunk-Größen effizient zu machen (128 MB pro Datei).
• Das NAS veröffentlicht ZPool1/Backups/TimeMachineals AFP-Freigabe mit gesetztem „Use for Time Machine“-Flag. TimeMachine erwartet, dass dies die virtuelle Festplatte enthält, die es dann verwendet, oder erstellt, wenn es die erste Verwendung dieses Netzwerkspeicherorts für die Sicherung ist.

Die ZFS-Volume-Snapshot-Funktion funktioniert also, weil es sich um ein ZFS-Volume handelt, das eine Reihe von 128-MB-Datendateien mit langweiligen Namen enthält. Time Machine funktioniert, weil es eine als HFS+ formatierte virtuelle Festplatte auf das angezeigte Dateisystem legt.

Ich hatte das gleiche Problem, als ich Time Machine zum ersten Mal für die Verwendung meines NAS konfigurierte – alle paar Wochen erhielt ich das Popup oben in diesem Thread. Es war sehr frustrierend. Allerdings habe ich mit der Zeit gemerkt, dass dies nur an bestimmten Wochentagen der Fall war. Und dann wurde mir klar, dass es nur während der wöchentlichen Scrub- (Montagmorgen) oder Resync-Operationen (Dienstagmorgen) passierte. Also habe ich eine Kopie von "Time Machine Editor" erhalten, mit der Sie Time Machine mitteilen können, wann es ausgeführt werden kann und wann nicht, ausgenommen Montag- und Dienstagmorgen, und voila, Problem gelöst.

Ergänzend zu Ronald Pottols Vorschlag konvertiert das Folgende ein Sparsebundle, anstatt es neu zu erstellen. Sobald dies erledigt ist, benennen Sie die Bundles einfach um.

hdiutil convert MyMac_001acb9cb23d.sparsebundle -format UDSB -tgtimagekey sparse-band-size=2097152 -o NEW_MyMac_001acb9cb23d.sparsebundle

Ich frage mich, ob Sie die maximale Dateianzahl für das Zielverzeichnis erreichen? In einem klassischen Unix-Dateisystem wie ext2 haben Sie ein Limit von 32.000 (2^15) Dateien (oder Unterverzeichnissen oder Links (Dingen)) pro Verzeichnis. Ein Time Machine-Backup ist ein Sparse-Disk-Image, das aus einer Reihe von 8-MB-Dateien besteht. 300 GB von 8 MB Dateien sind ungefähr 37.000. Hoppla.

Sie können die Größe der Dateien erhöhen, die Time Machine im Sparse-Bundle verwendet (diese Anweisungen würden die maximale Größe Ihres Backups um 16 erhöhen), oder das Dateisystem auf dem NAS ändern, Reiserfs, ext4 (einige Versionen von ext3), usw. wird wahrscheinlich funktionieren, wenn dies das Problem ist.

Benutzer KingKongFrog hat diese Antwort hinzugefügt, ich füge sie meiner Antwort hinzu (aber stimme auch seiner zu), damit können Sie Ihr vorhandenes Backup in die größere Größe konvertieren

hdiutil convert MyMac_001acb9cb23d.sparsebundle -format UDSB -tgtimagekey sparse-band-size=2097152 -o NEW_MyMac_001acb9cb23d.sparsebundle

Link zu dem Blog, von dem ich das habe

# creates a sparsebundle disk image with a 128MB band size
MACHINE_NAME=your-machine-name
echo $MACHINE_NAME
hdiutil create -size 900g -type SPARSEBUNDLE -nospotlight -volname "Backup of $MACHINE_NAME" -fs "Case-sensitive Journaled HFS+" -imagekey sparse-band-size=262144 -verbose ./$MACHINE_NAME.sparsebundle

# copy the plists from TIME_MACHINE_IMAGE to NEW_IMAGE
TIME_MACHINE_IMAGE=your-machine-name.old.sparsebundle
NEW_IMAGE=your-machine-name.sparsebundle
cp $TIME_MACHINE_IMAGE/com.apple.TimeMachine.*.plist $NEW_IMAGE

Ich habe ein Skript geschrieben, das versucht, das Time Machine-Sicherungspaket gemäß den Anweisungen von hier zu reparieren . Es ist auch auf GitHub verfügbar .

#!/usr/bin/env bash

BACKUP_PATH=$1

if [ -z "$BACKUP_PATH" ]; then
    echo "Please provide path to Time Machine backup bundle."
    exit 1
fi

echo "Don't forget to enable Full Disk Access in System Preferences -> Security & Privacy -> Privacy tab -> Full Disk Access -> check Terminal or iTerm item"
chflags -R nouchg "$BACKUP_PATH"
VOLUME_ID=$(hdiutil attach -nomount -noverify -noautofsck "$BACKUP_PATH" | grep "Apple_HFS" | awk '{print $1}')
fsck_hfs -drfy "$VOLUME_ID"
hdiutil detach "$VOLUME_ID"
sed -i '' -e '/<key>VerificationState<\/key>/ {' -e 'n; s/<integer>.*<\/integer>/<integer>0<\/integer>/' -e '}' "$BACKUP_PATH/com.apple.TimeMachine.MachineID.plist"

Diese Antwort soll einen weiteren Faktor der sogenannten „Korruption“ ansprechen.

Ich hatte etwas Ähnliches: macOS sicherte auf einer SMB-Freigabe auf meinem (virtualisierten) NAS, das auf ZFS gehostet wurde. Eigentlich verwende ich ein ext4-Volume, um das Sparsebundle zu speichern, da eine anständige Linux-Unterstützung für HFS/APFS nicht wirklich vorhanden ist. Auf diese Weise kann ich zumindest richtig auf die Rohdaten direkt von meinem NAS zugreifen und gleichzeitig macOS mit einem HFS-Sparsebundle füttern. Ich verschlüssele das Backup nicht aus genau dem Grund, um es außerhalb von macOS wiederherstellen zu können. Das lief schon seit einiger Zeit gut, aber heute entschied es plötzlich, dass die Dinge "korrumpiert" waren. Der Versuch, es außerhalb von Time Machine zu mounten, hat zunächst nicht funktioniert:

$ hdiutil attach -nomount -noverify -noautofsck mymac.sparsebundle
hdiutil: attach failed - image not recognized

Aber ZFS wurde kürzlich gescrubbt und hat keine Probleme gemeldet, auch kann ich Dateien problemlos über mein NAS bearbeiten (ich habe die XML-Dateien zum Testen verwendet). Dies lässt es eher nach einem Zugriffsproblem als nach einer tatsächlichen Beschädigung klingen. Ich verwende immer nur ein und denselben SMB-Benutzer für den Zugriff auf die Freigabe, und ich sichere nicht einmal mehrere Macs, sodass Eigentumsprobleme ausgeschlossen werden sollten. Ich habe mich entschieden, stattdessen die Eigentümerberechtigungen zu überprüfen :

$ find mymac.sparsebundle ! -perm -u+r -o ! -perm -u+w -o ! -perm -u+x
mymac.sparsebundle
mymac.sparsebundle/bands/1ac69
# snipped, there are 31432 hits for files in /bands/
mymac.sparsebundle/com.apple.TimeMachine.MachineID.bckup
mymac.sparsebundle/token

Beachten Sie, dass sogar dem Sparsebundle selbst mindestens eine der Berechtigungen fehlt. Es scheint, dass alle von zurückgegebenen Treffer findfehlen +x, was ziemlich problematisch ist, da ich das Sparsebundle jetzt nicht "ausführen" ( seinen Inhalt lesen ) kann. /bands/Nur um sicherzugehen, dass ich nach Dateien gesucht habe , die rwxBerechtigungen für den Eigentümer haben:

$ find mymac.sparsebundle/bands -type f -perm -u+rwx | wc -l
77868

Es scheint also, als hätte wirklich alles u+rwxeingestellt werden sollen, sogar normale Dateien. Dies kann am Sparsebundle-Format, dem ext4-Volume oder sogar an SMB liegen. Wie auch immer, lassen Sie uns das korrigieren: chmod -Rv u+rwx mymac.sparsebundle.

Das war jedoch nicht genug, da Time Machine sich immer noch beschwerte. Anscheinend speichert es einige "Panik" -Informationen in den XML-Dateien des Sparsebundle, und Sie können überall Korrekturen dafür finden (einschließlich anderer Antworten auf genau diese Frage), aber ich habe meine insbesondere von hier . Ich habe mich leicht an meinen Geschmack angepasst:

$ cd mymac.sparsebundle
$ chflags -R -v nouchg . # The gist doesn't use -R but uses only specific paths
$ /usr/libexec/PlistBuddy -c "Delete :RecoveryBackupDeclinedDate" com.apple.TimeMachine.MachineID.plist
$ /usr/libexec/PlistBuddy -c "Set :VerificationState 0" com.apple.TimeMachine.MachineID.plist
$ hdiutil attach -nomount -noverify -noautofsck .
/dev/disk4              GUID_partition_scheme
/dev/disk4s1            EFI
/dev/disk4s2            Apple_HFS
$ fsck_hfs -fy -c 8gb /dev/rdisk4s2 # I made a habit of using rdisk* instead of disk* for low-level operations like this
# snipped some output, but it ended with:
** The volume Time Machine Backups appears to be OK.
$ hdiutil detach /dev/disk4
"disk4" ejected.

Endlich kann ich meine Backups fortsetzen, ohne den gesamten Verlauf verloren zu haben. Ich bin mir nicht sicher, was das Berechtigungsproblem verursacht hat, vielleicht haben es die von Time Machine gesendeten Befehle aufgrund eines Netzwerkfehlers nicht ganz geschafft. Oder ein Problem mit der ACL-Vererbung.

Beachten Sie, dass dies auch nach dem Ändern der Eigenschaften und dem Festlegen von Berechtigungen fsck_hfserforderlich zu sein scheint . plistIch denke, es dreht immer noch einige Bits um, die macOS mitteilen, dass die Lautstärke jetzt (wieder) tatsächlich gesund ist.

Update 14.06.2022: Das gleiche Berechtigungsproblem trat erneut auf, als ich Time Machine betrat und es während des Ladens unterbrach. Diesmal konnte es das Sparsebundle immer noch teilweise montieren, aber ich kam immer noch Permission deniedüberall hin. Also habe ich es einfach nochmal korrigiert und gut ist.

Die prägnanteste Anleitung (es hat funktioniert und meine TM-Backup-Sparsebundles wiederhergestellt) habe ich unter gefunden

http://jd-powered.net/notes/fixing-your-time-machine-backup

und

http://tonylawrence.com/post/unix/fixing-corrupted-time-machine-backups/ das scheint der Originalartikel zu sein (2012)

Diese Antwort soll meine Erfahrungen dazu teilen und Sie einladen, Feedback zu geben.

Ich hatte den Fehler „Beschädigte Backups“, also habe ich die Lösung von Ronald Pottol erfolglos ausprobiert. hdiutil: create failed - ...Beim Erstellen des Sparsbundle auf meinem NAS (einem selbstgemachten NAS mit Debian Wheezy und einer ext4-Partition) kam es immer zu einem Fehler.

Also, nach einigem Googeln habe ich das versucht (von dort ):

1. Rufen Sie die Kennung des Computers ab:

   $ ifconfig en0 | grep ether | sed s/://g | sed s/ether//

   b88d120afd6c

2. Verwenden Sie diese Kennung, um ein Sparsebundle (in Ihrem Heimatverzeichnis) mit den Parametern von Ronald Pottol zu erstellen (ComputerName muss durch den tatsächlichen Computernamen ersetzt werden).

   sudo hdiutil create -size 190g -type SPARSEBUNDLE -nospotlight -volname "Backup of ComputerName" -fs "Case-sensitive Journaled HFS+" -imagekey sparse-band-size=262144 -verbose ~/ComputerName_b88d120afd6c

   „Backup of ComputerName“ sollte durch eine Zeichenfolge ersetzt werden, die Ihren Spracheinstellungen entspricht. Auf französisch: "Copies de sauvegarde Time Machine"

   Fügen Sie hinzu -encryption AES-128 -stdinpass(z. B. nach -verbose), um die Verschlüsselung für das Backup zu aktivieren. Sie werden nach einem Verschlüsselungskennwort gefragt. Sie können auch AES-256anstelle von verwenden AES-128.

3. Stellen Sie das NAS-Laufwerk bereit, das die Time Machine-Sicherungen enthalten wird.

4. Kopieren Sie mit dem Finder das erstellte Sparsbundle aus dem Home-Verzeichnis auf dieses Laufwerk.

5. Konfigurieren Sie Time Machine für die Verwendung des NAS-Laufwerks. Wenn die Verschlüsselung aktiviert war, verwenden Sie dieselben Sicherungsdateien und bestätigen Sie das zuvor festgelegte Kennwort.

6. Führen Sie eine erste Sicherung durch.

Im Dienstprogramm Console sollte eine Nachricht geschrieben werden, die angibt, dass das Sparsebundle umbenannt wurde. Es hat also den richtigen Sparse-Band-Size-Parameter, der zukünftige Fehler vermeiden sollte:

18/07/2014 06:50:25,712 com.apple.backupd[3573]: Renaming /Volumes/tmNasDrive-1/ComputerName_b88d120afd5c.sparsebundle to /Volumes/tmNasDrive-1/ComputerName.sparsebundle

Ich hatte keine Fehler, seit ich dieses neue Backup gestartet habe, aber das bedeutet nicht, dass diese Lösung wirklich zuverlässig ist. Ich hoffe, das wird helfen. Jedes Feedback ist willkommen.