Option für den dd - Befehl

[khs]

Mein Vorhaben wäre, den kompletten Inhalt einer 500er HDD, die mit weniger als 100 GB an Daten
belegt ist, 1:1 auf einer 120er HDD mit dem dd-Befehl zu sichern.

Habe schon mit der count- und bs-Option probiert.

dd count=63 if=/dev/sda of=spur-0-der-festplatte.bin funktioniert,

aber mit count="vielfaches von 63" kam ich nicht weiter.

auch mit der Option bs=110G konnte die Übertragung nicht begrenzen.

Hat jemand eine Lösung parat, ohne daß ich die 500er verkleinern muß.

Gruß
Hans

[bluestar]

Hat jemand eine Lösung parat, ohne daß ich die 500er verkleinern muß.

Du wirst nicht daran vorbeikommen die 500GB erst einmal zu verkleinern, damit sichergestellt ist, dass all deine Daten auch wirklich in den ersten 110GB der HDD liegen.

[Strunz_1975]

Clonezilla

oder

Partimage

[tijuca]

Für Dein Vorhaben ist das dd Tool nicht die richtige Wahl. Dieses Tool erstellt eine 1:1 Kopie der Rohdaten der Partition. Allerdings wird die Partition auf der Zielplattform mit Sicherheit anders organisiert sein und Du somit in der Regel Performance Problem haben (bedingt durch das unterschiedliche Alignment, wenn man nicht nacharbeitet). Oder das Wear-Leveling wird suboptiomal ausgeführt.

Was Du benutzen willst ist rsync um eben nur die Nutzdaten zu transferieren. Z.B. wie hier beschrieben. Ich würde aber auch nicht die kompletten 500GB als Ziel benutzen sondern eine neue Partition mit Deiner Wunschgröße anlegen.

[Meillo]

Hat jemand eine Lösung parat, ohne daß ich die 500er verkleinern muß.

Du wirst nicht daran vorbeikommen die 500GB erst einmal zu verkleinern, damit sichergestellt ist, dass all deine Daten auch wirklich in den ersten 110GB der HDD liegen.

Ein Filesystem ist ein reservierter Bereich (bei dir 500G) in dem die Nutzdaten (bei dir 110G) *irgendwie* abgelegt sind. Ob sie am Anfang oder am Ende oder frei verteilt liegen ist alleine dem Dateisystem ueberlassen.

Wenn du die Verteilung innerhalb des Bereichs veraendern willst, dann brauchst du ein Tool, das das jeweilige Filesystem implementiert um es zu modifizieren. Programme, die Dateisysteme verkleinern koennen tun genau das: Sie kopieren Datenbloecke an andere Stellen und passen die internen Verwaltungsstrukturen des Dateisystems an. Wenn so ein Programm alle Daten an den Anfang geschoben hat -- und nur dann -- kann man das Dateisystem von hinten her kleiner machen. dd(1) kann das nicht.

[MSfree]

Mein Vorhaben wäre, den kompletten Inhalt einer 500er HDD, die mit weniger als 100 GB an Daten
belegt ist, 1:1 auf einer 120er HDD mit dem dd-Befehl zu sichern.

Das geht mit dd nicht. 1:1 heißt nämlich, daß auch die 400GB unbelegter Speicher auf die 120er kopiert werden. Das paßt also nicht.

Wenn nur 100GB auf dem Quellmedium belegt sind, kannst du die einfach mit cp oder rsync auf das Zielmedium sichern.

[schwedenmann]

Hallo


Wenn du es unbedingt als image machen willst,wäre partclone noch eine wahl (schreibt nur belegte Sektoren in ein image), ansonsten einafcher per rsync, cp oder auch fsarchiver.

mfg
schwedenmann

[DaCoda]

Einfach mit gparted die Partition von 500GB auf 100GB verkleinern.
Bei einer bootfähigen Platten war es aber bei mir aber so, dass ich dann nicht mehr booten konnte.

Dann dafür sorgen, dass die Partitionstabelle der 120er-Platte nicht eingehängt ist (weil die ja überschrieben wird).
Das geht mit partx -d /dev/sdb (oder wie auch immer deine Platte heißt).

Dann mit

Code: Alles auswählen

dd if=<500er> of=<120er> bs=10M status=progress conv=fsync

kopieren.

