Time-Machine-Backup/-Sparsebundle reparieren

Aus verschiedenen Gründen kann es sein, dass Time Machine die Überprüfung eines Sparsebundle-Backups nicht erfolgreich abschließt. In den meisten Fällen hat das Dateisystem des Sparsebundle-Images ein Problem. Mit einigen wenigen – aber zeitaufwendigen – Schritten ist nachfolgend erklärt, wie man sein Time-Machine-Backup/-Sparsebundle reparieren kann, nachdem Time Machine es als nicht mehr zuverlässig erkannt hat.

Eine solche Meldung von Time Machine sieht folgendermaßen aus:

Time Machine hat erkannt, dass deine Backups auf „KittNAS.local“ nicht zuverlässig wiederhergestellt werden können.

Die Meldung als Text:

Time Machine hat erkannt, dass deine Backups auf „KittNAS.local“ nicht zuverlässig wiederhergestellt werden können.

Time Machine muss deinen bestehenden Backup-Verlauf löschen und ein neues Backup starten, um dies zu beheben.

Im ersten Schritt sollten die automatischen Backups in Time Machine deaktiviert werden. Das geht in den Systemeinstellungen unter Time Machine > Automatische Datensicherung.

Vor macOS 11 alias Big Sur sah die Fehlermeldung etwas anders aus:

Time Machine hat die Überprüfung deines Backups auf „KittNAS.local“ abgeschlossen. Um die Zuverlässigkeit zu verbessern, muss Time Machine ein neues Backup für dich erstellen.

Die Meldung als Text:

Time Machine hat die Überprüfung deines Backups auf „KittNAS.local“ abgeschlossen. Um die Zuverlässigkeit zu verbessern, muss Time Machine ein neues Backup für dich erstellen.

Klicke auf „Neues Backup starten“, um ein neues Backup zu erstellen. Dabei wird dein bestehender Backup-Verlauf gelöscht. Dies kann mehrere Stunden dauern.

Klicke auf „Backup später erstellen“, um morgen an das Backup erinnert zu werden. Währenddessen erstellt Time Machine keine Backups

Dateisystem einhängen

Danach muss das Time-Machine-Volume eingehängt werden, sodass es unter /Volumes sichtbar ist. Das kann in der Regel über das Netzwerk im Finder vorgenommen werden.

Dann muss man sich im Terminal mit dem Programm chflags Schreibzugriff auf das Sparsebundle-Image geben, damit man es beschreiben kann. Dieser Befehl sieht folgendermaßen aus:

chflags -R nouchg /Volumes/{Netzlaufwerk}/{name}.sparsebundle

Dabei müssen {Netzlaufwerk} und {name} jeweils durch den Namen bzw. durch den Pfad des Netzlaufwerks bis zum Sparsebundle-Image und den Namen des Sparsebundle-Images selbst ersetzt werden.

Sind dort im Pfad Leerzeichen vorhanden, müssen diese mit einem vorangestellten \ markiert werden. Beispielhaft sieht ein Pfad folgendermaßen aus:

/Volumes/timemachine/MacBook\ Pro\ Backup.sparsebundle

Dateisystem überprüfen

Dann sollte als erstes das Dateisystem überprüft werden. Das geht mit dem Programm hdiutil, der genaue Befehl sieht folgendermaßen aus:

hdiutil attach -nomount -noverify -noautofsck /Volumes/{Netzlaufwerk}/{name}.sparsebundle

Auch hier muss wieder der Pfad zum Sparsebundle-Image angepasst werden.

Es erscheint sofort eine Ausgabe, die folgendermaßen aussieht:

/dev/disk3          	GUID_partition_scheme
/dev/disk3s1        	EFI
/dev/disk3s2        	Apple_HFS

Der eigentliche Test wurde dann bereits durchgeführt und ist unter /var/log/fsck_hfs.log zu finden. In meinem Fall sieht die Ausgabe dort folgendermaßen aus:

/dev/rdisk3s2: fsck_hfs started at Fri Jul  5 21:42:42 2019
/dev/rdisk3s2: /dev/rdisk3s2: ** /dev/rdisk3s2 (NO WRITE)
/dev/rdisk3s2:    Executing fsck_hfs (version hfs-407.200.4).
QUICKCHECK ONLY; FILESYSTEM DIRTY
/dev/rdisk3s2: fsck_hfs completed at Fri Jul  5 21:42:42 2019Code-Sprache: JavaScript (javascript)

Oder:

