Frage zu Image Erstellung mit dd

[sia]

kannst auch in-place packen mit gzip, dann brauchst du nicht den doppelten Speicherplatz.

Würde das vielleicht eher folgendermaßen machen, ist aber reine Gewohnheit.

[src=bash]gzip --best -c /path/to/image.img >image-compressed.gz[/src]

Ich würde aber lieber lz4 image.img compressed.lz4 machen, das geht schneller

 

[Sony]

Vielen Dank! Ja, habe gestern mal etwas recherchiert, der Befehl von mir gilt wohl nur, wenn ich während der Imageerstellung packen lassen will.

O.K., also dann statt "/image.img" dann lz4 image.img und statt ">image-compressed.zip" dann compressed.lz4?

Eine Frage, geht es eig. schneller, bereiuts bei der Imageerstellung eine Hashsumme wie MD5, SHA1 oder so berechnen zu lassen, als wenn das Image bereits fertig ist?

 

[Metal_Warrior]

@Sony: Wozu willst du den Hash haben? Er beinhaltet keine nützliche Information, insbesondere nicht, wenn die Festplatte grad abraucht. Und nein, nicht wirklich.

 

[Sony]

Möchte das einfach mal testen. Und natürlich vom Image, nicht von der HDD, ist ja klar!

 

[Metal_Warrior]

@Sony: Mit Hashes überprüft man Datenintegrität - das nützt aber nur was, wenn du Daten kopierst, d. h. nen Hash der Quelle hast und einen des Ziels. Daher nutzt der hier gar nix (und wenn du was kopierst, macht das System automatisch ne Integritätsprüfung, insofern doppelte Arbeit, kein Nutzen).

 

[Sony]

Ja, das stimmt schon. Noch was, ich will das Image nicht packen, ich will ein dupliziertes gepacktes Image

Edit: Also, ich habe das Image nun ausgelesen und es wurden etliche Daten gefunden. Aber hierzu eine Frage, wenn das Image, welches erstellt wurde, keinen Lesefehler meldet und man mit Scalpel etc, arbeitet, wie hoch ist die Wahrscheinlichkeit, dass zuvor nicht überschrieben Daten nicht gerettet werden können? Eigentlich ist das nicht möglich, oder? Denn das Image ist ja komplett und ohne Auslesefehler.

 

[sia]

Es wird nicht immer ein Lesefehler geworfen, wenn es Fehler beim Auslesen gibt. Klingt komisch, aber beispielsweise Bit Flips kann dd natürlich nicht erkennen. Genausowenig erkennt es mehrfache Versuche der Festplatte, eine Datei zu lesen. NAS-Festplatten werfen direkt beim ersten fehlgeschlagenen Lesevorgang einen Fehler ans Betriebssystem, damit man die Platte gleich austauschen kann. Bei Desktop-Platten ist das nicht so.

 

[Sony]

Ja, das stimmt schon, aber das kein Fehler geloggt wird und später > 300 GB fehlen, kann kaum sein, oder?

 

[theSplit]

Vermutlich werden die Fehlerhaften Sektoren übersprungen (aber genullt geschrieben) die nach einer unbestimmten bzw. selbst definierten Anzahl von versuchen nicht gelesen werden können, heißt es gibt "Lücken" oder eben statt ner 1 ne 0 oder anderhersherum wenn "fehlerhaft gelesen wird".

Reduziert wird aber mit Sicherheit nichts an der Datenmenge, da du ja ein 1:1 Abbild haben willst, das heißt auch die Sektoren sollen so angeordnet sein/bleiben, wie sie gelesen sind (ob fehlerhaft oder nicht) oder eben nicht gelesen worden sind.

 

[Sony]

