Tut dieser Befehl ddrescue etwas?

Während ich versuche, Daten von einer fehlerhaften Festplatte wiederherzustellen , führe ich den Befehl aus ddrescue.

Der Befehl wird seit 9 Tagen ausgeführt, und ich dachte aufgrund der Geräusche der Festplattenaktivität, dass er möglicherweise etwas bewirkt. Die Befehlszeilenausgabe sah die ganze Zeit mehr oder weniger statisch aus:

$ sudo ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:         0 B,  errsize:    500 GB,  current rate:        0 B/s
   ipos:     2539 MB,   errors:       1,    average rate:        0 B/s
   opos:     2539 MB,     time from last successful read:     9.7 d
Splitting failed blocks... 

Der eine Teil, der sich geändert hat, ist, wo es heißt iposund opos. Es dauerte 9 Tage, bis 500000 MBdie Größe des fehlerhaften Laufwerks erreicht war. Als es dort ankam, fiel es wieder zurück 0und stieg wieder an. Während ich das schreibe, geht es darum 2580 MBund zählt.

Die erstellte Bilddatei ist 0 Byte lang.

Die Protokolldatei ist ungefähr 3 MB groß und sieht folgendermaßen aus:

# Rescue Logfile. Created by GNU ddrescue version 1.14
# Command line: ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile
# current_pos  current_status
0x975C3000     /
#      pos        size  status
0x00000000  0x00862000  -
0x00862000  0x00014800  /
0x00876800  0x00800400  -
~~~~~~edited for brevity ~~~~~~~~
0x74702CCE00  0x00320000  -
0x74705ECE00  0x00025800  /
0x7470612600  0x005F3A00  -

Ich mache mir langsam Sorgen, dass dies nur Zeitverschwendung ist und überhaupt keine Daten wiederhergestellt werden.

Gibt es Hinweise auf diese Ausgabe, dass etwas Nützliches passiert?

Gibt es einen Grund, den ddrescueBefehl unverändert fortzusetzen, oder sollte ich ihn stoppen und etwas anderes tun?

Dies ist der neueste Inhalt von /var/log/syslog

Jun 10 07:29:17 homebase-i3 kernel: [568470.316436] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.316443] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.316450] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00
Jun 10 07:29:17 homebase-i3 kernel: [568470.316465] end_request: critical target error, dev sdb, sector 301925016
Jun 10 07:29:17 homebase-i3 kernel: [568470.346640] sd 5:0:0:0: [sdb] Unhandled sense code
Jun 10 07:29:17 homebase-i3 kernel: [568470.346646] sd 5:0:0:0: [sdb]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jun 10 07:29:17 homebase-i3 kernel: [568470.346651] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.346656] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.346662] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00

Ich weiß nicht, ob Sie immer noch versuchen, Daten von dieser Festplatte zu extrahieren, oder ob Sie bereits erfolgreich waren, aber falls Sie nicht erfolgreich waren und es versuchen möchten, um zu sehen, ob Sie möglicherweise verloren gehen können Bitcoins oder was auch immer, ich habe einige Änderungen an Ihren ddrescueBefehlszeilenparametern vorgenommen und Folgendes hinzugefügt:

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R

• -d, das ddrescue anweist, direkten Datenträgerzugriff zu verwenden,
• --force, das ddrescue anweist, Ihre Protokolldatei zwangsweise zu verwenden und zu lesen / schreiben, falls es sich beschwert, dass es sie nicht zum Lesen / Schreiben verwenden kann
• -R (ja, mit CAPITAL R), das angibt ddrescue, die Wiederherstellungsvorgänge in umgekehrter Reihenfolge auszuführen, anstatt die ausgefallene Festplatte im Vorwärtsmodus abzulesen. Manchmal hilft das umgekehrte Lesen, wenn der Schaden erheblich ist, da dies den Cache der Festplatte umgeht, falls dort Probleme auftreten.

Derzeit verwende ich diese Befehle (außer ich verwende den 3Befehl nicht, da ich nicht möchte, dass [NOCH] ddrescuefehlerhafte Sektoren erneut versucht werden. Ich werde dies zum letzten Mal belassen , nachdem mein erster Sweep abgeschlossen ist und ich einen großen Erfolg bei der Rettung habe Daten von meiner 1 TB Seagate-Festplatte, bei der ich davon ausgehe, dass sie möglicherweise ein paar Bitcoins enthält, die ich möglicherweise in den Jahren 2009 bis 2010 abgebaut habe. Wahrscheinlich habe ich 1 bis 3 Blöcke mit jeweils 50 BTC gefunden. Ich hoffe, sie befinden sich auf dieser Festplatte. Ich werde insgesamt über 15 Tage brauchen, um den Vorgang mit einer Leserate von durchschnittlich 634 kbps abzuschließen.

Außerdem möchte ich hinzufügen, dass Sie aufgrund Ihrer bisherigen Erfolgsbilanz von mehr als 9 TAGEN "letzter Leseaktivität" möglicherweise auf eine Situation stoßen, in der sich die Festplatte nur weigert, weiterzulesen Drücken Sie in diesem Fall einfach STRG + C, um den Vorgang abzubrechen, da Sie eine Protokolldatei verwenden. Entfernen Sie das SATA-Kabel von der ausgefallenen Festplatte, nicht jedoch den USB-Controller vom USB-Anschluss (ja, verwenden Sie einen USB-SATA-Controller, anstatt ihn anzuschließen ein Motherboard, damit Ihr gesamter Computer nicht gesperrt wird und Sie einen Neustart erzwingen müssen. Schließen Sie dann die SATA-Stromversorgung wieder an, um die Festplatte neu zu starten. Geben Sie ihr etwa 10 Sekunden Zeit und drücken Sie dann den Aufwärts- oder Abwärtspfeil, um Ihr vorheriges Terminal neu zu laden Befehl und starten Sie dieddrescueBetrieb, dank Ihres vorherigen Protokolls wird es dort fortgesetzt, wo es zuletzt aufgehört hat, und es wird gelesen, und der "letzte erfolgreiche Lesevorgang" muss immer bei "0s" (null Sekunden) bleiben, wo er sollte, was anzeigt, dass ddrescueer erfolgreich ist Lesen von der Festplatte, und wenn Sie jemals bemerken, dass der "letzte Lesevorgang von" beginnt, Sekunden zu zählen, beenden Sie ihn einfach erneut ddrescuemit CTRL+ C, schalten Sie die Festplatte aus und wieder einddrescueEs macht keinen Sinn zu warten, ob das "letzte Lesen von" von selbst wieder auf 0 zurückgesetzt wird. Nach meiner Erfahrung wird es niemals passieren. Sie werden auf die Ewigkeit warten. Ich musste meine schlechte 1-TB-Festplatte insgesamt etwa 20 Mal aus- und wieder einschalten. Es sind ungefähr 7 Tage vergangen, und ich bin kurz davor, die 500-GB-Wiederherstellungsmarke zu erreichen, auf halbem Weg noch, ich hoffe, ich werde keine größeren Fehler feststellen Ich bin fast 100%, da es in den letzten 3 Tagen einwandfrei gelaufen ist, wieder mit über 634 kbps.

Seien Sie auch nicht gierig auf den Versuch, eine schnellere Leserate für den Datendurchsatz zu erzielen, da mein Versuch, viele Parameter und verschiedene Blockgrößen auszuprobieren, fast zu einem absolut harten Lauf führte, der nach dem Aus- und Einschalten in mehr als 1 Sekunde nicht mehr funktioniert (das war vor 5 Tagen), aber zum Glück zeigte es gerade wieder ein Lebenszeichen und las anfänglich mit 2.000 bs (ja BYTES pro Sekunde) etwas weniger als 2 kbps. Ich war sehr enttäuscht, aber nachdem ich abgesagt hatteddrescuemit STRG + C und einfachem Neustart (umgekehrt mit dem hinzugefügten -R-Parameter) ging die Geschwindigkeit dann auf 630 zurück, bevor ich mit 930 kbps vorwärts las, zumindest bin ich zufrieden, dass ich 630 kbps rückwärts mache und wenn Sie nicht mit 2 kbit / s aufschieben müssen. Wenn Sie also bei einer Lesegeschwindigkeit wie dem 500-kbit / s-Bereich einen Erfolg erzielen, bleiben Sie dabei und versuchen Sie nichts, um die Geschwindigkeit zu erhöhen. Dies könnte Ihr letzter erfolgreicher Versuch sein, zu gewinnen jede Lesegeschwindigkeit.

Wenn ddrescuees für Sie nicht gut ist, weil Sie unabhängig von den von Ihnen versuchten Parametern nichts lesen können, sollten Sie alternativ in Betracht ziehen, die Logikplatine von der Festplatte zu ersetzen, da in 90% der Fälle die Logikplatine verwendet wird schlecht, aber zuerst nehmen Sie die Hauptplatine ab und reinigen Sie alle Kontakte, die Kontakte mit den Stiften der Festplatte herstellen. Manchmal enthält diese Kontakte eine schwärzliche, klebrige Mischung, die den Kontakt trennt, was die Ursache für Ihren Fehler sein könnte. Beachten Sie jedoch, dass Sie, wenn Sie die Logikplatine Ihrer Festplatte austauschen müssen, dieselbe Marke, Seriennummer (nahe), Modellnummer und Revisionsnummer erhalten müssen, da diese so nahe wie das Original für sein muss das Spendergremium zur Arbeit.

Sie sollten in der Lage sein, anzuhalten, ddrescueda die Protokolldatei verwendet wird, um den Betrieb (in der Nähe) an der Stelle neu zu starten, an der sie übrig geblieben ist. Ich würde jedoch überprüfen, ob die Protokolldatei kürzlich aktualisiert wurde, indem ich mir den Zeitstempel ansehe oder dies tue tail -f /home/dave/recovery_usb500.logfile.

Dass Ihre Image-Datei immer noch so klein ist, hat möglicherweise damit zu tun, dass noch keine Blöcke erfolgreich vom Laufwerk abgerufen wurden. Das wäre jedoch nach all der Zeit ein schlechtes Ergebnis. Angenommen, das Gerät enthält nur wenige fehlerhafte Blöcke und diese befinden sich nicht am Anfang. Der Status Ihrer ersten Einträge lautet dann +. IIRC ddrescuebeginnt mit dem Lesen, bis ein Fehler gefunden wird, und teilt dann den Rest der Disc auf. Ihre Disc scheint von Anfang an zu versagen.

Es sei denn, es gibt (mehrere) +Einträge im Protokoll und Ihre Dateigröße wäre immer noch. 0Ich denke nicht, dass dies ddrescuefalsch ist. Nein, das +bedeutet, dass nichts von Ihrem Laufwerk wiederhergestellt werden konnte. Das könnte gebratene Elektronik oder einen schlechten Kopf bedeuten, denn wenn nur einige Sektoren fehlerhaft wären, hätten Sie viel schneller Ergebnisse erzielt.

Was etwas anderes angeht. Ich nehme an, Sie haben bereits versucht, ein paar Blöcke mit normalem dd zu lesen. Haben Sie sich das darauf basierende Syslog angesehen und alle dort gefundenen Nachrichten gegoogelt?

Die Suche nach "Ergebnis: Hostbyte = ungültiges Treiberbyte = DRIVER_SENSE" führt zu einigen interessanten Lesungen (teilweise deutsch) mit einigen weiteren Vorschlägen:

• Versuchen Sie, eine Verbindung über USB 1.1 anstelle von 2.0 herzustellen
• Das Laufwerk kann zu heiß werden. Wickeln Sie es daher in Plastik ein und stellen Sie es 10 Minuten lang in den Kühlschrank. Dies gibt eine gewisse Lesbarkeitszeit, bevor sich das Laufwerk wieder erwärmt.
• Schalten Sie SMART im BIOS um (und verbinden Sie sich mit SATA).
• Stellen Sie sicher, dass das USB-Laufwerk über ausreichend Strom verfügt (zusätzliches Netzteil).
• Wenn das Lesen über USB nach einiger Zeit fehlschlägt, verwenden Sie einen ferngesteuerten USB-Hub, an dem Sie die Stromversorgung vom USB-Hub zum Laufwerk für einige Sekunden programmgesteuert umschalten.

Abgesehen vom Kühlen einer nicht lesbaren Festplatte (mit Kühlspray) habe ich selbst keine davon ausprobiert.