/dev/rdisk3s2: fsck_hfs started at Fri Jul  5 21:22:45 2019
/dev/rdisk3s2: /dev/rdisk3s2: ** /dev/rdisk3s2 (NO WRITE)
/dev/rdisk3s2:    Executing fsck_hfs (version hfs-407.200.4).
QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk3s2: fsck_hfs completed at Fri Jul  5 21:22:45 2019Code-Sprache: JavaScript (javascript)

Steht dort FILESYSTEM DIRTY, dann muss das Dateisystem repariert werden (siehe erstes Beispiel). Steht dort FILESYSTEM CLEAN, dann muss das Dateisystem nicht repariert werden und die nachfolgenden Reparaturen können übersprungen werden.

Dateisystem reparieren

Für die Reparatur eignet sich das Programm fsck_hfs. Der Befehl sieht dabei folgendermaßen aus:

fsck_hfs -drfy /dev/disk3s2

Dabei haben die Parameter drfy folgende Bedeutung:

  • d: Debug-Modus
  • r: Catalog Tree neu erstellen
  • f: Änderungen erzwingen
  • y: Jeden Dialog automatisch mit „ja“ beantworten

Den Pfad /dev/disk3s2 kann man der Ausgabe von hdiutil oben entnehmen. Hier muss der Pfad verwendet werden, bei dem rechts dann Apple_HFS steht.

Möglicherweise erhält man dabei jedoch folgende Meldung:

Unable to open block device /dev/disk3s2: Operation not permittedjournal_replay(/dev/disk2s2) returned 1
** /dev/rdisk3s2 (NO WRITE)
Can't open /dev/rdisk3s2: Operation not permittedCode-Sprache: JavaScript (javascript)

Das heißt, das Programm hat nicht ausreichend Berechtigungen, die Festplatte zu verändern. Um dies zu ändern, muss die Datei /sbin/fsck_hfs in den Systemeinstellungen unter Sicherheit > Datenschutz > Festplattenzugriff hinzugefügt werden. Möglicherweise ist danach ein Systemneustart erforderlich.

Um das Programm dort einfügen zu können, gehe zum Finder und drücke ⌘ + control + G und gib im erscheinenden Fenster /sbin ein. Dort findest du dann die entsprechende Datei und kannst sie per Drag’n’Drop in die Systemeinstellungen einfügen.

Der Reparaturvorgang kann einige Zeit in Anspruch nehmen. Also bitte warten, bis er vollständig durchgelaufen ist. Das erkennt man im Terminal daran, dass der Cursor rechts von einem $ steht, bei mir beispielsweise:

MacBook:~ matze$

Die Ausgabe kann dabei folgendermaßen aussehen:

journal_replay(/dev/disk3s2) returned 0
** /dev/rdisk3s2
	Using cacheBlockSize=32K cacheTotalBlock=65536 cacheSize=2097152K.
   Executing fsck_hfs (version hfs-407.200.4).
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine-Backups
** Checking extents overflow file.
** Checking catalog file.
** Rebuilding catalog B-tree.
hfs_UNswap_BTNode: invalid node height (1)
** Rechecking volume.
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine-Backups
** Checking extents overflow file.
** Checking catalog file.
   Incorrect number of thread records
(4, 23290)
	CheckCatalogBTree: dirCount = 483781, dirThread = 483784
** Checking multi-linked files.
   Incorrect number of file hard links
	Incorrect linkCount for inode=1830530 (expected=2, found=1)
** Checking catalog hierarchy.
   Invalid directory item count
   (It should be 598264 instead of 598265)
   Invalid directory item count
   (It should be 109502 instead of 109504)
   Invalid volume directory count
   (It should be 483690 instead of 483780)
   Invalid volume file count
   (It should be 4061850 instead of 4062088)
   Incorrect folder count in a directory (id = 18)
   (It should be 0 instead of 1)
   Incorrect folder count in a directory (id = 19)
   (It should be 109502 instead of 109504)
   Incorrect folder count in a directory (id = 4418368)
   (It should be 41 instead of 0)
   Incorrect folder count in a directory (id = 4418981)
   (It should be 41 instead of 0)
** Checking extended attributes file.
   Incorrect number of extended attributes
   (It should be 2818345 instead of 2818894)
   Incorrect number of Access Control Lists
   (It should be 2818277 instead of 2818826)
   Unused node is not erased (node = 286408)
   Unused node is not erased (node = 286409)
   Unused node is not erased (node = 286410)
   Unused node is not erased (node = 286412)
   Unused node is not erased (node = 286413)
** Checking multi-linked directories.
	privdir_valence=109504, calc_dirlinks=309509, calc_dirinode=109502
   Incorrect number of directory hard links
	Error getting first link ID for inode=4419585