bs=10M bedeutet 10 MB block-Größe. Damit es schnell geht...
conv=fsync bedeutet, dass er die Daten nach Programmende auch auf die Platte schreibt. Sonst kann es passieren, dass du die Platte raus ziehst (bei USB-Platten) und die Daten noch gar nicht von der Cache auf die Platte geschrieben wurden.

Anschließend führe ich immer noch sync und eject <120er> aus (ist aber wahrscheinlich unnötig).

[Tintom]

Mein Vorhaben wäre, den kompletten Inhalt einer 500er HDD, die mit weniger als 100 GB an Daten
belegt ist, 1:1 auf einer 120er HDD mit dem dd-Befehl zu sichern.

Nur kurz zur Klarstellung: Es ist durchaus möglich dieses Szenario so zu machen, allerdings brauchst du für die Wiederherstellung der Sicherung eine HDD mit mind. 500GB Kapazität, d.h. die Sicherungs-HDD ist in dem Fall nicht zum booten geeignet.

[Meillo]

Mein Vorhaben wäre, den kompletten Inhalt einer 500er HDD, die mit weniger als 100 GB an Daten
belegt ist, 1:1 auf einer 120er HDD mit dem dd-Befehl zu sichern.

Nur kurz zur Klarstellung: Es ist durchaus möglich dieses Szenario so zu machen, allerdings brauchst du für die Wiederherstellung der Sicherung eine HDD mit mind. 500GB Kapazität, d.h. die Sicherungs-HDD ist in dem Fall nicht zum booten geeignet.

Soweit ich das sehe gibt es zwei Moeglichkeiten:

1) Die ungenutzten Bereiche sind zufaellig mit Nullen gefuellt, wodurch man das Image also eine Datei mit Holes erzeugen kann, die weniger Platz verbraucht als sie eigentlich gross ist. Die Voraussetzung dafuer ist aber unwahrscheinlich, ausser man verwendet zuerst ein Aufraeumprogramm, das mit Filesystem-Wissen die ungenutzten Bereiche nullt.

2) Beim Kopieren/Imageerstellen werden nur die genutzten Bereiche kopiert. Letztlich ist das ein aehnlicher Ansatz wie (1), nur dass die Reihenfolge der Arbeitsschritte vertauscht ist. Auch hier braucht man Filesystem-Wissen.

Mit einem generischen Programme (z.B. dd(1)) von aussen muss man immer die ganze Groesse kopieren. Wenn man ungenutzte Teile aussparen will braucht man Filesystem-Wissen.

[khs]

Vielen Dank für die vielen Antworten.

Ein vorangesetztes Aufräumprogramm hatte ich schon angedacht.
Meine Frage zielte hauptsächlich auf die Codebeschreibung von DaCoda,
welche ich als erstes versuchen will.
Aber wenn ich richtig verstanden habe, geht es damit auch nur wenn
ich vorher die Ursprungsplatte verkleinere.
Die Partitionstabelle wollte ich schon auf der Zielplatte haben
damit auch sie gesichert ist, was bei den anderen Vorschlägen
vermutlich nicht der Fall sein dürfte.

Gruß
Hans

[knittels]

Hallo,

man kann mit dd auch ein komprimiertes Archiv erstellen. Das braucht dann auch nur den wirklich belegten Platz.
Siehe: https://www.thomas-krenn.com/de/wiki/Dd ... _Partition

Grüße,

[Meillo]

man kann mit dd auch ein komprimiertes Archiv erstellen. Das braucht dann auch nur den wirklich belegten Platz.
Siehe: https://www.thomas-krenn.com/de/wiki/Dd ... _Partition

Genauer gesagt komprimiert das das mit dd erzeugte Image on-the-fly. Wieviel kleiner es dadurch aber wird ist voellig offen. Wenn man davon ausgeht, dass der nicht genutzte Platz des Filesystems mit Noise gefuellt ist (geloeschte Daten und so) und die genutzten 110G ebenfalls nicht gleichfoermig sind, dann weiss ich nicht, ob 5:1 komprimiert werden kann. AV-Daten sind oft schon in komprimierten Formaten. Eine zusaetzliche gzip-Kompression holt da selten mehr als 10% raus. Hier muessten es ja aber knapp 80% sein. Die belegten und die unbelegten (!) Bereiche muessten also Gleichfoermigkeiten in den Daten aufweisen (wie Textdateien, beispielsweise), damit der Ansatz funktioniert.

(Die CPU-Last fuer die Kompression wird ganz schoen hoch sein.)

Ich find's gut, dass du diese Idee der Brainstorming-Session beigesteuert hast, auch wenn ich nicht glaube, dass sie in dem Fall praxistauglich ist.

[Meillo]

Die Partitionstabelle wollte ich schon auf der Zielplatte haben
damit auch sie gesichert ist, was bei den anderen Vorschlägen
vermutlich nicht der Fall sein dürfte.

Die Partitionstabelle kannst du auch separat sichern, beispielsweise mit fdisk-Programmen die ihren Output einlesen koennen (ich glaube, ich habe dafuer mal sfdisk verwendet, weiss aber nicht mehr, ob das auch GPT kann).

[Tintom]

man kann mit dd auch ein komprimiertes Archiv erstellen. Das braucht dann auch nur den wirklich belegten Platz.
Siehe: https://www.thomas-krenn.com/de/wiki/Dd ... _Partition

Genauer gesagt komprimiert das das mit dd erzeugte Image on-the-fly. Wieviel kleiner es dadurch aber wird ist voellig offen. Wenn man davon ausgeht, dass der nicht genutzte Platz des Filesystems mit Noise gefuellt ist (geloeschte Daten und so) und die genutzten 110G ebenfalls nicht gleichfoermig sind, dann weiss ich nicht, ob 5:1 komprimiert werden kann. AV-Daten sind oft schon in komprimierten Formaten. Eine zusaetzliche gzip-Kompression holt da selten mehr als 10% raus. Hier muessten es ja aber knapp 80% sein. Die belegten und die unbelegten (!) Bereiche muessten also Gleichfoermigkeiten in den Daten aufweisen (wie Textdateien, beispielsweise), damit der Ansatz funktioniert.

(Die CPU-Last fuer die Kompression wird ganz schoen hoch sein.)

Ich find's gut, dass du diese Idee der Brainstorming-Session beigesteuert hast, auch wenn ich nicht glaube, dass sie in dem Fall praxistauglich ist.

Wenn du den nicht genutzten Platz des Dateisystems mit Nullen füllst (sei es mit zerofree oder einem simplen cat /dev/zero), lassen sich solche Kompressionsfaktoren durchaus realisieren. Zumal in eiem durchschnittlichen Dateisystem abseits von A/V-Dateien noch andere Daten liegen, die sich idR gut komprimieren lassen.
Ich habe einige Images so gesichert und finde es eine durchaus elegante Lösung, alle benötigten Tools sind auf einem Standard-Debian schon ab Installation vorhanden.

[knittels]

Wenn du den nicht genutzten Platz des Dateisystems mit Nullen füllst (sei es mit zerofree oder einem simplen cat /dev/zero), lassen sich solche Kompressionsfaktoren durchaus realisieren. Zumal in eiem durchschnittlichen Dateisystem abseits von A/V-Dateien noch andere Daten liegen, die sich idR gut komprimieren lassen.
Ich habe einige Images so gesichert und finde es eine durchaus elegante Lösung, alle benötigten Tools sind auf einem Standard-Debian schon ab Installation vorhanden.

Das müsste man auf jeden Fall machen. Ich habe mal meine Systempartition gezippt. Partitionsgröße = 110GB, belegt sind 16 GB und das Image hat 24 GB.
Die CPU-Last liegt bei 100%, jedoch nur auf einem Kern.

Grüße,

[schwedenmann]

Hallo

@knittels

man kann mit dd auch ein komprimiertes Archiv erstellen. Das braucht dann auch nur den wirklich belegten Platz.

Wo steeht das im verlinkten Artijel

Du erzeugts ein image einer Partition von 500MB, das ist bei dd 500MB groß, wenn du das komprimierst ist es zwar kleiner, aber um das komprimierte auf eine neue HDD zu spielen, mußt du es entpacken, dann ist es aber wieder 500MB groß. Die Komprimierung nutzt dir da gar nichts, außer du willst das image irgendwo zwischenspeichern und hast keine 500MB übrig.

mfg
schwedenmann

[Meillo]

Wenn du den nicht genutzten Platz des Dateisystems mit Nullen füllst (sei es mit zerofree oder einem simplen cat /dev/zero), lassen sich solche Kompressionsfaktoren durchaus realisieren.

Wenn diese Bereiche mit Nullen gefuellt sind, dann kann das Device doch auch gleich in eine Datei mit Loechern (sparse file) kopiert werden. Die sollte dann auch nur etwas groesser als die Nutzdaten sein, ohne dass die CPU 110G effektiver Daten plus 390G Nullen komprimieren muss.

Zumal in eiem durchschnittlichen Dateisystem abseits von A/V-Dateien noch andere Daten liegen, die sich idR gut komprimieren lassen.

Es haengt halt sehr von den Daten ab. Die Kompressionsrate kann irgendwo zwischen 5% und 95% liegen. Das weiss man aber im Voraus nicht.

Ich habe einige Images so gesichert und finde es eine durchaus elegante Lösung, alle benötigten Tools sind auf einem Standard-Debian schon ab Installation vorhanden.

Das ist ein Pluspunkt.

Was mich halt nicht recht ueberzeugt an der Sache ist, dass es auch nur dann Sinn macht wenn man das FS zuvor aufraeumt (hier mit `zerofree'). Jede einzelne der Optionen, die hier diskutiert werden, erfordert es, dass man zuerst mit einem Tool, das das FS versteht, dieses aufraeumt: Entweder man nullt die ungenutzten Bloecke oder man schiebt die genutzten Bloecke an den Anfang. Ohne diese Vorarbeit macht auch eine gzip-Kompression keinen Sinn. Wenn man aber solch eine Vorarbeit unternimmt, dann wuerde ich eher gleich das FS verkleinern bzw. reicht es dann evtl. nur den Anfang zu kopieren.

[Meillo]

Das müsste man auf jeden Fall machen. Ich habe mal meine Systempartition gezippt. Partitionsgröße = 110GB, belegt sind 16 GB und das Image hat 24 GB.

Wuerde man die genullten Bloecke zu Loechern machen sollte die Image-Datei dann so gross sein wie Nutzdaten + Inodes + Superbloecke & Co. Wenn du die Nutzdaten mit du(1) gemessen hast, wird es sichtbar mehr. Wenn du auf df(1) geschaut hast, sollten die Inodes wohl schon enthalten sein.

Heute habe ich keine Zeit mehr fuer Tests, aber das wuerde mich doch interessieren tatsaechlich zu sehen. -- Wer zuerst Zahlen liefert! Auf die Plaetze, fertig, los!

[schwedenmann]

Hallo


5Gb Partition

belegt rund 1Gb oder auch 1,2Gb

dd ergibt ein Image von 5Gb

per gzip komprimiert ist das image immer ncoh 1,8Gb groß

entpackt per xarchiver haben wir wiederr ein image von 5GB, komprimieren per Aufruf von dd bringt Null,außer man will imaged per dd archivieren.

mfg
schwedenmann

P.S.

Die CPU-last bei dd + gzip ist gering gewesen ~18%, beim entpacken dagegen ~35-39%

[Tintom]

Wenn du den nicht genutzten Platz des Dateisystems mit Nullen füllst (sei es mit zerofree oder einem simplen cat /dev/zero), lassen sich solche Kompressionsfaktoren durchaus realisieren.

Wenn diese Bereiche mit Nullen gefuellt sind, dann kann das Device doch auch gleich in eine Datei mit Loechern (sparse file) kopiert werden. Die sollte dann auch nur etwas groesser als die Nutzdaten sein, ohne dass die CPU 110G effektiver Daten plus 390G Nullen komprimieren muss.

An Speichermedien sind wenn ich das richtig sehe nur eine 500GB-HDD und eine 120GB-HDD vorhanden. Ein sparse file müsste doch irgendwo zwischen gespeichert werden, bevor es auf die kleinere Festplatte wandert, oder?

Zugegeben, der Sinn von 110G Daten durch gzip zu schicken sei einmal dahin gestellt, die Kompression von Nullen ist hingegen sehr schnell und kostet so gut wie keinen Speicherplatz. Ich finde dieses Konzept leichter verständlich als mit sparse files zu arbeiten.

In diesem Zusammenhang vielleicht auch:

Die CPU-Last liegt bei 100%, jedoch nur auf einem Kern.

Wenn du z.B. pigz verwendest, werden mehrere Kerne verwendet.

Wenn man aber solch eine Vorarbeit unternimmt, dann wuerde ich eher gleich das FS verkleinern bzw. reicht es dann evtl. nur den Anfang zu kopieren.

Das birgt aber das Risiko mit einem falsch ausgeführten Befehl sämtliche Daten zu gefährden.

Ich würde nach dem Nullen mit einem beherzten cat /dev/500GB-HDD | pigz > /dev/120GB-HDD sogar auf das Anlegen von Partitionen/Dateisystemen auf der kleineren Festplatte verzichten.

In dem Zusammenhang will ich auch noch einmal auf unser Wiki verweisen, dort stehen alle Schritte bereits drin: https://wiki.debianforum.de/Vollst%C3%A ... zen_Platte

Wer zuerst Zahlen liefert! Auf die Plaetze, fertig, los!

$ head -c 100M /dev/urandom > urandom.dat
$ head -c 400M /dev/zero > zero.dat
$ cat urandom.dat zero.dat > urandom+zero.dat
$ cat urandom+zero.dat |gzip > urandom+zero.dat.gz
$ gzip -l urandom+zero.dat.gz
compressed uncompressed ratio uncompressed_name
105281876 524288000 79.9% urandom+zero.dat
$ ls -lh *.dat*
-rw-r--r-- 1 tintom tintom 100M Feb 9 21:14 urandom.dat
-rw-r--r-- 1 tintom tintom 500M Feb 9 21:15 urandom+zero.dat
-rw-r--r-- 1 tintom tintom 101M Feb 9 21:16 urandom+zero.dat.gz
-rw-r--r-- 1 tintom tintom 400M Feb 9 21:14 zero.dat

[wanne]

belegt rund 1Gb oder auch 1,2Gb

dd ergibt ein Image von 5Gb

per gzip komprimiert ist das image immer ncoh 1,8Gb groß

Und jetzt probiers mal mit einem Stick den du schon etwas öfter benutzt hast...
Lasst den Schrott die Idee mit dem Komprimieren ist ein bescheuerter Krüppelweg für Leute, die nicht wissen wie man es richtig macht.
Für den Zweck gibt es Datiesystemspezifische Tools wie e2image ntfsclone etc. (Oder tools, die die benutzen alla partclone oder Clonezilla)
Beispeil:

Code: Alles auswählen

partclone.ext3 -s /dev/sda1 -c -o /tmp/usb.img

Dann ist das Image auch wirklich nur so groß wie die belegten Daten.
Wenn dus immer noch komprimieren willst kannst du da auch ein gzip o.ä dahinter hängen. abe 500GiB zu komprimieren obwohl da nur 50GiB belegt sind ist bescheuert.

Code: Alles auswählen

partclone.ext3 -s /dev/sda1 -c -o - | lzop > /tmp/usb.img

ext3 muss natürlich durch das passende Dateisystem ersetzt werden und sda1 durch die richtige Partition.

[wanne]

Die CPU-last bei dd + gzip ist gering gewesen ~18%, beim entpacken dagegen ~35-39%

Dann war der USB-Stickkrückenlahm. Kannst du auch veraten wie lange es für die 5GiB gedauert hat? Und das mal 100 nehmen für die 500GiB-HDD. Vermutlich die üblichen 15MB/s. Jede Festplatte (Üblicherweise so 300MB/s) sollte deine CPU an 100% Auslastung bringen.

[khs]

War die letzten Wochen viel beschäftigt, für alle, die es noch interessiert:

Hatte defragmentiert, den freien Bereich mit Nulllen aufgefüllt und:

knoppix@Microknoppix:/dev$ dd if=/dev/sda | gzip > /media/sdb1/Sicherung/image.gz
dd: Fehler beim Lesen von „/dev/sda“: Eingabe-/Ausgabefehler
765287912+0 Datensätze ein
765287912+0 Datensätze aus
391827410944 Bytes (392 GB) kopiert, 12717,2 s, 30,8 MB/s

Die CPU-Auslastung hatte ich nicht überwacht,
die ca. 100 GB Daten und Nullen bis zum Abbruch ergaben im image.gz
Gesamtgröße der Dateien: 58,9 GiB (63.292.334.282 Bytes)
Größe auf Datenträger: 58,9 GiB (63.292.338.176 Bytes)

Danke nochmals für die Unterstützung,
Hans

[Tintom]

Nur der Vollständigkeit halber: Dir ist bewusst, dass du nicht die gesamte Festplatte gesichert hast, sondern nur 392 GB?