dd clone-backup einer OS-SD-Card ohne Dateireste zu kopieren

[Filinimum]

Hallo.

Ich benutze einen RaspberryPI. Gelegentlich schalte ich ihn ab, nehme die SD Karte raus und führe unter einem normalen deutlich schnelleren PC-Debian-Linux ein Backup aller Daten durch.

Code: Alles auswählen

    /dev/mmcblk0p1          c W95 FAT32 (LBA)
    /dev/mmcblk0p2          83 Linux

Dafür benutze ich dd und setze bei /dev/mmcblk0 an. Komprimiere den Datenstrom einfach direkt mit bzip2 und lasse die dann in eine Datei speichern.

Das Problem: Die Daten werden immer größer, da damit auch gelöschte Dateien kopiert werden.

Bei einer HDD würde ich einfach eine Datei mit /dev/zero als Quelle erstellen und sobald diese voll ist, Lösche ich sie wieder und das Backup wird wieder deutlich kleiner. Allerdings soll man Flash-Karten nicht so "quälen", da sie so deutlich schneller abgenutzt werden.

Die Alternative wäre vielleicht: ich kopiere einfach dazu die 64 GB, mounte sie dann als Datei und fülle es hier dann dann mit null bytes auf dem PC. Leider aber ist es auch eine Flash-SSD.

Und dazu kommt noch die ist gerade mal 64 GB groß. Das komprimierte Backup braucht gerade mal 2.5 GB.

Soviel zum Problem. Hat vielleicht jemand eine Idee wie ich eine solches Mirror-Backup durchführen könnte, ohne das die gelöschten Dateien kopiert werden?

TrueImage macht so was bspw. in der Windows -Welt, welches auch nur die benutzten Daten kopiert und so eine saubere komprimierte raw-Kopie erstellt.

Vielleicht gibt es auch ein spezielles DD, dass damit umgehen könnte?

Interessant wäre auch ob man damit auch eine gleichgroße SD-Karte Clonen könnte ohne alte Dateireste auch mit zu kopieren.

Vielleicht hat jemand Ideen *Daumen drückt*

[DeletedUserReAsG]

Warum muss es ein Image sein? Wenn du die Daten einfach kopierst, landen nur existierende Dateien/Daten im Backup.

[rendegast]

TrueImage macht so was bspw. in der Windows -Welt, welches auch nur die benutzten Daten kopiert

clonezilla + partimage/partclone sollte das imaging ohne deleted-files hinbekommen.
Dann aber vermutlich von den Partitionen resp. Dateisystemen separat, nicht vom ganzen Datenträger.

[wanne]

mmcblk0p1 ist FAT. Da sind doch sowieso keine erweiterten Attribute drauf. Kannst du einfach die dateien kopieren.
Was hat mmcblk0p2 denn für ein Dateisystem? BTRFS hat mit btrfs send seine eigenen Backup Funktionen. Für ext könntest du e2image nehmen.

Code: Alles auswählen

e2image -ra /dev/mmcblk0p2 - | xz -1 > mmcblk0p2.img.xz