Danke, aber was heißt das nun genau`? Das Image ist so groß wie der Quelldatenträger, also 1 TB. Zudem habe ich das mit dd_rescue gemacht - so fehlerhaft kann die Platte nicht sein, dass > 300 GB fehlen, oder? Ich meine, wo wäre dann der Sinn von dd_rescue, wenn kein Fehler ausgegeben wird?

 

[theSplit]

Aus der Manpage die @Nik bereits hier verlinkt hat:

Description

dd_rescue is a tool that copies data from a source (file, block device, pipe, ...) to one (or several) output file(s).

If input and output files are seekable (block devices or regular files), dd_rescue does copy with large blocks (softbs) to increase performance. When a read error is encountered, dd_rescue falls back to reading smaller blocks (hardbs), to allow to recover the maximum amount of data. If blocks can still not be read, dd_rescue by default skips over them also in the output file, avoiding to overwrite data that might have been copied there successfully in a previous run. (Option -A / [kw]--alwayswrite[/kw] changes this.).

dd_rescue can copy in reverse direction as well, allowing to approach a bad spot from both directions. As trying to read over a bad spot of significant size can take very long (and potentially cause further damage), this is an important optimization when recovering data. The dd_rhelp tool takes advantage of this and automates data recovery. dd_rescue does not (by default) truncate the output file.

"""dd_rescue does not (by default) truncate the output file""":
Standardeinstellung sollte also sein, das die Datenmenge/das Outputfile nicht gekürzt werden (1 zu 1 Kopie) - so würde ich das verstehen.

Davor steht:
"""If blocks can still not be read, dd_rescue by default skips over them also in the output file, avoiding to overwrite data that might have been copied there successfully in a previous run. (Option -A / [kw]--alwayswrite[/kw] changes this.)."""

Blöcke die nicht mit dd_rescue gelesen werden könne, werden übersprüngen. also geht man auch im Schreibvorgang "über möglicherweise bereits existierende Blöcke", wenn die Datei nicht automatisch gekürzt wird? Was die andere Zeile sagt.


Das mit dem "Ausnullen":

Sparse files and write avoidance

-A, --alwayswrite

changes the behavior of dd_rescue to write zeroes to the output file when the input file could not be read. By default, it just skips over, leaving whatever content was in the output file at the file position before. The default behavior may be desired, if e.g. previous copy operations may have resulted in good data being in place; it may be undesired if the output file may contain garbage (or sensitive information) that should rather be overwritten with zeroes.

"""changes the behavior of dd_rescue to write zeroes to the output file when the input file could not be read. By default, it just skips over, leaving whatever content was in the output file at the file position before."""

Wenn --alwayswrite oder "-A" Switch genutzt werden, werden Blöcke, die nicht gelesen werden können, ausgenullt in einer "bestehenden" Datei, was möglicherweise Daten überschreibt / auslöscht, die vorher erfolgreich "in die Zieldatei" gelesen worden sind, wenn diese bereits existiert.

------------

Warum 300 GB "fehlen", hast du dein Image gepackt? - Tar zum Beispiel entsorgt "leere" Informationen, das heißt der ganze "leere" ("defekte") Block "000000000000" im Lesevorgang, wird zu "0" bzw. enthält "keine Daten" die gepackt werden müssen - vereinfacht gesagt, daher "könnte" der Größenunterschied kommen, nach dem Entpacken aus einer Archivdatei.

Würde für mich heißen, du hast circa ~300 GB Sektoren die keine Informationen enthielten, die durch ein mögliches Packen, "entfernt" worden sind.

 

[Metal_Warrior]

@Sony: Der Sinn von dd_rescue ist, dass keine Fehler ausgegeben werden. Anders als dd, das sofort beim ersten Lesefehler abbricht. dd_rescue ist dazu da, so fehlertolerant wie möglich eine Kopie der Festplatte zu erstellen. Wenn die Quelle nur noch ein rauchender Schrotthaufen ist, wird dd_rescue trotzdem fehlerfrei beenden - die Daten, die es ins Ziel schreibt, sind dann die einzigen, die man der Quelle noch entreißen konnte.

Ansonsten hat Split dir das schon richtig erklärt.

 

[Sony]

An euch beide VIELEN DANK! Ja, das stimmt schon, aber ich habe gedacht, dass es wenigstens im Log dokumentiert wird, wenn Blöcke "aufgenullt" wewrden.

Aber ich habe schon hunderttausende Daten gerettet. Eine Frage, foremost kann nur mit Daten bis 2 GB Größe umgehen - und die anderen? Welches tool eignet sich? scalpel?

@theSplit

Nein, ist nichts gepackt. Es scheinen Daten im unpartitionieretn Bereich zu liegen. Den ersten Versuch habe ich abgebrochen, als 1 Stunde nichts gerettet wurde - danach gings aber noch weiter

 

[Sony]

Ich habe nochmal eine Frage, ich kann ja das "dd" Image auch mounten. Das wäre auch nötig, da ich mit Photorec noch einges testen will. Kann mir bitte jemand helfen und sagen, wie ich das Image mounte? Und geht das, wenn die Dateisystemstruktur beschädigt ist?

 

[sia]

RTFM: http://www.forensicswiki.org/wiki/Mounting_Disk_Images

 

[dexter]

habe ich das mit dd_rescue gemacht - so fehlerhaft kann die Platte nicht sein, dass > 300 GB fehlen, oder?

Hatt dd_rescue denn Fehler ausgegeben?

edit: oops, da waren noch andere Antworten.

 

[Sony]

@phre4k

Ja, vielen Dank! Bisher hatt ich das Manual nicht^^ Dann könnte ich ja Photorec drüberlaufen lassen, oder?

Hatt dd_rescue denn Fehler ausgegeben?

Nein, nicht einen einzigen.

 

[dexter]

Nein, nicht einen einzigen.

Dann sollten egtl. alle Daten da sein.

 

[Sony]

So, das mit dem mounten klappt natuerlich nicht. Das Image liegt auf /dvd/sdc in dem Ordner Toshiba und das Image ist Toshiba.img. bitte, wie muss ich es mounetn

 

[sia]

RTFM.

mount -optionen quelldatei zielverzeichnis/