Reparieren Sie das Sparsebundle von Time Machine, das nicht mehr gemountet werden kann

Ich habe in meinem Blog einen Artikel darüber geschrieben, wie man versucht, NAS-basierte Sparsebundle-Fehler zu beheben . In Summe:

1. hdiutil attach -nomount -noverify -noautofsck /Volumes/{name of your disk}/{name of}.sparsebundle

   Sie sehen dann so etwas wie

   /dev/diskx Apple_partition_scheme
   /dev/diskxs1 Apple_partition_map
   /dev/diskxs2 Apple_HFSX
   

   Wobei x die Festplatten-ID für die externe Festplatte ist. x kann 2, 3, 4 oder höher sein. Sie interessieren sich für das mit der Bezeichnung Apple_HFSX oder Apple_HFS.

2. fsck_hfs -drfy /dev/diskxs2Verwenden Sie das relevante Gerät, das in Schritt 1 gefunden wurde.

   Hoffentlich wirst du es irgendwann sehen

   Das Volume wurde erfolgreich repariert

3. hdiutil detach /dev/diskxs2

Seit OS X 10.6.3 weigert sich Time Machine jedoch, auf ein Zielvolume zu schreiben, dessen Überprüfung fehlschlägt. Selbst wenn der obige Prozess bei der Wiederherstellung des Backups erfolgreich ist, müssen Sie möglicherweise noch die schwarzen Markierungen entfernen, die Time Machine geschrieben hat, als die Überprüfung fehlgeschlagen ist.

4. Schalte das Sparsebundle frei

   chflags -R nouchg /Volumes/{name of your disk}/{name of}.sparsebundle
   

5. Verschieben Sie es zurück an seinen ursprünglichen Ort

   mv /Volumes/{name of your disk}/{name of}_YYYY-MM-DD.sparsebundle /Volumes/{name of your disk}/{name of}.sparsebundle
   

6. Bearbeiten Sie im obersten Verzeichnis des Sparsebundle die Datei com.apple.TimeMachine.MachineID.plist.

   • Entfernen

     <key>RecoveryBackupDeclinedDate</key>
     <date>{whatever-the-date}</date>
     

   • Veränderung

     <key>VerificationState</key>
     <integer>2</integer>
     

     zu

     <key>VerificationState</key>
     <integer>0</integer>
     

Erweiterte Attribute im Sparsebundle verhindern möglicherweise Schreibvorgänge in der Datei:

Laufen

chflags -R nouchg flattop.sparsebundle

Aber seien Sie vorsichtig, das Sparsebundle wurde möglicherweise geschützt, weil es wirklich kaputt ist.

Es ist nicht so einfach wie chmod. Erstens scheint es, dass 10.5 / 10.6 / 10.7 alle geringfügige Unterschiede in der Handhabung eines Sparse-Bundles aufweisen. Zweitens werden die Flags und der Dirty/Bad-Status eines Sparse-Bündels woanders gespeichert. Drittens müssen Sie möglicherweise das Sparse-Bundle selbst angreifen - nicht das darin enthaltene Dateisystem.

Am besten lassen Sie das Festplattendienstprogramm das Image reparieren, bevor Sie sich das darin eingebettete Dateisystem ansehen. Es funktioniert sowohl auf dem Bundle als auch auf den Dateisystemen - und weiß, wie Apple Dinge gespeichert hat.

Die Details des Pakets sind entweder proprietär oder aus den Entwicklerdokumenten schwer zu erkennen – und es ist sicherlich nichts, was andere Dienstprogramme von Drittanbietern an dieser Stelle gerne beheben würden. Solange Sie eine gleiche oder neuere Version des Festplatten-Dienstprogramms verwenden als der Mac, der die Backups erstellt hat, sollte es Ihnen gut gehen. Sobald Sie das Festplattendienstprogramm aufgegeben haben, können Sie etwas wie Drive Genius oder Disk Warrior ausprobieren, aber ich würde bei Apples Tool bleiben, wenn Sie hoffen, dieses Paket wiederzuverwenden.

Die Natur von Sparse-Bundles – insbesondere die festen Links sowie das Konzept, dass es nicht komprimiert wird, wenn Dateien gelöscht werden – es gibt viel zu tun . Ich habe DiskUtility zwei Wochen lang laufen lassen und immer noch keinen Reparaturdurchlauf für ein 800 MB großes Archiv abgeschlossen.

In der Praxis ist es möglicherweise besser, einfach zu einer früheren Version Ihres NAS zurückzukehren, wenn es Snapshots enthält oder selbst gesichert ist. Am Ende - wenn es Fehler gibt, die fsck/Disk Utility nicht beheben kann, wird Ihr Sparse-Bundle als fehlerhaft markiert und gesperrt. Sie können dann Dinge lesen, aber nie wieder dazu schreiben. Sehen Sie nach, ob Sie eine Maschine mit dem Speicher verbinden und Dinge reparieren können (DAS oder Hochgeschwindigkeitsverbindungen sind besser - ebenso wie eine Maschine, die die Zeit hat, Dinge zu reparieren und nicht neu gestartet zu werden, ideal ist)

Viel Glück - dies kann möglicherweise nicht anhand der von Ihnen angegebenen Details wiederhergestellt werden.

@ Garths Antwort hat bei mir nicht funktioniert. Ich musste die -readwriteOption hinzufügen hdiutil, damit sie für mein verschlüsseltes Bild funktioniert. Ohne diese Option wird hdiutilnicht nach dem Passwort gefragt.

Beim fsck-Schritt stieß ich auf eine Disk full error. Um das zu beheben, habe ich die resizeOption zum Vergrößern der Bildgröße vor dem Ausführen von fsck verwendet.

Hier sind die Befehle, die ich verwendet habe, um es zu beheben:

# chflags -R nouchg MyImage.sparsebundle

# hdiutil attach -nomount -noverify -readwrite -noautofsck MyImage.sparsebundle
Enter the password to access „MyImage.sparsebundle“: 
/dev/disk2              GUID_partition_scheme           
/dev/disk2s1            EFI                             
/dev/disk2s2            Apple_HFS                       

# hdiutil resize -size 1.5t MyImage.sparsebundle
Enter the password to access „MyImage.sparsebundle“: 

# fsck_hfs -drf /dev/disk2s2
** 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.
…

# hdiutil detach /dev/disk2s2

Wie in den anderen Antworten erläutert, kann der Gerätepfad variieren, sodass Sie stattdessen die vom Befehl disk2s2gedruckte Festplatte verwenden müssen . hdiutil attachAußerdem benötigen Sie den resizeSchritt nur, wenn Sie Disk full errorbeim Ausführen des fsck_hfsBefehls den erhalten haben. Außerdem sollten Sie anstelle von my 1.5teine vernünftige neue Größe eingeben, die nur geringfügig größer ist als Ihre aktuelle Bildgröße (überprüfen Sie mit du -hs MyImage.sparsebundle).

Ich habe ein Synology NAS und bekam den NO-WRITE-Fehler, als ich versuchte, den Fix auszuführen, aber ich bin auf diese optimierte Version gestoßen , die meinen Speck gerettet hat:

1. Deaktivieren Sie Time Machine-Sicherungen, damit der Reparaturvorgang nicht beeinträchtigt wird:tmutil disable
2. Mounten Sie die SMB/AFP-Freigabe, die das Sparsebundle enthält: mkdir /Volumes/TimeMachine ; mount_afp afp://ReadyNAS:<pass>@<ip-address>/ReadyNAS /Volumes/TimeMachine(alternativ mounten Sie die Freigabe im Finder)
3. Setzen Sie die Flags auf dem von Time Machine gesetzten Sparsebundle zurück, das verhindert, dass es geschrieben wird:chflags -R nouchg /Volumes/TimeMachine/<my-backup>.sparsebundle
4. Hängen Sie das Sparsebundle read-write an: hdiutil attach -nomount -readwrite -noverify -noautofsck /Volumes/TimeMachine/<my-backup>.sparsebundle. Sie sollten eine Ausgabe ähnlich der folgenden erhalten:

/dev/disk2              GUID_partition_scheme
/dev/disk2s1            EFI
/dev/disk2s2            Apple_HFS

5. Führen Sie unter Verwendung des letzten Eintrags der Ausgabe fsck: aus fsck_hfs -dy /dev/rdisk2s2. Um die Reparatur zu beschleunigen, können Sie angeben, dass Sie fsckmehr Arbeitsspeicher verwenden sollen: -c 8gwenn Sie 8 GB freien Arbeitsspeicher usw. haben. Optional können Sie ausführen fsck_hfs -dy -Race /dv/rdisk2s2, um den Katalog neu zu erstellen , nachdem Sie die anfängliche Reparatur ausgeführt haben (in meinem Fall hat das Ausführen der Neuerstellung vor der anfänglichen Reparatur den Dateisystem irreparabel).
6. Dann müssen wir Time Machine mitteilen, dass das Sparsebundle gut zu verwenden ist. Show contentsdes Sparsebundle, dann öffnen Sie die com.apple.TimeMachine.MachineID.plist:

• Entferne das:

<key>RecoveryBackupDeclinedDate</key>
<date>some-data</date>

• Ändere das:

<key>VerificationState</key>
<integer>2</integer>

• dazu:

<key>VerificationState</key>
<integer>0</integer>

7. Werfen Sie das Sparsebundle aus: hdiutil detach /dev/disk2und werfen Sie die Netzwerkfreigabe aus:umount /Volumes/TimeMachine
8. Aktivieren Sie die Time Machine-Sicherung erneut:tmutil enable

Hinweis: Die meisten Befehle müssen möglicherweise mit Root-Rechten ausgeführt werden. sudoAn den Befehl anhängen, wenn er fehlschlägt .

Laden Sie das Shell-Skript hier herunter . Auch unten angehängt. Muss als root ( sudo) ausgeführt werden.

if [[ $(whoami) != 'root' ]]; then
    exit 1
fi

read -p 'Enter Time Machine Hostname: ' HOSTNAME
read -p 'Enter Share: ' SHARE
read -p 'Enter Username: ' USERNAME
read -s -p 'Enter Password: ' PASSWORD

TM_NAME=$(hostname -s | sed -e 's/-/ /g')
MOUNT=/Volumes/TimeMachine
SPARSEBUNDLE=$MOUNT/$TM_NAME.sparsebundle
PLIST=$SPARSEBUNDLE/com.apple.TimeMachine.MachineID.plist

echo "Disabling Time Machine"
tmutil disable

echo "Mounting volume"
mkdir $MOUNT
mount_afp afp://$USERNAME:$PASSWORD@$HOSTNAME/$SHARE $MOUNT

echo "Changing file and folder flags"
chflags -R nouchg "$SPARSEBUNDLE"

echo "Attaching sparse bundle"
DISK=`hdiutil attach -nomount -readwrite -noverify -noautofsck "$SPARSEBUNDLE" | grep Apple_HFS | cut -f 1`

echo "Repairing volume"
#diskutil repairVolume $DISK
/sbin/fsck_hfs -fry $DISK

echo "Fixing Properties"
cp "$PLIST" "$PLIST.backup"
sed -e '/RecoveryBackupDeclinedDate/{N;d;}'   \
    -e '/VerificationState/{n;s/2/0/;}'       \
    "$PLIST.backup" \
    > "$PLIST"

echo "Unmounting volumes"
hdiutil detach /dev/$DISK
umount $MOUNT

echo "Enabling Time Machine"
tmutil enable

echo "Starting backup"
tmutil startbackup

exit 0

Ich habe alle oben genannten Schritte ausgeführt, aber nach einer Weile konnte das Image nicht mit fsck_hfs oder hdutil repariert werden, viele Fehler im Zusammenhang mit beschädigten Threads oder Knoten.

Was für mich funktionierte, war:

1. (Optional) Schließen Sie ein mit HFS Jornaled formatiertes externes USB-Laufwerk mit 1 TB an.

2. (Optional) Gehen Sie im Airport Utility zu Time Capsule Disks -> Archive Disk in das Laufwerk, das über USB mit Time Capsule verbunden ist. Für 600 GB habe ich 12 Stunden gebraucht.

3. hdiutil Attach -nomount -noverify -noautofsck /Volumes/DISK/MyFile.sparsebundle

4. Dann war die Festplatte mit DiskWarrior sichtbar . Klicken Sie auf der Registerkarte Verzeichnis auf Neu erstellen . Es dauerte etwa 1 Stunde.

Nach der Behebung konnte ich endlich meine Dateien mounten und sichern.

In meinem Fall habe ich meine Festplatten in meinem iMac ausgetauscht und ein Upgrade auf Big Sur durchgeführt. Nach dem Upgrade konnte ich nicht auf meine Time Capsule Time Machine-Sicherung zugreifen. Ich habe versucht, es zu mounten, habe aber den Fehler erhalten:

diskimagemounter erkennt Sparsebundle nicht

Ich bin einige der Schritte in diesem Beitrag durchgegangen und nichts hat so funktioniert wie erklärt. In den Kommentaren erwähnte jemand chmododer 777so etwas. Ich dachte mir, warum nicht versuchen, die Dateiberechtigungen zu reparieren. Also habe ich folgendes gemacht:

1. Navigieren Sie zu dem Laufwerk mit dem TimeMachine-Backup mit der Bezeichnung „[was auch immer der Benutzername war].sparsebundle“. Klicken Sie mit der rechten Maustaste und wählen Sie Informationen abrufen aus .

2. Klicken Sie unten im resultierenden Fenster auf das kleine Schloss und geben Sie Ihr Passwort ein, wenn Sie dazu aufgefordert werden.

3. Klicken Sie auf das [+] und wählen Sie Ihren Benutzer aus der Liste aus (möglicherweise befinden sich nur zwei Benutzer in der Liste: Ihr Benutzer und der Admin-Benutzer). Klicken Sie auf Auswählen .

4. Wählen Sie in der kleinen Spalte Privilege neben Ihrem Benutzernamen Read & Write .