** Checking volume bitmap.
   Volume bitmap needs repair for under-allocation
** Checking volume information.
   Invalid volume free block count
   (It should be 17692608 instead of 8239466)
	invalid VHB nextCatalogID
   Volume header needs minor repair
(2, 0)
   Verify Status: VIStat = 0xa000, ABTStat = 0x0064 EBTStat = 0x0000
                  CBTStat = 0x0800 CatStat = 0x00004003
** Repairing volume.
   Indirect node 1834048 needs link count adjustment
   (It should be 2 instead of 1)
   Indirect node 1834275 needs link count adjustment
   (It should be 2 instead of 1)
	Error getting first link ID for inode = 4421033 (result=32)
   Invalid first link in hard link chain (id = 4421033)
   (It should be 7230411 instead of 0)
	Error getting first link ID for inode = 4421840 (result=32)
   Invalid first link in hard link chain (id = 4421840)
   (It should be 7230419 instead of 0)
	Error getting first link ID for inode = 4422043 (result=32)
   Invalid first link in hard link chain (id = 4422043)
   (It should be 7230421 instead of 0)
	Error getting first link ID for inode = 4422691 (result=32)
   Invalid first link in hard link chain (id = 4422691)
   (It should be 7230427 instead of 0)
	Error getting first link ID for inode = 4422911 (result=32)
   Invalid first link in hard link chain (id = 4422911)
   (It should be 7230429 instead of 0)
   Orphaned directory hard link (id = 7230385)
   Orphaned directory hard link (id = 7230391)
UpdFolderCount: second SearchBTreeRecord failed (thread.parentID = 19, result = 32), just returning without complaint
UpdFolderCount: second SearchBTreeRecord failed (thread.parentID = 19, result = 32), just returning without complaint
	DoMinorRepair: Repair for type=542 failed (err=2).
** The volume Time Machine-Backups could not be repaired.
	volume type is pure HFS+
	primary MDB is at block 0 0x00
	alternate MDB is at block 0 0x00
	primary VHB is at block 2 0x02
	alternate VHB is at block 856014766 0x3305bfae
	sector size = 512 0x200
	VolumeObject flags = 0x07
	total sectors for volume = 856014768 0x3305bfb0
	total sectors for embedded volume = 0 0x00
	CheckHFS returned 2, fsmodified = 1
Code-Sprache: JavaScript (javascript)

In meinem Fall hat die Reparatur nicht geklappt, was man an der Zeile 90 gut erkennt:

The volume Time Machine-Backups could not be repaired.

Es gibt jedoch noch einen weiteren Befehl, der ebenfalls eine Weile benötigt, den man dann ausprobieren kann:

fsck_hfs -p /dev/disk3s2

Damit werden eigentlich nur normale Inkonsistenzen behoben, aber das kann manchmal wahre Wunder bewirken.

In meinem Fall war die Ausgabe dann die folgende:

   Executing fsck_hfs (version hfs-407.200.4).
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine-Backups
** Checking extents overflow file.
** Checking catalog file.
   Incorrect number of thread records
(4, 23290)
** Checking multi-linked files.
** Checking catalog hierarchy.
   Invalid directory item count
   (It should be 598264 instead of 598265)
   Invalid directory item count
   (It should be 109502 instead of 109504)
   Invalid volume directory count
   (It should be 483690 instead of 483780)
   Invalid volume file count
   (It should be 4061848 instead of 4062086)
   Incorrect folder count in a directory (id = 4416049)
   (It should be 11 instead of 13)
   Incorrect folder count in a directory (id = 4418368)
   (It should be 41 instead of 0)
   Incorrect folder count in a directory (id = 4418981)
   (It should be 41 instead of 0)
** Checking extended attributes file.
   Incorrect number of extended attributes
   (It should be 2818355 instead of 2818894)
   Incorrect number of Access Control Lists
   (It should be 2818277 instead of 2818826)
   Invalid leaf record count
   (It should be 10379778 instead of 10379768)
** Checking multi-linked directories.
** Checking volume bitmap.
   Volume bitmap needs repair for under-allocation
** Checking volume information.
   Invalid volume free block count
   (It should be 17692610 instead of 8239466)
   Volume header needs minor repair
(2, 0)
** Repairing volume.
** Rechecking volume.
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine-Backups
** Checking extents overflow file.
** Checking catalog file.
   Missing thread record (id = 4418368)
   Missing thread record (id = 4418981)
   Incorrect number of thread records
