macOS High Sierra Time Machine backups.backupdb auf neue Festplatte kopieren klappt nicht

[john_j]

Hi,

ich möchte meine alte 4TB USB-Platte durch eine neue ersetzen. Auf der alten sind noch ca. 360GB frei, d.h. das sollte problemlos auf eine neue 4TB-Platte passen. Vorgegangen bin ich wie von Apple gewünscht (https://support.apple.com/de-de/HT202380), also neue Platte vorbereiten und backups.backupdb mit dem Finder auf die neue Platte kopieren.

Das ganze dauert sehr lange (OK, große Datenmengen), aber irgendwann kommt ein Fehler, dass nicht genug Festplattenspeicher zum Kopieren da sei. Ich habe mal ein bisschen probiert und geforscht und vermute nun, dass beim Kopieren die Hardlinks aufgelöst werden, also in jedem Backup-Verzeichnis das Gesamtbackup liegt und nicht nur das Delta.

Hat jemand eine Idee, das Problem zu beheben oder einen alternativen Kopierweg, der die Hardlinks erhält (z.B. Terminal)?

bg, Heiko

 

[Isegrim242]

Klon' die Platte doch vielleicht lieber per Festplattendiebstprogramm oder CCC o.ä.

 

[john_j]

Das geht leider nicht - ccc weist selbst darauf hin, dass es keine TC-Festplatten kopieren kann und man dem Apple-Weg folgen soll. Ich meine Festplattendienstprogramm kann das ebensowenig.

 

[oneOeight]

https://support.apple.com/de-de/HT202380

das sagt man soll es über den finder kopieren

 

[john_j]

Ähm, ja, lies mal das Ursprungsposting...

 

[oneOeight]

ja, hatte ich gelesen, deswegen ja das zwinkern, da apple was vorschlägt was nicht funktioniert.

vielleicht hilft dir ditto oder rsync im terminal?
die können hardlinks erhalten.

 

[CyberTom]

https://superuser.com/questions/1055656/time-machine-size-explodes-when-copied-to-new-drive

dd sollte helfen wenn die beiden Festplatten die gleiche Größe haben. Das Problem bei anderen *nix-Tools ist dass das TimeMachine-Backup nicht nur für Dateien Hardlinks nutzt sondern auch für Verzeichnisse.

Vielleicht ist das generell die sinnvollste Methode das Backup auf eine neue Festplatte zu bringen: eine Partition der gleichen Größe erstellen, mit dd kopieren und danach die Partition auf die gewünschte Größe verändern.

 

[rpoussin]

Beim Kopieren über den Finder kann es helfen, alle Programme zu beenden und das Netzwerk zu deaktivieren.

 

[john_j]

dd sollte helfen wenn die beiden Festplatten die gleiche Größe haben. ...

Danke für den Link! Aktuell läuft noch ein Versuch via Finder. Wenn der wieder fehlschlägt, werde das mal mit dd testen und berichten. Wird aber ein paar Tage dauern - schnell ist das ganze bei den Datenmengen und vor allem den zig Millionen Dateien, die der Finder erst alle abzählen muss, nicht...

 

[john_j]

Hallo zusammen,

hier mal der aktuelle Stand: Mühsam ernährt sich das Eichhörnchen.

Der Finder hat es natürlich wieder nicht gepackt. Also bin ich dem Vorgehen in https://superuser.com/questions/1055656/time-machine-size-explodes-when-copied-to-new-drive gefolgt:

1. diskutil list will list the volume's device identifiers (e.g. disk2s3 is the third slice (partition) of physical disk #2)
2. diskutil info <sourcevolumeid> will list the source volume size in bytes (along with lots of other info)
3. diskutil resizeVolume <targetvolumeid> <sourcevolumesize>B (the "B" means "bytes" -- see the "SIZES" section of the diskutil man page).
4. diskutil unmount <sourcevolumeid> and diskutil unmount <targetvolumeid> -- don't use dd on mounted volumes!
5. sudo dd if=/dev/r<sourcevolumeid> of=/dev/r<targetvolumeid> to do the copy. Note the "r" prefix on the device names -- this bypasses the OS disk buffers, and in my experience makes dd run much faster. Be very careful to get the volume IDs right, or you may copy a blank volume over your backup!
6. Finally, use either diskutil resizeVolume or Disk Utility to expand the target volume out to the full disk's size.

Das scheint zu klappen, aber Terminal schweigt so vor sich hin. Abhilfe schafft ctrl+t, womit man jederzeit den aktuellen Status abrufen kann. Als Ergebnis kommt dann so etwas:

1469101+0 records in
1469100+0 records out
752179200 bytes transferred in 460.667845 secs (1632802 bytes/sec)
​

Die Bytes rechnet man in MB und GB um und stellt fest, dass das laaaaaangsam ist: 1,6 MB/s ist noch viel langsamer als der Finder, da brauche ich für 3,5TB locker 3-4 Wochen. Also habe ich mal gegoogelt und bin auf diesen Blogartikel gestoßen: https://blog.netways.de/2015/05/05/mac-os-x-dd-schneller-und-mit-fortschrittsanzeige/

Also hänge man einfach "bs=8m" an den Befehl (5.)

5. sudo dd if=/dev/r<sourcevolumeid> of=/dev/r<targetvolumeid> bs=8m

und statt 1,6MB/s kommt man auf 55-80MB/s. Damit war das Kopieren dann in gefühlt 1,5 Tagen durch, d.h. deutlich schneller als der Finder.

Jetzt der Haken: Die Zielfestplatte ist immer noch leer. Nach einem Reboot kann ich sie auch nicht aktivieren. Im Festplattendienstprogramm sehe ich die Partition, auf die ich kopiert habe, mit der korrekten Kapazität von 4TB, davon 0kb verfügbar (es müssten aber ca. 350GB verfügbar sein).

Sehr seltsam. Vielleicht liegt die Lösung in einem kleinen Hinweis in https://superuser.com/questions/1055656/time-machine-size-explodes-when-copied-to-new-drive:
"If they are (e.g. if they're encrypted), things get a bit more complicated."

Meine Quell-HDD ist leider verschlüsselt :-( Ich könnte sie jetzt entschlüsseln (dauert wieder x Tage) und danach noch einmal kopieren, um dann auf das nächste Problem zu stoßen oder am Ende festzustellen, dass das Backup durch die Entschlüsselung unbrauchbar geworden ist. Also lasse ich es und nehme es mit der bei Apple zunehmend notwendig gewordenen Gelassenheit hin - man kann nicht mehr erwarten, dass die Dinge funktionieren. Machen wir doch einfach ein neues Backup, wen interessieren schon die Daten von gestern :-(

bg, Heiko