Alternativ kannst du QEMU images erstellen. (Die sind nur so groß wie die tatsächlichen Daten, komprimieren aber nicht:

Code: Alles auswählen

e2image -Qa /dev/mmcblk0p2 mmcblk0p2.qcow2

Generell würde ich ganz massiv von bzip2 abraten. Die Kompressionsrate ist bescheiden* und die Geschwindigkeit grauenhaft.
Wenn du starke kompression willst nimm pxz -6e willst du es schneller nimm plzip.

* Für Wörterbücher ist es tatsächlich noch gut und für natürliche Texte konkurrenzfähig. Aber schon bei HTML oder ähnlichem wird es vergleichsweise schlecht.

[Filinimum]

Ohje. Ich sehe es wird deutlich schwieriger.

Generell würde ich ganz massiv von bzip2 abraten. Die Kompressionsrate ist bescheiden* und die Geschwindigkeit grauenhaft.

Also zur Kompression nur bzip2 oder gzip. Das gibt's notfalls sogar auf jedem Router. Ich wollte auch unbedingt das es RAW bleibt. Nur eben ein sauberes.

Nebenbei bin ich der Meinung das andere auch bessere wären. Für mich ist 7z das allerbeste, aber auch langsamste. Braucht Unmengen leider an Speicher, aber dafür kann sich das Ergebnis sehen lassen. Wenn schneller gehen soll nehme ich machmal auch gzip auf niedrigster Stufe. Im Grunde soll es ja nur die 00000 zusammenfassen. Aber das schöne an RAW, ich kann es nachträglich auch einfach entpacken und mit was anderem wieder packen. Das kann dann auch schon 4 Stunden Dauern. Die SD Karte ist dann längst wieder im PI.


Ja... Das Dateisystem ist vfat zum Booten und ext4 für das Spezielle PI-Debian-ARM Linux selbst.

Die Idee vom e2image muss ich mir mal genauer anschauen. Aber ich fürchte es lässt sich dann nicht mehr mit dd einfach wieder auf spielen. Gerade zum Rücksichern wollte ich nichts ungebräuchliches nutzen. Und selbst mit dem bösen Windows kann man das noch zurück sichern.


Ich habe schon mal versucht beide einzeln zu Backup'en und zu Recovern. Doch danach lief es gar nicht mehr an. Somit bleibt nur das totale Image. Mal sehen ob das mit e2image geht. Da muss ich mich mal reinlesen.

Warum muss es ein Image sein? Wenn du die Daten einfach kopierst, landen nur existierende Dateien/Daten im Backup.

Gerade das Rückspielen und auch das Backup dauert einfach zu lange. Komplikationen gab es dabei oft genug. Allerdings lasse ich das Image zurück spielen und mach dann ein umgedrehtes rsync auf die "user"-Daten über ssh vom PC aus.

clonezilla + partimage/partclone sollte das imaging ohne deleted-files hinbekommen.
Dann aber vermutlich von den Partitionen resp. Dateisystemen separat, nicht vom ganzen Datenträger.

An clonezilla dachte ich auch schon. Hatte aber damit leider schon ganz große Misserfolge bei der Wiederherstellung. Ich wollte es lieber einfach halten.

Irgendwie etwas was den dd-Stream eigentlich nur mit ließt und automatisch nullen ersetzt, wo keine Dateien mehr sein sollte. Aber ich fürchte während ich nebenbei nochmal die zwei manpages gelesen habe, das ich wohl doch wohl nicht an ein null-bytes schreiben vorbei komme.

[DeletedUserReAsG]

Gerade das Rückspielen und auch das Backup dauert einfach zu lange.

Das verstehe ich nicht. In der Regel dauert es weit weniger lange, nur die tatsächlichen Daten zurückzuspielen, als ein komplettes Image drüberzubügeln. Komplikationen sollte es auch nur dann geben, wenn man irgendwas falsch gemacht hat.

Irgendwie etwas was den dd-Stream eigentlich nur mit ließt und automatisch nullen ersetzt, wo keine Dateien mehr sein sollte.

dd hat keine Ahnung, was das für Daten sind. Es kopiert sie nur.

[Filinimum]

Gerade das Rückspielen und auch das Backup dauert einfach zu lange.

Das verstehe ich nicht. In der Regel dauert es weit weniger lange, nur die tatsächlichen Daten zurückzuspielen, als ein komplettes Image drüberzubügeln. Komplikationen sollte es auch nur dann geben, wenn man irgendwas falsch gemacht hat.

Bei vielen großen Dateien JA. Da stimmt ich absolut zu. Da wäre das deutlich schneller.

Mir sind öfters Flashs kaputt gegangen, nachdem zu viele Dateien zurück kopiert wurden. Vermutlich wird dabei einfach zu oft unnötig in den Datei-Index geschrieben. Bei über 20.000 Dateien wären wohlmöglich zwei Recoveries schon deren tot.

Bei einem RAW-Recovery dürfte nur einmal der Bereich beschrieben werden. Und alle Bereiche die bereits 0 waren, sollte der Controller einfach überspringen. Das macht es nochmal deutlich schneller, da nicht auf einen erfolgreichen Schreibvorgang gewartet werden muss.

Mir ist die Schonung der Karte einfach am wichtigsten. Da kann ich auch mal 10 min länger warten. Die gibt es zwar auch zum extremen Spottpreis inzwischen. Trotzdem sind die schlecht für die Umwelt. Soviel Verpackungsmüll jedes mal für etwas Fingernagel-Großes.

[DeletedUserReAsG]

Mit dd werden jedenfalls auch die Nullen, bzw. der Datenmüll der gelöschten Dateien geschrieben. Und wenn dann noch die falsche BS angegeben wird, so dass eine Zelle mehrfach beschrieben wird, wird’s arg langsam und verschleißfördernd. Auf Dateisystemebene sollte™ gecached und am Stück weggeschrieben werden.

[wanne]

Also zur Kompression nur bzip2 oder gzip. Das gibt's notfalls sogar auf jedem Router.

Bei gzip stimme ich dir da zu. Aber bzip2 stirbt zum Glück nach und nach wirklich aus.
Openwrt bringt in der aktuellsten Version kein bzip2 mehr mit (Allerdings auch kein xz).
Bei RPM sind die meisten auf xz umgestiegen für die initrd ist entweder gzip, lzma oder xz. bzip2 gabs da nie in freier Wildbahn.

Ich wollte auch unbedingt das es RAW bleibt. Nur eben ein sauberes.

Das hast du bei e2image -r (r steht sogar für RAW) oder rsync auf ein image auch.

Nebenbei bin ich der Meinung das andere auch bessere wären. Für mich ist 7z das allerbeste, aber auch langsamste. Braucht Unmengen leider an Speicher, aber dafür kann sich das Ergebnis sehen lassen.

hast du pxz mal ausprobiert?

Wenn schneller gehen soll nehme ich machmal auch gzip auf niedrigster Stufe.

lzop oder gar plzip mal getestet

Aber das schöne an RAW, ich kann es nachträglich auch einfach entpacken und mit was anderem wieder packen.

Mit was kannst du das nicht.

Das kann dann auch schon 4 Stunden Dauern. Die SD Karte ist dann längst wieder im PI.

Guck dir unbedingt mal lvms oder btrfs an.Da kannst du backups ziehen ganz ohne die Karte aus dem PI überhaupt erst zu entfernen. (Ist dann dank USB2.0 sticke lahm, aber deswegen kauft man sich einen bananapi )

Aber ich fürchte es lässt sich dann nicht mehr mit dd einfach wieder auf spielen.

Mit -r schon. Aber tu deiner SD-Karte einen Gefallen und nimm cat oder cp. Ist auch schneller. (Wobei man das bei SSD->SD kaum merkt.)

Aber ich fürchte während ich nebenbei nochmal die zwei manpages gelesen habe, das ich wohl doch wohl nicht an ein null-bytes schreiben vorbei komme.

e2image lässt das sein. Sogar beim Backupen, wenn man das auf ext4 macht. (siehe Sparcefiles)

Im Grunde soll es ja nur die 00000 zusammenfassen.

Dann reicht das ganz ohne kompression:

Code: Alles auswählen

cp --sparse=always

Auf einem modernen Datisystem (nicht FAT) wirst du feststellen, dass der Belegte Platz dem Datenträger deutlich kleiner als die Datei ist, weil cp die Nullen weglässt. Achtung beim kopieren: Jagt man die Datei durch ne Pipe oder kopiert sie auf FAT sind alle Nullen wieder da.

Code: Alles auswählen

e2image -ra /dev/mmcblk0p2 backup.img

Würde das automatisch machen. Da hättest du dir das Kompression also vollständig geschenkt, und jeder der das Dateisystem öffnen kann, kann die Datei ganz normal nutzen.

Mir ist die Schonung der Karte einfach am wichtigsten.

Dann nimm rsync oder nutze btrfs. Denen kann man sagen, dass es nur Änderungen abändert statt jedes mal neu zu schreiben.

[Meillo]

Irgendwie etwas was den dd-Stream eigentlich nur mit ließt und automatisch nullen ersetzt, wo keine Dateien mehr sein sollte.

dd hat keine Ahnung, was das für Daten sind. Es kopiert sie nur.

Fast richtig. dd(1) hat aber ueberhaupt keine Ahnung von diesen Dateien, es kopiert nur die Bytes einer Device-Datei.

Du brauchst auf jeden Fall irgendein Programm, das das verwendete Dateisystem versteht. (In einer Pipeline mit dd(1) wird das eher nicht arbeiten koennen, weil vermutlich wahlfreier Zugriff noetig ist.)

[DeletedUserReAsG]

Daten ≠ Dateien

Man könnte dd aber durchaus auch auf Dateien anwenden. Doch das wäre in diesem Fall sinnlos bis kontraproduktiv.

Ich bleibe dabei: Inhalte der Dateisysteme mit cp oder rsync (mit entsprechenden Optionen für Links und Berechtigungen) zu kopieren, ist deutlich sinnvoller, als zu versuchen, die leeren Bereiche aus dem Datenstrom eines Images herauszupopeln um nur die tatsächlich belegten Blöcke zu schreiben. Letzteres müsste man ja sowieso wieder auf Dateisystemebene machen, weil unbelegte Bereiche im Dateisystem eben nicht zwangsläufig Nullen auf dem Datenträger sind und man gucken müsste, welche Daten nun tatsächlich zu Dateien gehören und welche nicht.

[wanne]

Daten ≠ Dateien

Unter UNIX schon.

Man könnte dd aber durchaus auch auf Dateien anwenden.

Man kann dd (zumindest das, dass ihr hier benutzt) ausschließlich auf Dateien anwenden.
Warum leute denken, dass man, wenn der Dateipfad mit /dev anfängt dd nehmen soll ist mir bis heute schleierhaft dd ist schlicht ein cp mit ein paar zusätzlichen lowlevel Funktikonen (sync nach allen X Bytes, synchrones lesen und schreibem, seek, skip, count) die in 99% der Fälle eher unerwünscht sind.

[MSfree]

Bei einer HDD würde ich einfach eine Datei mit /dev/zero als Quelle erstellen und sobald diese voll ist, Lösche ich sie wieder und das Backup wird wieder deutlich kleiner. Allerdings soll man Flash-Karten nicht so "quälen", da sie so deutlich schneller abgenutzt werden.

Deine Angst ist völlig unbegründet. Es stimmt zwar, daß Flashsppeicher nicht beliebig oft genullt werden kann, die Zahl der Schreibzyklen liegt aber bei ca. 10000. Wenn du wöchentlich alle mit Nullen füllen würdest, um dein Backup zu verkleinern, sind das 52 Schreibzyklen pro Jahr. Die 10000 Zyklen wären dann also nach 200 Jahre erreicht.

Wenn du trotzdem Bammel hast, daß die Karte voreilig kaputt geht, kannst du das Image auch erstmal in eine Datei auf eine Festplatte schreiben, diese Datei als Loopback-Device mounten, dort den unbenutzten Speicher mit Nullen füllen, das Image wieder unmounten und anschließend mit bzip2 komprimieren.

Wenn du das aber über die Festplatte machst, mußt du aufpassen, daß die Platte nicht an den Stellen kaputt geht, wo du die Nullen schreibst, denn auch Festplatten sind nicht beliebig häufig überschreibbar.

[Meillo]

Man könnte dd aber durchaus auch auf Dateien anwenden.

Man kann dd (zumindest das, dass ihr hier benutzt) ausschließlich auf Dateien anwenden.

Man muss sich klar machen, um *welche* Dateien es jeweils geht. dd(1) arbeitet auf einer Datei, das ist korrekt. Diese kann (und wird meistens) eine Device-Datei sein (und zwar ein Block-Device, das ein Dateisystem enthaelt). Aber man kann dd(1) genauso gut statt cp(1) verwenden.

Was dd(1) aber nicht kann, ist auf die Dateien innerhalb eines Dateisystems ueber dessen Block-Device-Datei zuzugreifen. Dazu muesste es naemlich das jeweilige Dateisystem verstehen koennen, was es nicht kann.

Da in Unix nunmal alles Dateien sind, kann es schon schnell verwirrend werden, um welche Dateien es in so geschachtelten Szenarios geht.

[DeletedUserReAsG]

Daten ≠ Dateien

Unter UNIX schon.

Kontext beachten, bitte.