Images erstellen mit ddrescue

Einige Klassiker und ihre Schwächen

Nicht regelmäßig aber doch immer mal wieder ist man in der unschönen Situation, eine defekte CD, DVD oder gar Festplatte kopieren zu müssen. Wenn man ein Image des ganzen Mediums anlegen möchte, gibt es zunächst einmal das Tool dd. Von der Sicherung defekter Medien mit dd ist allerdings abzuraten: Zum einen ist dd nur sinnvoll zu verwenden, wenn verschiedene Parameter richtig gesetzt werden – ansonsten bricht dd beim ersten Fehler ab oder schreibt unbrauchbare Images. Zum anderen bietet dd aber schlicht einige Features nicht, die man bei der Datenrettung haben möchte: So lässt sich zwar angeben, wie viele Bytes jeweils in einem Rutsch gelesen werden sollen – wenn die Quelle aber defekte Sektoren hat, wird man diese Zahl eher gering ansetzen wollen. Dies führt aber dazu, dass der Auslesevorgang unnötig verlangsamt wird. Setzt man die Anzahl der gelesenen Bytes aber zu hoch, wird im Falle eines Lesefehlers auch gleiche diese (hohe) Anzahl an Bytes als defekt behandelt – es werden somit weniger Daten gerettet als möglich wäre. dd kann also nur schnell oder langsam – eine Unterscheidung zwischen defekten und lesbaren Sektoren gibt es nicht (ich bitte im Zweifelsfall um Verbesserung).

Eine Lösung ist das Programm dd_rescue (der Name des Paketes in den Paketquellen lautet ddrescue). Dieses Programm kopiert ein Medium, indem es zunächst große Blöcke einliest und kopiert – das ist schnell. Tritt nun ein Fehler auf, fällt dd_rescue in den Fehler-Modus zurück, in welchem lediglich kleine Blöcke gelesen werden – das ist langsamer, stellt aber sicher, dass nicht unnötig Daten als “defekt” verworfen werden. Treten über längere Zeit keine Fehler mehr auf, setzt dd_rescue die Blockgröße wieder hoch und beschleunigt somit die Datenrettung erneut. Damit eignet sich dd_rescue schon deutlich besser zur Rettung defekter Medien, ist aber – für sich genommen – noch nicht ganz optimal: Stellt man sich vor, dass eine Festplatte in der Mitte eine große Anzahl defekter Sektoren enthält, wird dd_rescue zunächst die lesbaren Daten am Anfang der Platte kopieren und dann viel Zeit dafür aufwenden, die defekten Sektoren in der Mitte im langsamen Fehler-Modus zu kopieren. Erst danach werden die lesbaren Daten am Ende der Platte kopiert. Es wird also viel Zeit dafür aufgewendet, möglicherweise ohnehin nicht mehr verwertbare Daten aus defekten Sektoren zu kopieren. Auf Grund der mechanischen Beanspruchung wird die Platte aber vielleicht schon beim aufwändigen und kleinteiligen Kopieren der defekten Sektoren endgültig das Zeitliche segnen. Die lesbaren Daten am Ende einer defekten Platte werden so unnötig gefährdet. Diese konzeptionelle Schwäche können erfahrene Nutzer eventuell umgehen, indem sie dd_rescue händisch mehrere Male laufen lassen und jeweils unterschiedliche Start-Positionen angeben oder die Rettung u.a. rückwärts laufen lassen. Auch zusätzliche Skripte wie dd_rhelp könnten das Verhalten von dd_rescue in dieser Hinsicht optimieren. Selbst der Autor von dd_rhelp empfiehlt aber inzwischen ein anderes Tool:

Antonio Diaz’ Programm ddrescue (ohne Unterstrich) aus dem Paket gddrescue ist eigentlich nichts anderes als eine konsequente Neukonzeption von dd_rescue, die die Funktionalität bietet, die dd_rescue nur in Ergänzung mit dem Skript dd_rhelp hatte: ddrescue liest zunächst das defekte Medium in großen Blöcken aus und schreibt die ausgelesenen Daten in das angegebene Ziel. Anders als dd_rescue liest ddrescue aber zunächst schnell über die defekten Sektoren hinweg und notiert das in einer Logdatei. Erst nachdem das ganze Medium so durchlaufen wurde, schaut sich ddrescue die defekten Sektoren erneut an: Es unterteilt die großen defekten Bereiche in mehrere kleine Bereiche und versucht dann diese kleinen “Häppchen” zu kopieren.

Durch dieses Vorgehen verwendet ddrescue zunächst seine Zeit darauf, die noch vorhandenen und lesbaren Daten eines Mediums zu retten. Erst am Ende dieses Vorgangs schaut sich ddrescue die womöglich ohnehin nicht mehr zu rettenden Daten an. Dieses Vorgehen kann gerade beim Kopieren defekter Festplatten ein enormer Vorteil sein: Jede Lesevorgang beansprucht die Mechanik zusätzlich und vermindert die Chance, wirklich die gesamte Festplatte auslesen zu können. Daher bietet es sich an, statt lange über defekte Sektoren zu rödeln zunächst die lesbaren Daten zu kopieren!

ddrescue hat aber noch andere Vorteile: Durch die Log-Datei kann eine Rettung jeder Zeit einfach abgebrochen und später fortgesetzt werden. Richtig genial (wenn auch sicher eher selten benötigt) ist dabei der Umstand, dass ddrescue auch ein funktionsfähiges Images aus mehreren defekten Datenträgern erstellen kann: Aus zwei DVDs mit identischem Inhalt kann ddrescue also ein funktionsfähiges Image erstellen! Auch im Alltag ist diese Funktion aber durchaus hilfreich: So kopiere ich meine defekten und verschmutzten DVDs zunächst mit ddrescue auf die Festplatte. Wenn dabei einige Datenbereiche nicht gelesen werden konnten, kann man seine DVD jetzt aus dem Laufwerk nehmen, (aggressiver) reinigen und es erneut versuchen: Durch die Logdatei “weiß” ddrescue genau, welche Daten beim ersten Durchlauf nicht kopiert werden konnten und schaut sich nur diese Bereiche auf der DVD erneut an. Bevor man seine DVD also mit Gewalt, Wasser und Schmierlappen bearbeitet: Erstmal das auslesen, was noch da ist und in einem zweiten Durchlauf die Lücken füllen.

Benutzung

ddrescue ist denkbar einfach zu benutzen. Beachten sollte man nur, dass man die Log-Datei bei jeder Verwendung selbst angeben muss. Gibt man keine Log-Datei an, wird auch keine angelegt und viele nützliche Features von ddrescue bleiben unzugänglich. Einen einfach Durchlauf startet man wie folgt:

sudo ddrescue -n /dev/sr0 rettungsimage.iso logdatei.log

/dev/sr0 ist dabei durch das zu rettende Laufwerk / Medium zu ersetzen. Das Image wird (naheliegend) in die Datei “rettungsimage.iso” geschrieben, das Log in “logdatei.log”. Dabei ist natürlich darauf zu achten, dass für jede Rettung eine eigene Logdatei verwendet wird.

Da ddrescue in seinem Log notiert, welche Blöcke defekt sind und welche defekten Blöcke nicht kopiert werden konnten, würde ddrescue bei einem weiteren Durchlauf erstmal gar nichts machen – im Log steht ja, dass die verbliebenen Blöcke nicht kopiert werden konnten. Um ddrescue zu einem neuen Versuch zu bewegen, müssen zunächst die defekten Sektoren als “ungetestet” markiert werden, um im Anschluss alle ungetesteten Blocks einem erneuten Test zu unterziehen:

sudo ddrescue -RT /dev/sr0 rettungsimage.iso logdatei.log

Jetzt wird ddrescue nur die vormals defekten Blöcke neu auslesen – und vielleicht retten können.

