Aus der
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.