(4, 23290)
** Checking multi-linked files.
** Checking catalog hierarchy.
   Invalid volume directory count
   (It should be 483690 instead of 483780)
   Invalid volume file count
   (It should be 4061848 instead of 4062086)
   Incorrect folder count in a directory (id = 4418368)
   (It should be 41 instead of 0)
   Incorrect folder count in a directory (id = 4418981)
   (It should be 41 instead of 0)
** Checking extended attributes file.
** Checking multi-linked directories.
** Checking volume bitmap.
** Checking volume information.
** Repairing volume.
   Missing directory record (id = 4418981)
   Missing directory record (id = 4418368)
** Look for missing items in lost+found directory.
** Rechecking volume.
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine-Backups
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
   Incorrect folder count in a directory (id = 2)
   (It should be 5 instead of 4)
   Incorrect folder count in a directory (id = 11714635)
   (It should be 2 instead of 0)
** Checking extended attributes file.
** Checking multi-linked directories.
** Checking volume bitmap.
** Checking volume information.
   Invalid volume file count
   (It should be 4062086 instead of 4061848)
   Invalid volume directory count
   (It should be 483783 instead of 483693)
** Repairing volume.
** Rechecking volume.
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine-Backups
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking multi-linked directories.
** Checking volume bitmap.
** Checking volume information.
** The volume Time Machine-Backups was repaired successfully.
Code-Sprache: JavaScript (javascript)

Wie am Ende zu sehen ist, war hier die Reparatur erfolgreich. Wenn nicht, kann man nochmal den ersten Reparaturbefehl nutzen:

fsck_hfs -drfy /dev/disk3s2

Danach sollte das Dateisystem wirklich repariert sein. Falls nicht, ist es in einer Art und Weise beschädigt, dass eine Reparatur nicht mehr möglich ist und ein neues Backup erstellt werden muss. Am besten entfernt man hier das Sparsebundle-Image manuell, sodass Time Machine wirklich ein komplett sauberes neu anlegt.

In meinem Fall sah die Ausgabe dann folgendermaßen aus:

journal_replay(/dev/disk3s2) returned 0
** /dev/rdisk3s2
	Using cacheBlockSize=32K cacheTotalBlock=65536 cacheSize=2097152K.
   Executing fsck_hfs (version hfs-407.200.4).
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine-Backups
** Checking extents overflow file.
** Checking catalog file.
** Rebuilding catalog B-tree.
hfs_UNswap_BTNode: invalid node height (1)
** Rechecking volume.
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine-Backups
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking multi-linked directories.
	privdir_valence=109502, calc_dirlinks=309507, calc_dirinode=109502
** Checking volume bitmap.
** Checking volume information.
** The volume Time Machine-Backups was repaired successfully.
	CheckHFS returned 0, fsmodified = 1
Code-Sprache: JavaScript (javascript)

Überprüfungsstatus zurücksetzen

Zu guter Letzt muss im Time-Machine-Backup selbst der Status der letzten Überprüfung zurückgesetzt werden. Andernfalls ist Time Machine nach wie vor der Auffassung, dass ein neues Backup angelegt werden muss, auch wenn alle Fehler korrigiert wurden.

Dazu muss man das Sparsebundle-Image öffnen. Je nach Größe kann das im Finder einige Minuten dauern, in denen es keine Rückmeldung gibt. Daher empfehle ich, sofern möglich, das Image direkt auf dem jeweiligen Netzlaufwerk (beispielsweise NAS) zu öffnen. Dort findet man direkt auf der ersten Ebene die Datei com.apple.TimeMachine.MachineID.plist. Deren Inhalt müsste etwa folgendermaßen aussehen:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>RecoveryBackupDeclinedDate</key>
	<date>2019-07-05T19:40:26Z</date>
	<key>VerificationDate</key>
	<date>2019-07-05T19:39:50Z</date>
	<key>VerificationExtendedSkip</key>
	<false/>
	<key>VerificationState</key>
	<integer>2</integer>
	<key>com.apple.backupd.HostUUID</key>
	<string>C361AD5E-10AE-533B-9E58-BA73E2A5D840</string>
	<key>com.apple.backupd.ModelID</key>
	<string>MacBookPro14,3</string>
</dict>
</plist>
Code-Sprache: HTML, XML (xml)

Hier muss zuerst der VerificationState geändert werden, dessen Wert in Zeile 12 mit 2 festgelegt ist. Dieser Wert muss auf 0 geändert werden.

Außerdem müssen die Zeilen 5 und 6 entfernt werden, die angeben, wann das Backup als nicht erfolgreich überprüft eingestuft wurde.

