Gesendet: Montag, 14. Dezember 2020 um 23:17 Uhr
Von: "Heiko Schlittermann" <hs@schlittermann.de>
An: lug-dd@mailman.schlittermann.de
Betreff: Re: Festplatte kopieren

Bernd Müller <be-mueller@gmx.de> (Mo 14 Dez 2020 22:33:18 CET):
> Guten Abend,
>
> mir stellt sich die Frage, was du mit der geclonten Platte später anstellen
> willst?
>
> Dein Befehl, ertellt ein so genanntes Partitionsimage. Ist das gewollt? Das
> lässt sich später nicht ohne weiteres mounten. Es fehlt ja die
> Partitionstabelle und Info zum Dateisystem.

Um das Image zu mounten, braucht es keine Partitionstabelle. Und die
Info zum Filesystem steht ausschließlich im Image. Das, was die
Partitionstabelle vielleicht auch noch als FS Typ drin hat, ist Schall und
Rauch.

 

Ich meine das ein klein wenig anders. Die Partition kann man schon mounten. Sollte man irgendwann auf die Idee kommen, das Image zu virtualisieren, wird es schwierig.

> Ich würde einfach CloneZilla nehmen. Damit kann man alles "menü"-geführt
> auswählen.

Ich habe angeborenes Misstrauen in Menüführungen.

 

Ich i. d. R. auch, aber bei Clonezilla ist das imho nicht so.

> Bei Verwendung von dd erhält man immer die vollständige Platte als Image. Das
> soll heißen, dass 500 GB eben 500 GB Image ergeben. Auch wenn nur ein paar
> Megabyte darauf gespeichert sind. Muss das sein?

Das war ja vom OP offenbar so gewollt. Und im ersten Ansatz hat er sogar
verucht, es zu komprimieren. (Das komprimierte Image kann er dann
allerdings nicht mounten, das muss erst wieder irgendwo hingelegt
werden, das unkomprimierte kann er sogar per Loop-Mount direkt mounten.)

Wenn er *vor* dem Koperen Zwischenräume noch mit Nullen füllt, kann er
*beim* Kopieren sogar ohne Kompression eine Menge sparen, wenn er es als
Sparse-File kopiert (cp --sparse=always, und ich denke, auch DD hat da
eine Option).

> Als Zielplatte FAT32 ist keine gute Idee, die maximale Dateigröße ist 4 GB.

Da hast du Recht, das hat er wohl schon gemerkt.

> Wenn, dann würde ich immer das ganze Device, also /dev/sda clonen.

Warum?

 

Wegen der offen gehaltenen Möglichkeit das Image später vollständig zu virtualisieren.

> Aber auch da würde ich anders vorgehen und ein komprimiertes forensisches Image
> (e01) erzeugen. Die Werkzeuge sind alle frei verfügbar. Mounten kann man das

EWF meinst Du. e01, e02, … sind wohl nur die Dateieindungen. Wenn ich
den Artikel dazu richtig verstanden haben. Beim Überfliegen des Artikels
beschlich mich der Verdacht, dass hier auch nur Grundwissen
zusammengefasst wird, angereichert um einige interessante Werkzeuge, die
aber auch nur Grundwissen anwenden. Aber dieser Eindruck mag verfliegen,
wenn man das genauer liest.

Einen Filesystem-Dump in kleine Files zu schreiben, und dies dann zu r/w
zu mounten (wobei die Änderungen getrennt vom Original gespeichert
werden), das ist zwar keine Fingerübung für einen Nachmittag, aber geht
in einem 2…4 wöcheigen Projekt auch mit Fuse und Perl zu bewerkstelligen
(https://git.schlittermann.de/imager/) (hier incl. Deduplikation, die
sicher besser gemacht werden könnte)

> dann mit xmount on-the-fly. Richtig angewendet hab ich bspw. bei 1 TB Platte,
> mit Windows 10 (LibreOffice, Gimp, FF, Adobe,..) und Ubuntu (inkl. Cinnamon,
> ...) im dualboot, in einem 28 GB Image. Auf Wunsch in 1G-, 2G-...-Häppchen.

Hört sich spannend an. Ob die von mir o.g. Lösung im Produktivbetrieb mit FF,
Adobe usw. performant genug wäre, weiss ich nicht. Ich nutze es für
endlose Backups und gelegentliche Restores.

 

Als Live-Sicherung ist das natürlich nicht geeignet. Aber ansonsten äußerst effektiv. Im übrigen kann man über die ewf-Sicherung bspw. mit Photorec direkt nach gelöschen Dateien suchen, nicht nur nach Fotos.

 

Heiko