5. Neben dem [+] befindet sich ein kleiner Kreis mit drei Punkten darin und einem Dropdown-Pfeil daneben. Wenn die Option zum Anwenden auf beiliegende Elemente vorhanden ist, wählen Sie sie aus. Andernfalls schließen Sie einfach das Fenster Get Info und versuchen Sie nun, auf die Time Machine-Datei „.sparsebundle“ zu doppelklicken.

Es wird jetzt hoffentlich auf Ihrem Desktop gemountet. Wenn Sie alle kleinen Laufwerke sehen, wählen Sie das mit dem Datum aus, auf das Sie zugreifen möchten. Navigieren Sie zu den Dateien, die Sie wiederherstellen möchten.

Wenn Sie ein Sparse-Bundle-Disk-Image auf einem Computer sichern und versuchen, es auf einem anderen zu öffnen, erhalten Sie möglicherweise die Fehlermeldung "keine mountbaren Dateisysteme", insbesondere wenn sich die Benutzernamen der Eigentümer auf den beiden Computern unterscheiden.

Meine Lösung bestand darin, das Bundle auf meine lokale Festplatte zu kopieren und auszuführen

sudo chown -R MyUserName nonmounting.sparsebundle

darauf.

Danach öffnete es sich gut und alles war in Ordnung mit der Welt.

Das hat bei mir funktioniert:

• Klicken Sie mit der rechten Maustaste auf das Disk-Image, ändern Sie "Jeder" in Lesen und Schreiben.
• Terminal öffnen
• chmod -R 777 {disk image path}

Es war anscheinend ein Berechtigungsproblem.

HINWEIS: DADURCH WIRD IHR BACKUP FÜR JEDEN ZUGÄNGLICH, DER PHYSIKALISCHEN ZUGRIFF DARAUF HAT

Ich hoffe, das kann jemandem helfen.

Ich wurde nach einem El Capitan-Sicherheitsupdate mit dem Fehler „kein montierbares Dateisystem“ aus meinem alten Dateitresorkonto ausgesperrt.

Was in meinem Fall funktionierte, war das Öffnen der Sparsebundle-Datei mit „Paketinhalt anzeigen“ aus dem Dropdown-Menü und das manuelle Ändern des Zugriffs für „Jeder“ von „Kein Zugriff“ auf „Lesen und Schreiben“ für jedes der enthaltenen Elemente. Für das Verzeichnis „Bands“ habe ich den Befehl „Auf eingeschlossene Elemente anwenden“ aus dem Dropdown-Menü verwendet.

Ich hatte ein ähnliches Problem mit einem Sparsebundle, das auf einem Windows-Rechner gehostet wurde. Ich habe alles in diesem und anderen Threads ausprobiert, was immer zu einem Fehler " Kein montierbares Dateisystem" führt (der auch einen 112-Fehler anzeigt).

Das Problem war Windows Defender, der eine der Dateien im Sparsebundle als Trojaner erkannte (Trojan:Script/Foretype.A!ml). Andere Leute haben ähnliche Fehlalarme gemeldet, wie Spotify-Cache oder von Rust kompilierte Dateien.

Um das Problem zu lösen, schließen Sie die Datei einfach aus der Windows Defender-Quarantäne aus und mounten Sie das Sparsebundle erneut. Es hat zu lange gedauert, daher können Sie mit diesem Befehl eine Ausgabe erhalten:

hdiutil attach -verbose -debug -mountpoint /mount/path /path/to.sparsebundle

Ich hatte gerade das gleiche Problem

** /dev/rdisk2s2 (NO WRITE)

beim Versuch, ein fehlerhaftes TM-Sparsebundle auf einem QNAP 419II zu reparieren.

Ich habe die TM-Halterung mit Finder "ausgeworfen" und ausgeführt

hdiutil attach -nomount -noverify -noautofsck ...

Befehl (hier zu finden Fix Time Machine Sparsebundle NAS Based Backup Errors ) erneut, der (im Gegensatz zum ersten Lauf, bei dem es "/dev/disk2s2 Apple_HFSX" ausgab) dieses Mal gab

/dev/disk1s2            Apple_HFSX  

Überprüfen Sie das Sys-Log mit

tail -f /var/log/fsck_hfs.log

Nein angezeigt

/dev/rdisk1s2: fsck_hfs run at Sun Feb 17 17:53:20 2013
/dev/rdisk1s2: ** /dev/rdisk1s2
/dev/rdisk1s2:    Executing fsck_hfs (version diskdev_cmds-540.1~34).
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
... LOTS-OF-OUTPUT ...
QUICKCHECK ONLY; FILESYSTEM CLEAN

Nichtsdestotrotz führte die erneute Aktivierung von TM immer noch zu einer Currepted-Backup-Nachricht :(

Viel Glück!