Abgeändert sieht die Datei bei mir dann folgendermaßen aus:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>VerificationDate</key>
	<date>2019-07-05T19:39:50Z</date>
	<key>VerificationExtendedSkip</key>
	<false/>
	<key>VerificationState</key>
	<integer>0</integer>
	<key>com.apple.backupd.HostUUID</key>
	<string>C361AD5E-10AE-533B-9E58-BA73E2A5D840</string>
	<key>com.apple.backupd.ModelID</key>
	<string>MacBookPro14,3</string>
</dict>
</plist>
Code-Sprache: HTML, XML (xml)

Dateisystem aushängen

Um das Sparsebundle-Image nun wieder als Backup-Laufwerk verwenden zu können, muss es erst am lokalen System ausgehängt werden. Das geht mit folgendem Befehl:

hdiutil detach /dev/disk3s2

Backup manuell ausführen und automatische Datensicherung wieder aktivieren

Nun ist das Time-Machine-Sparsebundle wieder vollständig einsatzbereit und kann genutzt werden. Es bietet sich an, das Backup nun einmal manuell zu starten. Lief das erfolgreich durch, kann man auch die automatische Datensicherung wieder aktivieren.

Das erste Backup dauert für gewöhnlich wesentlich länger als normal, da das gesamte Backup erneut geprüft wird. Außerdem kann es wesentlich größer sein (bei mir 80 GB statt der normalen ~800 MB).

