Daten retten von heruntergefallener Festplatte, die jetzt auf einmal sehr langsam nur noch reagiert

[recu]

Marvolo, ich habe meine kleine Anleitung komplettiert. Schau' Dir noch einmal den Link oben an!

Zu 1: Nein, ich beziehe mich auf die Aussage des Themenerstellers, in der er angibt, dass das Mounten nicht mehr funktioniert. Ist hier irgendwo nachzulesen. 😉

Zu 2: Letztendlich ist das zu befürchten, ja - wenn die HDD nicht so oder so schon vorher komplett abraucht durch den Stress mal gerade 2 TByte zu klonen. 🤔

Das ist halt das Risiko, das immer besteht, wenn man sich für eigene Rettungsversuche entscheidet.

 

[Donnerkind]

Es fängt erst an zu lahmen, nachdem oder während VC versucht sie zu mounten. Heißt das nicht, dass die Platte an sich vielleicht noch OK ist, aber vielleicht nur das Dateisystem, das VC nun mounten will, irgendwie fehlerhaft ist?

Das Dateisystem ist fehlerhaft, weil die Stelle der Platte, auf der dieses Stück Dateisystem gespeichert ist, kaputt ist. Deshalb blockiert Windows dann und erst dann, wenn es auf diese Bereiche zugreifen will. Aus diesem Grund klappt das Mounten (der VC-Header und die MFT oder wie das bei NTFS heißt existieren), aber sobald du auf was zugreifen willst, fällt das Kartenhaus zusammen und die Platte verschwindet irgendwann wieder, weil Windows nur unsinnige Daten zurück bekommt.

Bei einem Image wären diese Bereiche dann wahrscheinlich nur Nullen. Das sind zwar auch "kaputte" Daten, aber weil die nicht von einem Lesefehler begleitet werden, bleibt Windows nicht hängen und schmeißt auch nicht das gemountete Image raus.

Ist das hier das richtige Programm und der richtige Weg?

Wie schon erwähnt nein, dd macht einfach nur eine binäre Kopie von vorn bis hinten. ddrescue fängt Lesefehler besser ab, überspringt die Bereiche und schreibt erstmal Nullen ins Ziel.

Uff... Das klingt aber nicht sehr ermutigend. Liegt das jetzt am HDD-Defekt?

Die intakten Bereiche werden bei einer Datenrettung genauso schnell ausgelesen wie sonst auch. Aber sobald ein defekter Sektor angetroffen wird, versucht die Platte intern, die Daten auszulesen. Das kann ewig dauern (und das OS blockiert solange). Die Software bekommt dann irgendwann eine Fehlermeldung und versucht es u.U. nochmal, und nochmal. Und dann wird jedes Mal aufs Neue auf die Festplatte gewartet.

Das ist übrigens auch der Unterschied zu Serverplatten: die melden direkt nen Lesefehler und blockieren aber nicht, weil bei Servern i.d.R. RAID und ähnliches eingesetzt wird, was solche Fehler kompensiert, damit der Betrieb aufrecht erhalten bleibt.

ddrescue bleibt gerne mal zu lange an defekten stellen hängen daher, beim ersten durchgang grosszügig skippen (neustart mit offset)

Skippen macht ddrescue schon von sich aus im ersten Durchgang. Ich habe letzte Woche eine DVD mit großem sichtbaren Kratzer damit ausgelesen, da konnte man schön sehen, wie es bei Sektorfehlern Sprünge von 10 oder 100 MB gemacht hat bis es wieder intakte Bereiche gefunden hat. Da braucht es dann auch ewig für einen Sektor von 2 kiB, sodass eine DVD dann gerne mehrere Tage dauern kann bei Fehlerbereichen von mehreren 100 MB Umfang.

@Marvolo die Anleitung, die du suchst, findest du auch in der Dokumentation des zu verwendenden Programms. Ich habe jetzt keine Ahnung von ddrescue unter Windows, aber wenn du sowas findest, sollte der erste Blick auf die Webseite des Programms gehen und dort auf die Dokumentation.

 

[kieleich]

Skippen macht ddrescue schon von sich aus im ersten Durchgang.

Wenn es Lesefehler gibt ja. Wenn es einfach nur von anfang an Lahm ist, nein. Man kann Glück haben und es geht einfach so aber Hardwaredefekte können sich unterschiedlich äußern man muss eben je nachdem darauf reagieren. 3 Tage warten für paar Kilobyte lohnt nicht wenn dann immer noch alles andere fehlt. das könnte ddrescue besser machen aber ist leider nicht so gemacht das es von sich aus auf die Idee kommt, wenn es schon mal hängt

 

[Marvolo]

@Donnerkind

Danke für diese detaillierte, forensische Analyse. Interessant, auch mal zu verstehen, warum Windows hier so rumlahmt, sobald die Platte dranhängt.

Was würdest du nun sagen - lohnt sich das Auslesen mit ddrescue in dem Fall noch? Besteht die Möglichkeit, dass nach dem Auslesen das Dateisystem noch so intakt ist, dass man auf Daten zugreifen kann?

Oder ist das alles mehr oder weniger zum Scheitern verurteilt und der Aufwand kann gespart werden?

 

[Donnerkind]

Wenn du jetzt eh sagst "da probiere ich nichts mehr, die Platte ist hin", dann kannst du ebensogut riskieren, sie mit einem kompletten Auslesen endgültig zu schrotten. Solange du das Image dann mit VC noch geöffnet bekommst, könntest du photorec drüber laufen lassen, um Dateien aus einem kaputten Dateisystem zu kratzen.

Da ich ab und zu mal DVDs auf die Art auslese, wäre es für mich persönlich kein großer Aufwand, weil ich mich auskenne. Ob du dich da reinlesen willst, musst du wissen. Bis zu einem gewissen Grad kann man dir hier auch helfen, wenn du das per Live-Rettungslinux machen willst.

1. Linux booten, 2. Ersatzplatte anstecken, 3. Platten identifizieren, 4. ddrescue starten. Der Rest ist warten und hoffen. Leider kann man nicht wissen, wie groß der kaputte Bereich ist. Mit der Option -K kann man z.B. angeben, wie weit es springen soll, wenn ein Fehler auftritt. Wenn man den großzügig bemisst, z.B. 1 GB, springt man damit vielleicht über alle kaputten Stellen drüber. Die werden dann zuletzt probiert.

 

[Marvolo]

Da ich ab und zu mal DVDs auf die Art auslese

Braucht man dafür speziele DVD/CD-Laufwerke? Ich hätte hier nämlich - wenn wir hier eh schon bei Datenrettung sind - zwei CDs mit gebrannten Bildern aus den frühen 2000er Jahren. Offenbar löst sich hier die Schicht auf der Oberseite und damit auch die Daten auf der gebrannten Unterseite. Geht das mit ddrescue und jedem stinknormalen Laufwerk, oder braucht man da schon spezielle Datenrettungslaufwerke?

Ergänzung (23. Oktober 2024)

Wenn du jetzt eh sagst "da probiere ich nichts mehr, die Platte ist hin", dann kannst du ebensogut riskieren, sie mit einem kompletten Auslesen endgültig zu schrotten.

Es bleibt ja ansonsten nichts anderes übrig, oder? Außer mit ddrescue auslesen und versuchen zu retten, was zu retten ist. Was sonst könnte man denn noch tun, was die Platte vielleicht nicht endgültig schrottet?

 

[Donnerkind]

Ja, ich hab auch einen ganz normalen 10 Jahre alten internen DVD-Brenner benutzt und seit kurzem habe ich auch eine externes BluRay-Laufwerk. Das Schöne ist; wenn du eine CD mit ddrescue klonst, kommt da direkt ein ISO bei raus. Und was ein Laufwerk nicht lesen kann, schafft vielleicht noch ein anderes.

 

[recu]

Das hast Du sehr schön ausgedrückt! 😉



Auch beachtet dieses Vorgehen nicht, dass ein so gezogenes Image einer nicht mehr mountbaren VeraCrypt-Partition nach wie vor nicht mehr mountbar ist.

Das ist ein Denkfehler. Du hast ein Detail übersehen, eine kleine Zusatzinformation, die der Frager erwähnt hatte.

Man hätte zwar ein Image-Clon des Datenträgers - was normalerweise auch Sinn ergibt - könnte aber dennoch nichts mehr retten - es sei denn, wir fänden eine Datenrettungssoftware, die VeraCrypt beherrscht. Sachdienliche Hinweise diesbezüglich wären willkommen.

Das ist so falsch.

Ergänzung (23. Oktober 2024)

Beim "Dienstleister vor Ort" zahlste für nix. Der macht dann wirklich nichts anderes als Anstöpseln und irgendeine Softare drüber röddeln das kann man selbst

auch der Profi Datenretter wird nicht viel anders machen. Die kochen auch nur mit Wasser und verdienen ihr Geld lieber mit einfachen Fällen. die machen halt keine 100 Fehlversuche, aber wenns nicht klappt dann klappts da eben auch nicht

kein Backup = Daten weg

Was für ein haarsträubender Unsinn!!!
Echte Profis haben einen Reinraum und eine Hardwareausstattung, die fünfstellige Euro-Beträge kostet. Echte Profis haben Erfahrung, Spezialwissen, hackerartige Fähigkeiten und ein Netzwerk von Kollegen.

Der Laie merkt es im Zweifel nicht, dass er eine vorgeschädigte Festplatte zerstört.

Deswegen ist die Königsfrage bei Datenrettung immer: "Eigenfertigung" oder Fremdbezug? Selber machen oder in Auftrag geben?

 

[Marvolo]

Update zu dieser Geschichte hier:

Momentan läuft also gnu_ddrescue. Die heruntergefallene Platte gibt manchmal komische Schleifgeräusche von sich, aber das war ja zu erwarten.

Unklar ist mir aktuell noch, ob ich momentan mit dem richtigen Befehl dran gegangen bin. ChatGPT hat mir gesagt, ich solle als ersten Schritt erstmal folgendes machen:

sudo ddrescue -f -n /dev/sdb /dev/sda logfile.log

Der "-n"-Befehl soll wohl dafür sorgen, dass erstmal nur die fehlerfreien Bereiche gelesen und kopiert werden. Wenn dieser Vorgang dann beendet ist, sollte man einen weiteren starten, der wie folgt aussieht:

sudo ddrescue -d -r3 /dev/sdb /dev/sda logfile.log

Ist das alles so richtig? Momentan läuft es mit dem ersten Befehl, Restzeit fast 20h, read errors: 2 bisher und nach 12 Min Laufzeit gerade mal erst 1,03% kopiert...

Oder hätte ich direkt schon mit dem -d -r3-Befehl starten sollen?

Wo genau wird denn nun das logfile gespeichert bei den obigen Befehlen? Falls ich da mal unterbrechen will über Nacht?

Das ganze wurde über einen RescueZilla-USB-Stick gebootet und dort dann in der CMD-Zeile gestartet.

 

[kieleich]

du musst vorher mit lsblk, hdparm -i, smartctl -a ... kontrollieren ob sdb sda wirklich die geräte sind die du erwartest denn Linux verteilt diese Namen nach Zufall Prinzip (sda ist einfach die zuerst erkannte Platte und das kann jede sein oder ein USB Stick). Das kann sich jedem Reboot oder schlicht durch neuanstecken ändern. man kann da sehr schnell in die falsche richtung kopieren und dann sind die daten weg

daher sicherer eig. in eine datei zu kopieren statt mit -f force option eine ganze platte zu überschreiben

aber im prinzip kann es so gehen wieviele daten kopiert werden können kommt eben darauf an was die platte macht

wenn du nur ein livesystem gebootet hast dann wird das logfile im tmpfs sein also wenn die kiste abstürzt oder du reboot machst, dann ist es weg. kopier es dir halt auf einen stick, oder schicks in eine pastebin, bevor du abschaltest

 

[Marvolo]

du musst vorher mit lsblk, hdparm -i, smartctl -a ... kontrollieren ob sdb sda wirklich die geräte sind die du erwartest denn Linux verteilt diese Namen nach Zufall Prinzip (sda ist einfach die zuerst erkannte Platte und das kann jede sein oder ein USB Stick). Das kann sich jedem Reboot oder schlicht durch neuanstecken ändern. man kann da sehr schnell in die falsche richtung kopieren und dann sind die daten weg

Das habe ich überprüft. Die Geräte stimmen und wurden im Befehl angepasst. Der obige Befehl war der Standardbefehl von ChatGPT. Da habe ich jeweils meine Geräte sdd und sdc angepasst.

Ergänzung (10. Dezember 2024)

kopier es dir halt auf einen stick, oder schicks in eine pastebin, bevor du abschaltest

Wie genau mache ich das dann?

Also ich breche den Prozess mit STRG C ab und wie sichere ich dann die bereits vorhandene logfile bzw. schiebe sie woanders hin?

 

[redjack1000]

Momentan läuft es mit dem ersten Befehl, Restzeit fast 20h, read errors: 2 bisher und nach 12 Min Laufzeit gerade mal erst 1,03% kopiert...

Habe noch viel Geduld, ist normal.

Cu
redjack

 

[kieleich]

nein lass laufen, nur am ende (oder zwischendurch öfter mal) das logfile sichern. ein weiteres usb stick anschliessen und mounten. oder übers netzwerk schicken (pairdrop, pastebin, wasimmer)

ohne den logfile ist kein resume möglich bzw. der proziss beginnt wieder vonvorn

 

[Evil E-Lex]

Unklar ist mir aktuell noch, ob ich momentan mit dem richtigen Befehl dran gegangen bin. ChatGPT hat mir gesagt, ich solle als ersten Schritt erstmal folgendes machen:

Ach was war die Welt schön, als die Menschen noch Handbücher oder Beiträge von anderen Menschen gelesen und verstanden haben, anstatt einer angeblich allwissenden "KI" zu vertrauen.

sudo ddrescue -f -n /dev/sdb /dev/sda logfile.log

Das ist exakt der gleiche Befehl, den ich dir bereits in Beitrag #93 geschrieben hab. Nur das ich Langform der Parameter verwendet hab, da die einfacher zu verstehen ist.

sudo ddrescue -d -r3 /dev/sdb /dev/sda logfile.log

Der Befehl würde so eine Fehlermeldung werfen. Glückwunsch ChatGPT! Da du direkt von Gerät zu Gerät kopierst, muss der Parameter -f (--force) zusätzlich angegeben werden, da ddrescue aus Sicherheitsgründen den direkten Schreibzugriff auf Geräte nicht zulässt.

Ist das alles so richtig?

Ja, dass passt soweit. Du könntest aber zunächst nach dem ersten Befehl aufhören und prüfen, ob alle wichtigen Dateien da sind. Den zweiten Befehl könntest du dann immer noch ausführen, falls dem nicht so sein sollte.

 

[Marvolo]

Es bleibt also spannend.
Von der Thematik her haben wir es hier im Grunde mit einer ganz ähnlichen Ausgangslage zu tun wie bei meinem anderen Thread mit den 50mb-system-reservierter Partition, die auf eine verschlüsselte VC-Festplatte gecshrieben wurde und den ich ja mittlerweile erfolgreich lösen konnte.

Hier haben wir es auch mit einem verschlüsselten VC-Datenträger zu tun, der aber im Gegensatz zum anderen Thread weit weniger wichtige Daten erhält und der nicht durch eine 50mb-Partition überschrieben wurde, sondern heruntergefallen ist und jetzt wohl beschädigte Strukturen aufweist.

Es wird sich jetzt also zeigen, inwieweit diese beschädigten Sektoren einem erfolgreichen VC-Mounten im Weg stehen werden oder nicht. Zumal ich auch hier wieder Backup-Daten des Headers habe. Also ich gehe davon aus, dass ein Mounten und Entschlüsseln so oder so klappen wird. Die Frage ist halt, wieviele Daten werden fehlen durch die beschädigten Sektoren... Mit etwas Glück auch wieder nur solche, die für mich nicht weiter von Belang sind so wie im anderen Fall. Dort konnte ich bis jetzt keinerlei Datenverlust durch die 50mb Partition wahrnehmen.

Ergänzung (10. Dezember 2024)

nein lass laufen, nur am ende (oder zwischendurch öfter mal) das logfile sichern. ein weiteres usb stick anschliessen und mounten. oder übers netzwerk schicken (pairdrop, pastebin, wasimmer)

Also ist ein Unterbrechen, um den PC über Nacht auszuschalten, hier jetzt nicht sinnvoll? Auch wenn das Logfile gespeichert wird und es dann dort weitergeht, wo es aufgehört hat?

 

[Donnerkind]

Wo genau wird denn nun das logfile gespeichert bei den obigen Befehlen? Falls ich da mal unterbrechen will über Nacht?

Na genau da wo du ihm sagst. Du hast nur „logfile.log“ angegeben, also wird es in dem Verzeichnis gespeichert, in dem du dich zum Zeitpunkt der Ausführung des Befehls befunden hast.

Wie genau mache ich das dann?

Also ich breche den Prozess mit STRG C ab und wie sichere ich dann die bereits vorhandene logfile bzw. schiebe sie woanders hin?

Das Logfile ist eine ganz normale Textdatei. Die kopierst/verschiebst du herum wie jede andere Datei auch. Die Datei kann auch ganz woanders liegen und wenn du ddrescue ein weiteres Mal ausführst, kannst du theoretisch auch ddrescue -f /dev/sdb /dev/sda /ganz/anderer/pfad/zum/logfile.log angeben. Wichtig ist nur, dass du immer dieselbe Kombination aus Eingabe-, Ausgabe- und Logdatei angibst, weil die ja zusammengehören.

Also ist ein Unterbrechen, um den PC über Nacht auszuschalten, hier jetzt nicht sinnvoll? Auch wenn das Logfile gespeichert wird und es dann dort weitergeht, wo es aufgehört hat?

Natürlich ist es sinnvoll. Gerade dazu ist das Logfile doch da. Darin merkt sich ddrescue, welche Bereiche einer Datei oder Geräts es bereits erfolgreich lesen konnte, um den Auslesevorgang zu einem späteren Zeitpunkt fortzusetzen oder gar zu wiederholen¹. Schau es dir einfach mal mit cat an. Die Zeilen sind alle im Format „Startadresse Länge Status“, wobei ein Status von + fertig gelesen bedeutet.


¹ Ich habe über die letzten Wochen versucht, eine zerkratzte DVD auszulesen. In über einem Dutzend Durchgänge habe ich immer weitere Bereiche auslesen können, die das Laufwerk (bzw. ein anderes Laufwerk) bis dahin nicht zu lesen vermochte.

 

[Marvolo]

Das Logfile ist eine ganz normale Textdatei. Die kopierst/verschiebst du herum wie jede andere Datei auch. Die Datei kann auch ganz woanders liegen und wenn du ddrescue ein weiteres Mal ausführst, kannst du theoretisch auch ddrescue -f /dev/sdb /dev/sda /ganz/anderer/pfad/zum/logfile.log angeben. Wichtig ist nur, dass du immer dieselbe Kombination aus Eingabe-, Ausgabe- und Logdatei angibst, weil die ja zusammengehören.

Ich hatte deshalb gefragt, weil ich hier ja einen RescueZilla Live-Stick am Laufen habe. Der hat gebootet in eine Linux-artige Oberfläche und innerhalb dieser habe ich die dortige Kommandozeile genutzt, um ddrescue zu starten.

Ich weiß jetzt gerade nicht, wo innerhalb dieser Linux-Umgebung oder auf dem USB-Stick, der ja gebootet und am Laufen ist, sich dieses Logfile nun befindet bzw. wie ich dort hingelange und es umkopieren/verschieben kann.

Muss ich da mithilfe der Kommandozeile irgendwo hinnavigieren? Eine Art "Arbeitsplatz", das mir Laufwerke etc anzeigt, gibt es in dieser gebooteten Linux-Umgebung des Bootsticks nicht. Zumindest sehe ich nichts auf Anhieb...

 

[Marvolo]

PS: Das ist aktuell der Stand nach 16h Laufzeit...

Was genau bedeutet "non-tried"? Sind das die Bereiche, die beschädigt sind und die übersprungen wurden?
Das wären ja schon mal ganze 450GB

 

[Donnerkind]

Non-tried ist alles, was noch nicht gelesen wurde, also wenn es von vorne nach hinten zum ersten Mal alles liest, dann ist das der Bereich jenseits der aktuellen Position. Bereiche, die übersprungen wurden, finden sich in non-trimmed. Die „Bearbeitung“ bewegt sich in der Ausgabe quasi von links nach rechts und von oben nach unten durch die Werte: erst non-tried, dann rescued, dann non-trimmed, dann non-scraped, dann bad sectors.

non-tried: noch nicht probiert
rescued: gelesen
non-trimmed: nicht abgegrenzt. D.h. erstmal übersprungen wegen eines Fehlers. Mit trimmen wird der Bereich eingegrenzt, indem Beginn und Ende des kaputten Bereichs gefunden werden
non-scraped: die Bereiche innerhalb der trimmed area. Die werden dann „ausgekratzt“
bad: was beim Scrapen nicht gelesen werden konnte.

 

[Marvolo]

Danke für die Erklärung. Und was ist jetzt mit dem logfile? siehe #137