Hallo!
Die Idee ist, eine Partition (Windows, 40 GB, ~25 GB belegt, Rest mit "Nullfiles" beschrieben, diese gelöscht) auf einem USB-Stick (vfat) zu sichern. Da vfat maximal 4 GB Filegröße kann, muss also irgendwie noch ein split eingebaut werden, z.B.: dd if=dev/sda2 bs=1M | 7z a -si -so -an -tgzip -bsp2 | split -b3G - backup_sda2 für die "Hin-Richtung" und cat backup_sda2* | 7z e -si -so -an -tgzip -bsp2 | dd of=/dev/sda2 für das Restore.
Mir erschiene so etwas wie tar -L3G -vzf backup_sda2 /dev/sda2 irgendwie eleganter, da die -L Option split ersetzen könnte.
Allerdings komme ich mit der man-page von tar nicht klar. Die ist irgendwie so esoterisch formuliert (GNU-Style?), dass ich(!) nicht begreife, was nun eigentlich und wie gemacht werden muss. Gibt es in der Runde einen Erfahrungsträger?
Danke! Bernhard
Hallo Bernhard,
Die Idee ist, eine Partition (Windows, 40 GB, ~25 GB belegt, Rest mit "Nullfiles" beschrieben, diese gelöscht) auf einem USB-Stick (vfat) zu sichern.
...
Allerdings komme ich mit der man-page von tar nicht klar. Die ist irgendwie so esoterisch formuliert (GNU-Style?), dass ich(!) nicht begreife, was nun eigentlich und wie gemacht werden muss.
- 'tar -L' erfordert '-M' und ist für Wechselmedien (Tapes), wird also interaktiv nach neuen Dateinamen fragen - Deine Idee mit 'split' ist dann doch nicht verkehrt 'tar -cf - /dev/sda2 | split -b 3G - /ziel.datei.auf.vfat' - so werden aber die 15GB Nullen nicht wegrationalisiert, also sollte ein 'gzip -1 |' vor das 'split' - da Du nun aber eigentlich kaum features von tar nutzt, könnte 'dd bs=xx' performanter sein und du könntest es mit 'status=progress' oder 'pv' auch aufhübschen
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Hallo Ronny,
das ist schnelles Feedback. Da bin ich also nicht auf dem Holzweg mit dem Zusammenbasteln.
Das kleine Schmankerl meiner Version liegt in der Verwendung von 7z, das wohl auf allen verfügbaren CPUs komprimieren soll (im Gegensatz zu gzip). Allerdings muss man diese Kommandozeilenparameter erst einmal finden / rausbekommen: 7z a -si -so -an -tgzip -bsp2 a: mache Archiv(e) -si -so : nimm von stdin, schreibe nach stdout -an: nicht meckern / abbrechen, wenn Archiv-Namen nicht als Parameter genannt wird (-so!) -tgizp: gzip als Kompressionstyp -bsp2: Fortschrittsanzeige nach stderror Das hat auch gedauert, aber irgendwie kam ich bei tar gar nicht weiter.
Vielen Dank! Bernhard
Am Mittwoch, 5. November 2025, 12:33:17 Mitteleuropäische Normalzeit schrieb ronny@seffner.de:
Hallo Bernhard,
Die Idee ist, eine Partition (Windows, 40 GB, ~25 GB belegt, Rest mit "Nullfiles" beschrieben, diese gelöscht) auf einem USB-Stick (vfat) zu sichern.
...
Allerdings komme ich mit der man-page von tar nicht klar. Die ist irgendwie so esoterisch formuliert (GNU-Style?), dass ich(!) nicht begreife, was nun eigentlich und wie gemacht werden muss.
- 'tar -L' erfordert '-M' und ist für Wechselmedien (Tapes), wird also interaktiv nach neuen Dateinamen fragen
- Deine Idee mit 'split' ist dann doch nicht verkehrt 'tar -cf - /dev/sda2 | split -b 3G - /ziel.datei.auf.vfat'
- so werden aber die 15GB Nullen nicht wegrationalisiert, also sollte ein 'gzip -1 |' vor das 'split'
- da Du nun aber eigentlich kaum features von tar nutzt, könnte 'dd bs=xx' performanter sein und du könntest es mit 'status=progress' oder 'pv' auch aufhübschen
Mit freundlichen Grüßen / Kind regards Ronny Seffner
pgzip macht auch gzip auf allen CPUs, so als Randnotiz.
Grüße,
Falk
On Wed, 2025-11-05 at 14:34 +0100, Bernhard Schiffner wrote:
Hallo Ronny,
das ist schnelles Feedback. Da bin ich also nicht auf dem Holzweg mit dem Zusammenbasteln.
Das kleine Schmankerl meiner Version liegt in der Verwendung von 7z, das wohl auf allen verfügbaren CPUs komprimieren soll (im Gegensatz zu gzip). Allerdings muss man diese Kommandozeilenparameter erst einmal finden / rausbekommen: 7z a -si -so -an -tgzip -bsp2 a: mache Archiv(e) -si -so : nimm von stdin, schreibe nach stdout -an: nicht meckern / abbrechen, wenn Archiv-Namen nicht als Parameter genannt wird (-so!) -tgizp: gzip als Kompressionstyp -bsp2: Fortschrittsanzeige nach stderror Das hat auch gedauert, aber irgendwie kam ich bei tar gar nicht weiter.
Vielen Dank! Bernhard
Am Mittwoch, 5. November 2025, 12:33:17 Mitteleuropäische Normalzeit schrieb ronny@seffner.de:
Hallo Bernhard,
Die Idee ist, eine Partition (Windows, 40 GB, ~25 GB belegt, Rest mit "Nullfiles" beschrieben, diese gelöscht) auf einem USB-Stick (vfat) zu sichern.
...
Allerdings komme ich mit der man-page von tar nicht klar. Die ist irgendwie so esoterisch formuliert (GNU-Style?), dass ich(!) nicht begreife, was nun eigentlich und wie gemacht werden muss.
- 'tar -L' erfordert '-M' und ist für Wechselmedien (Tapes), wird
also interaktiv nach neuen Dateinamen fragen
- Deine Idee mit 'split' ist dann doch nicht verkehrt 'tar -cf -
/dev/sda2 | split -b 3G - /ziel.datei.auf.vfat'
- so werden aber die 15GB Nullen nicht wegrationalisiert, also
sollte ein 'gzip -1 |' vor das 'split'
- da Du nun aber eigentlich kaum features von tar nutzt, könnte 'dd
bs=xx' performanter sein und du könntest es mit 'status=progress' oder 'pv' auch aufhübschen
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Hallo,
On Wed, Nov 05, 2025 at 12:12:34PM +0100, Bernhard Schiffner wrote:
Die Idee ist, eine Partition (Windows, 40 GB, ~25 GB belegt, Rest mit "Nullfiles" beschrieben, diese gelöscht) auf einem USB-Stick (vfat) zu sichern. Da vfat maximal 4 GB Filegröße kann, muss also irgendwie noch ein split eingebaut werden, z.B.:
[...]
Unabhaengig von Ronnys Loesung "tar cf - ... | split ..." stellt sich die Frage, ob Du auf dem Stick exfat statt vfat nutzen kannst. Dafuer gibt es inzwischen nativen Support fuer Linux/Windows/MacOSX und es hat kein 4 GB Dateigroessenlimit.
Gruesse, Christian
Am Mittwoch, 5. November 2025, 12:12:34 Mitteleuropäische Normalzeit schrieb Bernhard Schiffner:
Hallo!
Die Idee ist, eine Partition (Windows, 40 GB, ~25 GB belegt, Rest mit "Nullfiles" beschrieben, diese gelöscht) auf einem USB-Stick (vfat) zu sichern. ...
Eine Idee, von der man (ich) Abstand nehmen sollte.
Ich habe die enstandenen Files per sh256sum gehasht und von inzwischen 3 USB Sticks nur einen ohne Fehler beim Restore wiederbekommen. D.h. selbst neue Sticks sind unzuverlässig und frage nicht nach Langzeitstabilität. Für Datensicherung empfehle ich deshalb SSD.
badlocks -wso error.log /dev/sdx is your friend. Interessant ist dabei, dass kaum badblocks entdeckt werden, aber die Speichermuster (0xAA, 0x55, 0x00, 0xFF) nicht einwandfrei zurück gelesen werden.
Bald mehr! Bernhard
lug-dd@mailman.schlittermann.de
-
Bernhard Schiffner -
Christian Perle -
Falk Herzog -
Mathias Krause -
ronny＠seffner.de