54 Kommentare zu “Time-Machine-Backup/-Sparsebundle reparieren

    1. Ich kann nur mutmaßen: Vermutlich ist die Oberfläche nur für einfache Operationen gedacht.
      Denn das ist es wahrscheinlich, was du meinst. Denn in macOS selbst ist es ja durchaus integriert – nur mit zusätzlichen manuellen Befehlen.

  1. Vielen Dank für die wirklich hilfreiche und verständliche Erklärung. Wie hier in der Erklärung angeführt, Reparaturversuch Nr. 2 (fsck_hfs -p /dev/disk3s2) hat bei mir dann funktioniert und das Time Machine Backup läuft wieder! Danke.

    1. Abgesehen davon, dass sich das Format bei meinem bestehenden Backup nicht geändert hat, gehe ich nicht davon aus, dass sich die grundlegende Funktionalität von Time Machine (und um die geht es hier) grundlegend geändert hat.

  2. Vielen Dank and den Erzeuger, hat auch bei mir (alter Mac Mini macOS 10.14.6 als TM-Server, Macbook auf 10.15.5 als TM-Client) prima funktioniert und ich gerettet.

    Bei aktuellem OS: einfach im obigen Rezept .sparsebundle durch .backupbundle ersetzen. Wer die .plist-Datei nicht findet, man muss sich zuerst mit Rechtsklick auf „Paketinhalt anzeigen“ in das Bundle hereinarbeiten.

    Als Ergänzung würde ich empfehlen, vom TM-Client aus eine manuelle Backup-Überprüfung anzustoßen, bevor man sich wieder blind auf die Integrität der Backups verlässt. Schließlich überlistet man ja durch die Änderung des Integer-Werts zurück auf 0 die TM und behauptet, die Integrität sei (wieder) gewährleistet, was aber de facto durch das Festplattendienstprogramm wie hier verwendet nicht garantiert werden kann.

  3. Ich konnte der Anleitung als Laie gut folgen – Dateisystem war clean. Hänge jetzt aber im letzten Schritt (*hdiutil detach /dev/disk3s2*) und wollte mal nachfragen, bevor ich etwas kaputt mache:

    Bei mir sieht es jetzt unter hdiutil attach -nomount -noverify -noautofsck /Volumes/{Netzlaufwerk}/{name}.backupbundle so aus:

    /dev/disk2 GUID_partition_scheme
    /dev/disk2s1 EFI
    /dev/disk2s2 Apple_HFS /Volumes/Time Machine-Backups

    Muss ich dann eventuell einfach dort „*hdiutil detach /dev/disk2s“ ausführen, weile s bei mir kein „disk3s2“ gibt? Würde mich über einen Hinweis freuen.

      1. Ich war offenbar voreilig: Leider hat es doch nicht geklappt.

        Das Volume wurde bei mir zwar als „clean“ gemeldet, der Versuch des manuell angestoßenen Backups ist aber mehrfach abgebrochen. Er startet zwar normal, überträgt offenbar auch Daten, bricht dann aber immer ab.

        Weitere Beobachtungen:

        Über Time Machine kann ich zwar auf die so erstellen Backups zugreifen. Die ältere sind dagegen zwar sichtbar, lassen sich aber nicht anwählen.

        Im fsck_hfs.log wird ein „No Write“ gemeldet.

        „/dev/rdisk2s2: fsck_hfs started at Tue Aug 18 09:47:15 2020
        /dev/rdisk2s2: /dev/rdisk2s2: ** /dev/rdisk2s2 (NO WRITE)
        /dev/rdisk2s2: Executing fsck_hfs (version hfs-522.100.5).
        QUICKCHECK ONLY; FILESYSTEM CLEAN
        /dev/rdisk2s2: fsck_hfs completed at Tue Aug 18 09:47:15 2020“

        Beim Versuch, im Ordner, der auch das Backupbuntle enthält, hdiutil attach -nomount -noverify -noautofsck laufen zu lassen, erscheint jetzt der Hinweis „attach failed – Die Ressource ist zeitweilig nicht verfügbar“

        Dafür erscheint jetzt unter Volumes noch zusätzlich „Time Machine-Backups“ (bin mir nicht sicher, ob das vorher auch schon da war).

        1. Bricht das Backup denn mit einer Fehlermeldung ab? Kann es vielleicht sein, dass kurzzeitig die Verbindung zum Backup verloren geht, sofern sie über das Netzwerk angeschlossen ist?

          Hast du einmal deinen Mac neu gestartet, um sicherzugehen, dass kein anderer Prozess noch auf das Backup zugreift?

          1. Ich habe noch mal nachgesehen (und neu gestartet, obwohl ich das vorher mW auch schon mal gemacht hatte): Das manuelle Backup lief nun durch. Beim „VerificationDate“ in com.apple.TimeMachine.MachineID.plist erschien auch das aktuelle Datum.

            Wenn man Time Machine öffnete, dauerte das Laden der früheren Versionen zwar lange, aber sie ließen sich auch ansteuern.

            In der Systemeinstellung Time Machine wurde die Platte jedoch weiter mit rotem „i“ markiert und nur das Datum des letzten erfolgreichen Backups vor dem Auftreten des Fehlers angezeigt.

            Aber, o Wunder, nachdem Aktivieren des automatischen Backups gab es im zweiten Versuch dann auch eine problemlosen Durch und die Warnung verschwand auch in der Systemeinstellung.

  4. Hallo ,
    ich habe auch ein Problem mit meinen TM Backup. Mit einem Mal will er ein neues *.backupbundle anlegen und lässt das bestehende links liegen (Habe MacOS Catalina)…
    Bei „hdiutil attach“ kommt:
    „hdiutil: attach failed – Image nicht erkannt“
    Ich habe dem Terminal bereits Festplattenvollzugriff gewährt und die Befehle mit sudo ausgeführt.

    Ich wäre über jeden Tip dankbar. Gruß Jan

        1. Hab Dank für die schnelle Antwort 🙂 aber ich glaube ich bekomme es einfach nicht mehr hin … nun sagt er mir: already specified

          Rolands-iMac:time machine ordner root# hdiutil attach -nomount -noverify -noautofsck /Volumes/time\ machine\ ordner /Rolands\ mac.purgeable.sparebundle
          hdiutil: attach: extra image argument „/Rolands mac.purgeable.sparebundle“ – „/Volumes/time machine ordner“ already specified
          Usage: hdiutil attach [options]
          hdiutil attach -help

  5. Hallo, ich habe auch eine womöglich, defektes Backup. Und hänge beim einhängen fest.

    Rolands-iMac:time machine ordner root# hdiutil attach -nomount -readwrite -noverify -noautofsck Rolands\ Mac.purgeable.sparsebundle
    hdiutil: attach failed – Es existiert keine Datei und kein Ordner dieser Art

    … doch sie existiert!

    Kann jemand meinen Fehler sehen, den ich mache?

  6. Hallo,
    vielen Dank für die Anleitung. Ich konnte dadurch mein Backup auf einer Airport Time Capsule mit ca. 5 Jahren Historie retten. Ich bin total glücklich darüber. Bei mir hat der Reparaturprozess ca. 30h gedauert (trotz Gigabit und MacBook Pro 16 i9) – also einfach die individuelle Größe des Backups berücksichtigen und Geduld zeigen.
    Nochmals danke!
    Viele Grüße
    Yannick

  7. Hallo,
    ich habe ein Problem mir der Lesbarkeit älterer Sicherungen.
    Ich nutze einen Mac mini um vier IMACs zentral auf einer Freigabe „Backup“ mit der Timemachine zu sichern.
    Wir haben einen iMac durch einen neuen ersetzt. Dann kam die Frage, ob der neue Mac den Timemachineverlauf übernehmen soll, den haben wir bejaht.
    Erst nach dem Umstieg auf Big Sur vor zwei Wochen hatten wir das Problem die Timemachine nutzen zu müssen.
    Im Verlauf können wir auf die letzten zwei Wochen zugreifen, der Rest bis Anfang 2018 erscheint zwar, ist aber grau.
    Wie können wir auf eine ältere Datei zuzugreifen?
    Oder gibt es eine Möglichkeit das .backupbundle auszupacken, dass die einzelnen Tage erscheinen, wie einer lokalen Timemachine?

    Das .backupbundle konnte ich auf eine externe USB-Platte kopieren und wollte es lokal nutzen. Geht aber nicht.

    Gibt es dazu einen Rat?

  8. Vielen Dank für die tolle Anleitung! Im Gegensatz zu anderen Quellen im Netz bezieht sich auf aktuelle mac os Versionen und ist auf Deutsch :-). Ich habe nur eine Ergänzung / Frage: Da die Überprüfung des Time Machine sparsebundels ja sehr lange Zeit in Anspruch nehmen kann, wird in einem (recht alten) Artikel https://hints.macworld.com/article.php?story=20110829063745320 empfohlen fsck_hfs mit dem Parameter „-c 2200m“ aufzurufen um ihm 2GB cache zu gönnen und die Verarbeitung dadurch zu beschleunigen. In der Anleitung hier wird dieser Parameter nicht benutzt, aber aus der Ausgabe geht hervor, dass durchaus ein größerer cache verwendet wird: „Using cacheBlockSize=32K cacheTotalBlock=65536 cacheSize=2097152K.“
    Bedeutet das, dass inzwischen der größerer cache die Voreinstellung ist?

    1. Wird keine Cache-Größe angegeben, wird diese automatisch anhand des verfügbaren Arbeitsspeichers berechnet. Daher kommt es hier auf das jeweilige System an, wie viel Arbeitsspeicher automatisch dafür verwendet wird.

  9. Danke für die super Anleitung. Konnte schon zwei mal mein Backup dadurch reparieren und weiter nutzen. Dieses Mal scheint es aber Schwierigkeiten zu geben. Ich folge den Schritten wie oben beschrieben.

    Sobald ich /var/log/fsck_hfs.log eingebe komme ich nicht weiter. Als Antwort bekomme ich: -bash: /var/log/fsck_hfs.log: Permission denied

    Beim ersten Mal habe ich diese Nachricht ignoriert und einfach mit den anderen Schritten weitergemacht. Das Backup konnte dadurch allerdings nicht repariert werden.

    Hat jemand Ahnung der Erfolg tatsächlich von den Zugriffsrechten abhängig sein kann und wie ich die evtl. bekomme?

      1. Danke. Als Antwort bekomme ich sudo: /var/log/fsck_hfs.log: command not found

        Sobald ich den Befehl ohne sudo eingebe, kommt wieder permission denied

  10. Moin in die Runde! Ich hatte schon mal erfolgreich vor einigen Monaten mit den Schritten oben mein Backup repariert. Jetzt habe ich erneut Probleme, kann aber nicht reparieren, da diese Meldung erscheint. Weiß jemand zu helfen?

    Yannick$ fsck_hfs -drfy /dev/disk2s2
    journal_replay(/dev/disk2s2) returned 0
    ** /dev/rdisk2s2
    Using cacheBlockSize=32K cacheTotalBlock=65536 cacheSize=2097152K.
    Executing fsck_hfs (version hfs-556.60.1).
    ** Checking Journaled HFS Plus volume.
    Invalid extent entry
    (4, 0)
    CheckExtRecord: id=4 1:(471288,0), (blockCount == 0)
    ** The volume could not be verified completely.
    volume check failed with error 7
    volume type is pure HFS+
    primary MDB is at block 0 0x00
    alternate MDB is at block 0 0x00
    primary VHB is at block 2 0x02
    alternate VHB is at block 5855666958 0x15d06630e
    sector size = 512 0x200
    VolumeObject flags = 0x07
    total sectors for volume = 5855666960 0x15d066310
    total sectors for embedded volume = 0 0x00
    CheckHFS returned -1317, fsmodified = 0

    Es steht was von Error 7 und invalid extent entry.
    Danke im Voraus!!!
    Yannick

      1. Danke für deine Hilfe Matthias! Leider hat der Befehl auch nicht den gewünschten Erfolg geliefert. Ich befürchte, dass es doch eher die Festplatte ist, die nach über 35000 hdd power on hours, das zeitliche segnet. Danke für die Hilfe!

  11. Hallo Matthias, herzlichen Dank für diese super Anleitung. Das hat mein Backup (eines von 3 🙂 gerettet. Woher weißt du denn das alles ?

    Auch wenn ich die Wertschätzung nicht materiell ausdrücken kann … auf jeden Fall herzlichen Dank für dein selbstloses (und Nag-freies) Teilen.

    lg B.

  12. Hallo Matthias,

    ich bekomme diese Fehlermeldung seit dem Update auf MacOS 11.3 (also erst seit drei Tagen).

    Ist die oben beschriebene Vorgehensweise (klingt für mich alles ziemlich kompliziert) hier genauso, um den gesamten Backup-Verlauf (immerhin einige Jahre) zu retten & nicht zu verlieren?

    Vielen Dank & VG

    Carsten

  13. Wenn „Unable to open block device“ trotz Festplattenvollzugriff für fsck_hfs als Fehlermeldung ausgegeben wird: auch das Terminal (also die App) muss Festplattenvollzugriff haben.

  14. Vielen Dank!
    Dies ist eine wirklich hilfreiche und verständliche Erklärung.
    Hat bei mir alles funktioniert und das Time Machine Backup läuft wieder!

    Saved my day!

    Danke!

  15. Hi,

    nach einem Crash ist mein Fusion Drive defekt und musste erneut gebildet werden = alle Daten weg. Nun habe ich das Problem, dass Time Maschine das Backup nicht zur Wiederherstellung anbietet. Das backupbundle liegt auf dem NAS, ich habe die oben beschriebenen Schritte durchgeführt und der Status wird als FILESYSTEM CLEAN angezeigt. Die plist-datei habe ich ebenfalls angepasst, auch die Host UUID stimmt und trotzdem tauch das Backup nicht in der Liste auf.

    Für jegliche Ideen bin ich empfänglich, ich brauche nämlich einige Daten zurück.

  16. Danke für die Anleitung, hat erstmal super funktioniert!

    Hab das backupbundle wieder herstellen können und es erscheint nun als clean. Jetzt kommt aber folgende Meldung: „Time Machine kann das Image nicht verwenden, da es schreibgeschützt ist.“.

    Im Finder steht es als geschützt, kann den Haken aber nicht rausnehmen!? Im Terminal und auf der NAS geht das irgendwie auch nicht … Hast Du noch eine Idee?

  17. Ein Neustart von iMac und NAS hat auch nichts gebracht 🙁

    Aber muss man den Schreibzugriff aus dem ersten Schritt (chflags -R nouchg) eigentlich nicht wieder zurücksetzen? Bin da nicht so firm in den Berechtigungen …

    Hecot

    1. Da bin ich mir jetzt auch nicht zu 100 % sicher, allerdings dürfte das dein Problem nicht lösen, denn dieser Befehl gibt dir explizit Berechtigung zum Schreiben.
      Kannst du einmal ein neues Backup auf einem anderen Volume anlegen und die Berechtigungen dann vergleichen?
      Hast du über den Finder Zugriff auf das Verzeichnis, in dem sich das aktuelle Sparsebundle befindet und kannst du in dieses Verzeichnis neue Dateien legen?

  18. Neue Dateien im Finder ließen sich auf dem Volume anlegen, das war kein Problem.

    Ich vermute, dass dort ein extended attribute oder auch ein ACL auf dem backupbundle drauf ist, was man ja an dem @ bei den Berechtigungen schon sieht.

    Um diese zu löschen habe ich folgende Befehle versucht:

    sudo xattr -rc iMac.backupbundle/
    sudo chmod -R -N iMac.backupbundle/

    Leider brach im Terminal nach einer Weile immer die SMB Verbindung ab, per SSH auf der NAS kannte diese Befehle nicht.

    Das Problem lies sich also nicht lösen und ich habe dann letztendlich das backupbundle per SSH und rm -r gelöscht und TM neu gestartet. Jetzt schnurrt das TM Backup wieder ganz prima 🙂

    Was sehr seltsam ist und zwar heisst das neu angelegte Bundle wieder SPARSEbundle und nicht wie vorher BACKUPbundle??? Habe BigSur 11.5.2 drauf … keine Ahnung was dort los ist!?

  19. Hallo,
    hab versucht ein defektes TM Backup wiederherzustellen –
    nach dem Befehl „fsck_hfs -drfy“ kommt immer wieder der Fehler : (NO WRITE) Can’t get device block size
    Die Datei /sbin/fsck_hfs in den Systemeinstellungen unter Sicherheit > Datenschutz > Festplattenzugriff wurde hinzugefügt. Mehrere Neustartes halfen auch nicht.
    weiß vielleicht jemand weiter?
    LG
    Denny

Schreibe einen Kommentar zu Martin Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert