ddrescue / Datenrettung dauert zu lange, andere möglichkeiten?

[end0fseven]

Guten Nachmittag

Ich versuche gerade von einer bekannten eine Datenrettung durchzuführen. Leider scheint das ganze nur sehr mässig zu funktionieren.

Folgende Parameter habe ich mit ddrescue versucht.

Die Festplatte scheint leider wirklich sehr langsam zu funktionieren?
Gibt es vielleicht noch eine andere möglichkeit die Platte anders auszulesen?

Wenn ich versuche die Platte zu Mounten kriege ich nur folgende Fehlermeldung:

Wenn das alles nichts bringt, würden wir vielleicht die Festplatte bei einer anderen Datenrettungsfirma einschicken. Die Offerte die sie gekriegt hat würde sich auf 2100€ belaufen..

 

[madmax2010]

nichts liest eine sterbende HDD zuverlässiger und vorsichtiger, als ddrescue.
Wenn du damit nicht weiter kommst, bzw ddrescue es nicht schafft, muss es der professionelle Weg sein

 

[Smily]

würden wir vielleicht die Festplatte bei einer anderen Datenrettungsfirma einschicken.

Das kommt darauf an, wie wichtig die Daten sind. Ich weiß ja nicht, was genau die Platte hat. Aber was du gerade machst, ist eine wahnsinnige Belastung für die Platte. Eventuell machst du gerade viel mehr Schaden, als das du hilfst!
Und was von der Platte gekratzt wurde, das ist weg, das kann niemand wieder herzaubern. Auch nicht für 2100 €. Also angenommen, da schleift der Lesekopf. Weiß man ja nicht.

Ansonsten ist ddrescue die beste Wahl. Hilft das nix, dann muss man die einzelnen Platten halt ausbauen, in eine neue Platte einbauen (oder ein Lesegerät), einstellen und davon lesen. Und eventuell muss man mehrmals eine neue Platte kaufen. Und zurück bekommst du das ganze wieder auf einer neuen Platte. Und das ... kostet halt die 2100 €.

In 181 Tagen wird die Platte aber wahrscheinlich Kernschrott sein. Und du keine Daten haben.

 

[BFF]

ddrescue ist schon das Mittel der Wahl zum Auslesen.
Und immer dran denken. Das was gesichert werden soll niemals mounten. ddrescue braucht das nicht.

Gibt es vielleicht noch eine andere möglichkeit die Platte anders auszulesen?

Ja. Nur bringt Dir das keinen Zuwachs an Geschwindigkeit wenn es um das Image geht.
Falls der Datentraeger per USB angeschlossen ist, kannst Du versuchen das Ding direkt per SATA wenn es eine SATA HDD/SSD ist.

 

[kartoffelpü]

Ein Versuch wäre, nur die benötigte Partition (und nicht die komplette Disk) per ddrescue zu sichern.
Mit etwas Glück ist der problematische Bereich nur im Bereich der EFI- und Recovery-Partition.
Aber wie bereits geschrieben wurde, jeder weiter Versuch kann es noch schlimmer machen.

 

[end0fseven]

@Smily Laut der Offerte ist der Lesekopf nicht beschädigt, sonst hätte ich es nicht versucht. Die Platte scheint nur unglaublich viele Fehlerhafte Sektoren zu haben. Habe aber an dieser Stelle nun abgebrochen da ich mir auch bewusst bin das ich damit unter umständen mehr schaden verursachen kann.

Ich habe einfach schon öfter gehört, dass es gewisse Datenrettungsfirmen gibt die eher "Scam" sind und viel zu viel Verlangen. Wenn das jedoch gerechtfertigt ist, dann ist ja gut.
Oder kennt noch jemand eine gute Firma?

@BFF Leider ist das eine WD My Passport mit direktem USB 3.0 auf der Plattine. Per SATA geht das leider nicht.

 

[Piktogramm]

Interessant wären ja die SMART-Werte der HDD und der Inhalt vom Logfile. Eine Aufnahme wie die HDD beim Arbeiten klingt gäbe wahrscheinlich auch Hinweise.

Dann wäre noch die Frage, wie die defekte HDD angeschlossen ist. Natives Sata ist zu bevorzugen und eigentlich sollte auch das Ziel ein internes Laufwerk sein. USB-HDDs haben je nach verwendeter USB-Sata Bridge ein paar Probleme, die der Kernel nicht zu 100% abfangen kann.
Und Selbst bei nativem Sata gibt es ein paar PCIe zu Sata Controller, die problematisch sein können.

 

[BFF]

Das ist mal wieder doof mit einer WD und angeloetetem USB. @end0fseven

Was ist denn mit der Platte ueberhaupt passiert, dass die gerettet werden muss. Runtergefallen im Betrieb?
Rein aus Interesse, bei wem hast Du angefragt? 2100 Euronen Angebot ohne die untersucht zu haben? Oder warst Du da vor Ort?

Ontrack macht eigentlich fuer WD die Datenrettung in D.

 

[end0fseven]

@Piktogramm Das Logfile kann ich sonst noch anhängen. Eine Aufnahme kann ich bei bedarf auch noch liefern.
Welches Tool wäre unter Linux Mint am besten für die Smartwerte?
Leider kann die defekte Platte nur per USB Betrieben werden. Intern habe ich leider keine 1TB Frei. Ich habe eine WD Red 3TB an einem NexStar (Model: NST-DP100S3) als externes Ziel.
Mir ist bewusst das dies nicht ganz Optimal ist. Jedoch ist mein Notebook an einem Platz wo mich die Datenrettung nicht stört und ich es durchlaufen lassen könnte.

@BFF Mechanisch hat die Festplatte nie was abgekriegt. Wurde für Backups eingeschalten und wieder in den Schrank gelegt.

Das war die Firma MPD Datenrettung. Die bekannte hat die Festplatte dort eingeschickt.

Folgende Diagnose: "Nach Analyse Ihrer Festplatte haben wir festgestellt, dass diese zahlreiche Defekte in den Sektorenaufteilungen aufweisen. Die Ursache eines solchen Fehlers liegt liegt im Allgemeinen in sogenannten "Bad Blocks", fehlerhaften Datenblöcken oder in Beschädigungen an den magnetischen Platten innerhalb der Festplatte. Dadurch kann der Lese-/Schreibkopf die Daten auf der Festplatte nicht orten."

 

[Smily]

Laut der Offerte ist der Lesekopf nicht beschädigt,

Aber woher wissen die das?
https://www.ontrack.com/de-de/ und Convar https://datenretter.de/ sind natürlich auch teuer, aber kein Scam.
Wenn du Datenrettung günstig bei Gogle suchst, dann kommt evetuell Scam^^.

Ergänzung (27. März 2025)

Ahso, die war schon weg!

 

[kieleich]

ddrescue, bleibt gerne mal an langsamen stellen hängen, statt zu überspringen

leg mal --min-read-rate=1M dazu oder setze von hand eine --input-position weiter hinten

die langsamen bereiche, kann man dann am ende noch mal versuchen

manchmal kann auch --reopen-on-error helfen

nebendran dmesg offen halten falls der controller spinnt, manche können mit defekten platten nicht umgehen! anderes system probieren

Ergänzung (27. März 2025)

ps: viele viele defekte blöcke, quer verteilt, sind schon starkes indiz auf mechanisches/lesekopf problem. zaubern wird ddrescue da nicht mehr aber wenn der preis nicht in frage kommt, nimmt man was man kriegen kann

poste auch mal den log file. mit "lückentext" (fehler alle X sektoren) kann man leider noch weniger anfangen als wenn nur eine bestimmte stelle fehlt

 

[JumpingCat]

Die Festplatte scheint leider wirklich sehr langsam zu funktionieren?

Wie verändern sich die smart Werte dabei? Reagiert die Platte überhaupt noch?

 

[Piktogramm]

Welches Tool wäre unter Linux Mint am besten für die Smartwerte?

sudo smartctl -q noserial -a /dev/sdb
Alternativ, die grafische Oberfläche für die Verwaltung der Partitionen/Laufwerke sollte auch SMART-Werte anzeigen können.

 

[end0fseven]

Ich poste dann noch das Logfile. Habe aber an dieser stelle wirklich aufgehört da ich nicht noch einen grösseren Defekt verursachen will.

# Mapfile. Created by GNU ddrescue version 1.27
# Command line: ddrescue -d -n /dev/sdb /media/christian/externeHDD/sicherung_bianca.img /media/christian/externeHDD/logfile_bianca.log
# Start time:   2025-03-27 03:20:47
# Current time: 2025-03-27 16:08:18
# Copying non-tried blocks... Pass 1 (forwards)
# current_pos  current_status  current_pass
0xB00B0000     ?               1
#      pos        size  status
0x00000000  0x1B560000  +
0x1B560000  0x00010000  *
0x1B570000  0x00990000  ?
0x1BF00000  0x00010000  *
0x1BF10000  0x01320000  ?
0x1D230000  0x00010000  *
0x1D240000  0x02640000  ?
0x1F880000  0x00010000  *
0x1F890000  0x04C80000  ?
0x24510000  0x00010000  *
0x24520000  0x09900000  ?
0x2DE20000  0x13AC0000  +
0x418E0000  0x00010000  *
0x418F0000  0x00990000  ?
0x42280000  0x00010000  *
0x42290000  0x01320000  ?
0x435B0000  0x00010000  *
0x435C0000  0x02640000  ?
0x45C00000  0x00010000  *
0x45C10000  0x04C80000  ?
0x4A890000  0x00010000  *
0x4A8A0000  0x09900000  ?
0x541A0000  0x14190000  +
0x68330000  0x00010000  *
0x68340000  0x00990000  ?
0x68CD0000  0x00010000  *
0x68CE0000  0x01320000  ?
0x6A000000  0x00010000  *
0x6A010000  0x02640000  ?
0x6C650000  0x00010000  *
0x6C660000  0x04C80000  ?
0x712E0000  0x00010000  *
0x712F0000  0x09900000  ?
0x7ABF0000  0x141A0000  +
0x8ED90000  0x00010000  *
0x8EDA0000  0x00990000  ?
0x8F730000  0x00010000  *
0x8F740000  0x01320000  ?
0x90A60000  0x00010000  *
0x90A70000  0x02640000  ?
0x930B0000  0x00010000  *
0x930C0000  0x04C80000  ?
0x97D40000  0x00010000  *
0x97D50000  0x09900000  ?
0xA1650000  0x0EA60000  +
0xB00B0000  0xE82EC50000  ?

Und ja, das war scheinbar die Backup Festplatte wo die Daten darauf kopiert wurden. Es existieren noch aber Dateien. Ganz alles ist nicht verloren.
Viele machen überhaupt keine Backups. Ich kenne sie auch noch nicht so lange, wir werden aber ein anderes Konzept überlegen das zumindest noch was in der Cloud ist für alle fälle.

 

[Piktogramm]

Character Meaning
'?' non-tried block
'*' failed block non-trimmed
'/' failed block non-scraped
'-' failed block bad-sector(s)
'+' finished block

https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html

Dein Log bzw. Mapfile ist die reinste Katastrophe. Es gibt Leseversuche, die schlagen fehl, ddrescue versucht den nächsten Bereich zu lesen, was wieder Fehler bedingt. Also Sprung zum nächsten Bereich, Fehler, ... Währenddessen nortiert ddrescue quasi, dass nahezu das gesamte Laufwerk Sektorweise ausgelesen werden sollte.
Ich hatte ja gehofft, dass da ein eng begrenzter Bereich Probleme macht, aber das ist schlicht absurd. Ich würde da stark zu einem Hardwareproblem neigen. Mit viel Glück sind die Platter in Ordnung und die R/W-Köpfe haben einen Treffer. Mit Pech sind die Platter bzw. die Magnetisierungsschicht im Eimer.

 

[end0fseven]

Deshalb habe ich auch abgebrochen. Da hatte die Datenrettungsfirma recht. Aber wenn in 15h nur 0.16% gerettet wurde geht das zu lange.

Wir werden schauen was sie nun machen will. Wenn sie Glück hat kriegt sie die Bilder noch von anderen Orten, dann wäre das Thema vom Tisch.

Ich danke euch allen. Habe einiges gelernt. Ist nicht meine erste Rettung, aber das erste mal nach langem und unter Linux anstelle Recuva unter Windows.

 

[JumpingCat]

Falls du weiter machen willst:

Da wurde quasi nichts kopiert. Eine Option wäre reverse (nur vorne ist defekt?) und die skip size (erstmal viel retten) viel höher setzen.

Again: Smart Werte sind stabil?

 

[kieleich]

die ddrescue map files sehen "immer" so aus solange der vorgang nicht abgeschlossen ist. das allein wäre noch kein grund zur sorge.

(+) wurde gelesen, dazwischen (*) gab es probleme [die werden am ende dann erneut probiert und näher eingegrenzt, hier können auch kabel/controller/... probleme mit rein spielen], und (?) der rest wurde noch gar nicht probiert.

gelesen wurde also:

# pos size status
0MiB     437MiB     +
734MiB   314MiB     +
1345MiB  321MiB     +
1963MiB  321MiB     +
2582MiB  234MiB     +

es scheint also alle ~300-400M zu fehlern zu kommen. bis hier her halt nur ein recht kleine sample size. wenn sich das weiter hinten so fortsetzt, dann ist das nicht normal. die interessante frage ist also, ob da noch ein bereich kommt. der normal gelesen werden kann.

Habe aber an dieser stelle wirklich aufgehört da ich nicht noch einen grösseren Defekt verursachen will.

weiss nicht ob das nach datenretter #1, sowie weiteren 12 stunden ddrescue, jetzt noch den unterschied macht. was immer da passiert, ist schon passiert. OK der ddrescue ist nie über den anfang hinaus gegangen, und was datenretter #1 gemacht hat weiss auch keiner. aber sonst...

wenn teure datenrettung eher unwahrscheinlich in frage kommt. würde ich mit den zuvor genannten vorschlägen weiter machen. eine read rate setzen (springen erzwingen, wenn das laufwerk so langsam ist, findet man eh kein ende sonst). kann auch sein dass es erstmal wieder schnell ist wenn der vorgang ganz neu gestartet wird. oder einfach mal manuell in die plattenmitte springen (--input-position, oder --reverse) und schauen wie es dort läuft.

--reverse ist von sich aus eine eher ungünstige option. platten haben keinen revers modus, d.h. um die von hinten her zu lesen, gibt es ständig seeks. gerade die will man eig minimieren bei angeknacksten platten. wenn lesefehler kommen muss man springen aber sonst wäre doch schöner wenn es geradeaus durch geht

 

[Piktogramm]

@kieleich
Naja der @TE hatte einen Lauf über 12h und noch >180d ausstehend bei 37kB/s Leserate. Da würde ich davon ausgehen, dass da nicht das ganze Mapfile gezeigt wurde. Der Einbruch der Leserate deutet darauf hin, dass da um fiele Sektoren gekämpft wird und die HDD verzweifels versucht Sektoren zu retten (und scheitert).
Und "immer" schaut das Mapfile so auch nicht aus, das ist schon ernsthaft kaputt.

Und @end0fseven, die SMART-Werte wären echt was wert, vor allem das Beobachten dieser, während du sowas wie ddrescue laufen lässt.

 

[kieleich]

ja aber das passiert sehr häufig mit ddrescue, das es schneckt.

ob das nun an der platte, am controller, am os oder an ddrescue selbst liegt. ich wiederhole mich zutiefst aber die min-read-rate option hat mir da schon oft geholfen und ansonsten auch mal ddrescue selber neu starten.

ddrescue ist ein gutes tool aber kein selbstläufer bei der datenrettung. ein wenig rumprobieren, ist da normal.

was hier wirklich mit der platte los ist. da ist die datenlage noch zu dünn um ein endgültiges urteil zu fällen