Fazit

Sicher lassen sich viele der beschriebenen Funktionen auch mit dd_rescue, dd_rhelp und sogar dd erreichen, wenn man die Tools gut zu bedienen weiß, viel Erfahrung im Umgang damit hat oder sich entsprechende Skripte geschrieben hat. ddrescue besticht aber dadurch, dass es all dies aus einer Hand bietet und keine (u.U. langsamen) Skript-Erweiterungen benötigt. Für eine einfache Datenrettung sind keine zusätzlichen Angaben durch den Benutzer nötig und die Überlegung, zunächst erstmal alle lesbaren Daten zu retten bevor man die defekten Sektoren auf Überlebende abklopft, ist sicher in sehr vielen Fällen die sinnvollere Strategie als das sequentielle Vorgehen.

Weitere Informationen

gibt es…

Hinweis
stfischr hat mich auf meine vorschnelle Editierung des Artikels hingewiesen, weswegen ich die ursprüngliche Version wiederhergestellt habe.
In der vorherigen Version des Artikels hatte ich behauptet, dass eine Rettung zunächst mit dem Schalter “-n” angestoßen werden sollte und erst in einem zweiten Durchgang darauf verzichtet werden könne. So wie sich die Sache mir jetzt darlegt, ist das nicht zutreffend und ein Durchlauf ohne irgendwelche Schalter erfüllt bereits seinen Zweck. An dieser Stelle nochmal besten Dank an stfischr für die Korrektur!

Kommentar schreiben

23 Kommentare.

  1. Sehr schön, Vor und Nachteile der Tools schön erklärt und die möglichen Einsatzszenarien umrissen. Gute Zusammenfassung zum Thema.

  2. Vielen Dank für diesen großartigen Artikel! Ich habe mich schon lange gefragt, wo die Unterschiede zwischen diesen Tools liegen und freue mich, die Antwort hier so gut und im Rahmen einer überzeugenden Rescue-Strategie erklärt zu finden.

  3. Vielen Dank für eure Rückmeldung! Leider haben sich im Abschnitt “Benutzung” Fehler eingeschlichen, die daraus resultieren, dass ich bisher eigentlich nur weniger defekte DVDs zum Testen hatte, so dass mir nicht aufgefallen ist, dass die von mir genannten Befehle zunächst sequentiell vorgehen und die fehlerhaften Sektoren eben doch beackern.

    Wichtig ist hier besonders der Parameter “-n”, durch den ddrescue die defekten Sektoren nicht weiter behandelt. Erst in einem zweiten Durchgang sollte man ohne den Parameter “-n” arbeiten und so die defekten Sektoren intensiver zu Rate ziehen.

    Die Angaben sind im Artikel nun korrigiert – wenn trotzdem noch etwas auffällt: Immer her damit ;) .

  4. Also was -n angeht. ich hab es bisher immer ohne benutzt und dabei nie ein anderes Verhalten beobachtet, als dass er erst mal alle Fehler überspringt, danach die Blöcke splittet und dann anfängt (je nach -r) die defekten Sektoren mehrmals zu lesen.

    In der Anleitung (info ddrescue) werden die Beispiele meiner Meinung nach nur getrennt (in -n und -d) um den Vorgang zu beschleunigen:
    – Mit -n alles lesen, was noch fehlerfrei ist. (schnell)
    – Mit -d die defekten Sektoren abklappern und dabei das Caching vom Kernel umgehen. (langsam)

    Ich kann mich aber auch irren …

  5. Also laut Anleitung bedeutet “-n” ja “no split” und ist per default nicht gesetzt. Da ddrescue als “Splitten” das bezeichnet, was bei dd_rescue gewissermaßen der “Fehler-Modus” ist, gehe ich davon aus, dass ddrescue per default fehlerhafte Sektoren nicht ignoriert sondern eben in kleinere Sektoren teilt (splittet) und versucht, diese auzulesen.

    Ich werde das morgen ggf. nochmal updaten – aber eigentlich sollte das so jetzt stimmen. Mal schauen – Rückmeldungen immer erwünscht ;)

  6. Hm, Also im Manual steht:

    > 2) Read the non-tried parts of the input file, marking the failed blocks as non-trimmed and skipping beyond them, until all the rescue domain is tried. Only non-tried areas are read in large blocks. Trimming, splitting and retrying are done sector by sector. Each sector is tried at most two times; the first in this step as part of a large block read, the second in one of the steps below as a single sector read.

    So wie ich das verstehe, wird im ersten Durchlauf (wenn die gesamte Platte als non-tried markiert ist) erstmal nur hintereinander weg gelesen und wenns nen Fehler gibt, der Block übersprungen und als non-trimmed markiert. Das läuft solange bis es keine non-tried Blocks mehr gibt (also einmal die Platte von vorne bis hinten durch).

    Danach kommt erst der 2. Durchgang ( 3) im Manual) genannt trimming wo einfach die non-trimmed Blöcke rückwärts gelesen werden.

    Danach geht erst das Splitten los.

    Und danach dann das durch -r begrenzte lesen der defekten Sektoren.

    Also würden mit -n die ersten 2 Durchläufe trotzdem geschehen. Und ohne -n werden diese Durchläufe auch gemacht und auch in der selben Reihenfolge. Der unterschied ist halt nur, dass man mit -n die -d Option differenzierter anwenden kann.

    Hab nochmal alles relevante dazu durchgelesen und bin mir da jetzt auch ziemlich sicher.

  7. Jap, du hast Recht: Ich habe es gestern nochmal mit einer defekten DVD getestet und habe mit “-n” auch nicht den gewünschten Erfolg gehabt: Damit brach die Rettung bei mir sehr frühzeitig ab. Ich habe daher die erste Artikel-Version wiederhergestellt. Ich hoffe, dass ich meine Änderungen mit dem Hinweis am Ende transparent genug gemacht habe. Eine bequeme Möglichkeit, einfach auf die (falsche) frühere Revision zu verlinken, gibt es leider nicht.

    Vielen Dank für deine Mühe!

  8. Mal ne Frage: Soll das nen Tag dauern? Ich versuche grade eine DVD zu rippen die einen Kratzer hat, aktuell hat ddrescue im ersten Lauf 7 Fehler gefunden und rödelt seit weit über 12 Stunden vor sich hin…

  9. Ja, ich muss ehrlich sagen, dass ich das Problem zur Zeit auch habe und nach einer Möglichkeit suche, das zu umgehen. Technisch gesehen ist es ja so, dass ddrescue so spezifiziert ist, dass es (wenn ich das richtig sehe), die defekten Sektoren ausliest, wenn alle lesbaren bereits kopiert wurden.
    Praktisch scheint es aber so zu sein, dass ddrescue (wie auch dd_rescue) streng linear vorgeht. Ich wäre da sehr an einer Abhilfe interessiert.

    Teilweise kann man mit dem “-i” Parameter arbeiten und damit gewissermaßen die defekten Sektoren manuell überspringen. Bei stark zerkratzten DVDs bringt das aber sicher auch nicht viel. “-n” führt anscheinend auch nicht immer dazu, dass nur die lesbaren Sektoren behandelt werden, sondern manchmal auch dazu, dass beim ersten defekten Sektor abgebrochen wird.

    Sehr merkwürdig das alles.

  10. Also insgesamt doch nicht so nützlich wie erhofft?

  11. Naja, es ist schon so, dass man mit dem Parameter -n erstmal alle lesbaren Blöcke kopieren kann und defekte Blöcke damit übersprungen werden. Nur bricht -n manchmal auch “zu früh” ab. Prinzipiell würde ich es aber immer damit versuchen.

    In einem zweiten Durchgang kannst du dann die defekten Blöcke nochmal durchtesten. Hierbei hilft es, wenn man die Anzahl der Versuche limitiert.

  12. Datenrettung | Finns Blog - pingback on 6. Dezember 2010 um 18:48
  13. Ich habe hier gerade eine Festplatte mit defekten Sektoren und versuche das mit dem “-n” Schalter auch gerade zu verstehen (mein Englisch lässt mich da etwas im Stich). Also ich habe jetzt ein “Backup” von /dev/kaputte_platte nach /dev/neue_plattte mit “-n” getriggert. Und merke er hängt sich an defekten Blöcken auf. Also ddrescue zeigt keine Errors lässt sich aber sehr lange Zeit. Kann das sein?

    Weil ich dachte eigentlich auch er überspringt die erst mal, aber scheinbar zahlt sich die Hartnäckigkeit aus und er liest sie. Nur braucht das ewig lange. Also für 12 Kilobyte eiert ddrescue jetzt schon 10 Minuten rum…

    Kan man das auch schon limitieren? Bzw. für “Runde 2″ aufsparen? Oder ist das eher Sinnfrei (weil er sie ja anscheinend irgendwann doch noch gelesen bekommt)

  14. Also das ist eine 2Gb Platte und er steht jetzt bei 755816 MB (755799 vor ca. 15 Minuten). Das könnte jetzt länger werden wenn er so weitermacht :)

    Mir ist nicht so ganz klar was bei “-n”
    “Stop after the trimming pass.”
    heisst.

    http://www.gnu.org/s/ddrescue/manual/ddrescue_manual.html

  15. Vieleicht kann ich noch etwas Licht ins Dunkel bringen.

    Zunächst beziehe ich mich mit “Anleitung” auf:
    http://www.gnu.org/s/ddrescue/manual/ddrescue_manual.html

    Grundsätzlich: ddrescue klappert lt. Anleitung “sector by sector” nach folgendem Algorithmus ab:

    - versuche Sektor zu kopieren
    - versuche Sektor zu trimmen
    - versuche Sektor zu splitten
    - versuche es nochmal (retry)

    Was das im Einzelnen ist: Keine Ahnung. Außer “kopieren”.

    Sektoren/Blöcke:
    Sind zwei Paar Stiefel. Werden aber oft synonym benutzt.
    Sind in der Regel aber gleich groß.
    Siehe Wikipedia, Kapitel “Physischer Aufbau der Scheiben”

    Wir suchen ja in der Regel nach “Defekten Blöcken” während
    ddrescue von Sektoren spricht. Nur um Verwirrungen vorzubeugen. Oder auch nicht :)

    Jetzt zu dem ominösen “-n” Schalter.
    Es ist wohl, nach meinem Verständnis, jetzt so:
    Gesunde Sektoren/Blöcke werden gemäß obiger “Kette” kopiert.
    Jetzt kommt ein defekter Block/Sektor. Kopieren funktioniert nicht, also mach ddrescue den nächsten Schritt: trimmen
    Wenn das *auch nicht klappt* dann versucht ddrescue als nächstes zu splitten. Es sei denn “-n” ist gesetzt. Dann lautet die
    Regel lt. Anleitung nämlich:

    `-n’
    `–no-split’
    Stop after the trimming pass.

    Ergo: Nach kopieren versuchen und anschließendem Versuch zu trimmen bitte STOPPEN!

    Grund: Avoids spending a lot of time trying to rescue the most difficult parts of the file. This option overrides the `–max-retries’ option.

    Was passiert wenn “-n” nun nicht gesetzt ist: Dann würde ddrescue zum “splitten” übergehen. Was auch immer das sein mag :) Und sollte das auch nicht klappen, dann würde er einen “retry” versuchen. Per Default und per Anleitung: 1x pro Sektor.
    Es sei denn man definiert mit “-r” bzw. “–max-retry=n” eine
    andere Anzahl. Zum Beispiel 3 oder 0 ;-)
    Letzteres dürft dafür Sorgen das nach dem splitten eben KEIN
    retry erfolgt und der nächste Sektor dran ist.

    In anderen Worten: “-n” verkürzt in der Tat den Zeitaufwand, weil nach “kopieren” und “trimmen” eben “split” und “retry” wegfallen.

    Ein Kopierversuch findet auf jeden Fall statt. Ebenso ein trim Versuch und DAS zieht bei defekten Sektoren das Ganze in eine
    unglaubliche Länge.

    Bei mir: eine 2TB Platte braucht alleine schon gute 30 Stunden!
    Ohe Fehler. WENN Fehler auftauchen, dann kann das mit einem “-n” immer noch ungefähr dazu führen das pro MB 1-2 Minuten ins Land gehen. Frag mich keiner wovon das abängig ist.
    Das heisst: Wenn ich mal eben 100 defekte Blöcke habe, dann dauert das eben entsprechende Stunden. Ergo: Eine Platte die sehr, sehr kaputt ist, kann TAGE (!) brauchen . Und zwar auch MIT gesetztem “-n”.

    OHNE das “-n” würde nach dem trimmen ja noch das splitting kommen.

    Ich habe jetzt mal spasseshalber, nachdem ddrescue fertig war
    (49 Errors, ca. 4tausendnochwas Bytes als defekt markiert)
    mal nochmal das Ganze ohne “-n” gestartet. Er hängt jetzt schon
    eine viertel Stunde beim “splitting failed blocks” rum. Mit exat NULL Datendurchsatz! Was auch immer er da genau tut.

    Oh, ich sehe gerade das er beim “splitting” anfängt die Zeit zu
    zählen: time from last successfull read: 14.2 m

    Ein “-RT” wird da nicht mehr allzu viel bringen weil ein
    “-T” ist ein “Try again” und das “-R” für ein “aber diesmal
    drehe die Reihenfolge des Ablaufes ab: Also erst split UND retry
    und dann trimm. (Wenn ich es richtig übersetzt habe):

    Reverse direction of all copy operations. This means the copy of the non-tried blocks, splitting and retrying are run backwards, while trimming is run forwards.

    Ergo: Jeder Durchgang ist kopieren, trimm, splitt, retry.
    Ein “-n” stopt den Druchgang (für den jeweiligen Sektor( nach “trim”.

    Ich orakel mal: Ein -RT wird da nicht mehr viel rauskitzeln.

    Oh und hier: Per Default nimmt er wohl mehrere Sektoren
    pro Durchlauf (pass):

    “–c sectors” Number of sectors to copy at a time. Defaults to 64KiB

    Ok dann dürfte das mit “Sektoren” wohl stimmen, weil ein Block i.d.R. ja 512 Bytes hat. ddrescue aber eben gleich 64kIb nimmt.

    Ups…eben sehe ich das die Zeitangabe wieder bei 7.2 min. ist.
    Ok, nachdem ddrescue ja per Default 1 “retry macht” pasiert das eben zweimal. Einmal in der Reihenfolge und eben der eine retry
    dann nochmal. Oder er hat mehrere defekte Sektoren/Blöcke
    und macht das jetzt für JEDEN Blockweise. Ja Blockweise weil:

    Each sector is tried at most two times;
    the first in this step as part of a *large block read*, the second in one of the steps below as a *single sector read*.

    Oder es ist eben nur eine Information a la “Mein letzter erfolgreicher leseversuch war vor n Minuten”. Das heisst er
    kratzt also noch erfolgreich was von der Platte.
    Die errsize müsste dann runtergehen, aber braucht halt pro KB (!)
    jetzt etliche Minuten. Das tu ich mir jetzt nicht an

    Fazit: Bei defekten Platten auf jeden Fall MIT “-n” starten.
    Und ja: Das dauert sehr, sehr, sehr , sehr, sehr lange.
    Und ohne “-n” vermutlich um ein vielfaches NOCH länger :)
    Eine entsprechend “geschredderte Platte” kann also schon auch mal MEHRERE TAGE benötigen!

    Daher erst mal MIT “-n” Versuchen und wer dann noch Zeit und Lust hat, kann dann eine 2. Runde OHNE “-n” starten…
    Ich tu mir das jetzt nicht an.

    Vielleicht meldet sich ja noch jemand :)
    Bei einer Google suche nach “ddrescue” ist der Blog-Artikel hier an dritter Stelle :) Vielleicht erleuchtet und noch jemand was split und trim genau machen.

  16. Oder eben SO:

    #Erfasse zuerst die meisten fehlerfreien Bereiche auf die Schnelle:
    ddrescue -B -n /dev/old_disk /dev/new_disk rescued.log
    #Versuche dann soviel wie möglich von den heiklen Bereichen wiederherzustellen:
    ddrescue -B -r 1 /dev/old_disk /dev/new_disk rescued.log

    Gefunden bei:
    http://www.cgsecurity.org/wiki/Besch%C3%A4digte_Festplatte

    Wobei -B:
    Show units with binary prefixes (powers of 1024).
    SI prefixes (powers of 1000) are used by default. (See table below).

    und -r1 eben “1 retry” ist.

    Also im Grunde das was ich eben geschrieben habe :)

  17. Danke für die Vertiefung und Aufklärung :)

  18. Hey. Bin hier nach langer zeit zufällig mal wieder gelandet.

    Weil scheinbar immernoch Unklarheit besteht möchte ich nochmal stichpunktartig die Vorgehensweise darstellen. ddrescue ohne jede Option:
    1. lese in großen Blöcken, wenn defekter Sektor überspringe einen Bereich und lese weiter in großen Blöcken
    2. lese die übersprungenen Bereiche sektorweise rückwärts, bis defekter Sektor kommt (trimm)
    i. -n würde an dieser Stelle aufhören, es gibt jetzt nurnoch gelesene Bereiche, die von kurzen ungelesenen Bereichen unterbrochen werden. Die ungelesenen Bereiche beginnen mit einem bad-sector und enden mit einem bad-sector
    3. lese die ungelesenen Bereiche, wenn zu viele bad-sectors kommen teile den Bereich auf (split) und lese ab der 2. Hälfte weiter. Teil 3 wird so lange wiederholt bis keine ungelesenen Blöcke mehr vorhanden sind.
    4. lese alle bad-sectors erneut und wiederhole Schritt 4 -r Mal

    Natürlich kann schon der aller erste Schritt ewig (Wochen bis Monate) dauern, wenn der Datenträger entsprechend beschädigt ist. Man denke nur mal daran, dass das Lesen eines defekten Sektors bis zu 2 min dauern kann und wenn man 100000 davon auf der Platte hat bringt es auch nicht sehr viel, wenn man durch überspringen nur 10000 davon liest ist man immernoch 13 Tage am lesen und bei solchen Platten gibt es ja auch “gerade noch lesbare” Sektoren, die aber auch so ihre 30 Sekunden brauchen.

    So ist das halt, wer kein Backup macht muss geduldig sein oder halt Backups machen. ;)

  19. PS: Es gibt auch noch die Optionen um Bereiche zu überspringen, wenn man meint das es weiter hinten wieder besser wird kann man das durchaus probieren, das Logfile erlaubt ja jederzeit eine Unterbrechung.

  20. Daten aus defekter Partition retten - pingback on 7. Mai 2012 um 14:28
  21. Hi,

    ich spiegel grad mit ddrescue eine 320GB Platte, die anscheined KEINEN mechanischen Defekt hat und da rast ddrescue.
    Wird keine 3 Std. dauern für 320GB.
    Meine Option ist:
    ddrescue -r0 -d -v -n

  22. Datenrettung mit ddrescue « My computer stuff - pingback on 24. Januar 2013 um 20:30

Kommentar schreiben


Hinweis - Du kannst dies benutzenHTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackbacks und Pingbacks: