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

[Evil E-Lex]

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.

Da RescueZilla ein Live Linux ist, wird das gesamte System im RAM ausgeführt, dort liegt auch die Datei. Da du im Home-Verzeichnis des Root-Benutzers bist, liegt die Datei in /root.

Ergänzung (11. Dezember 2024)

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]

UPDATE

Auch dieser Thread kann als gelöst markiert werden.
Nachdem dd_rescue den allergrößten Teil problemlos kopieren konnte, habe ich im zweiten Durchlauf dann 3 Suchrunden (r3) auf den restlichen nicht kopierten Teil losgelassen.

Ich glaube, viel konnte er da nicht mehr rausholen, also hab ichs dabei belassen. Hier der Screenshot des ersten Durchlaufs von 21,5h (das hat bedeutend länger gedauert für eine 2TB HDD als im anderen Thread das reine Kopieren meiner 6TB HDD)...

Resultat:
Auch hier ließ sich, wie im anderen Thread, die Festplatte mit VC ganz normal mounten (diesmal sogar ohne vorherige Reparatur des Headers, denn dieser war gar nicht beschädigt) und ich kann nun auf die Daten zugreifen.

Der Head-Crash hat einige wenige Daten korrupt gemacht, aber was ich bislang gesehen habe, waren das keine wichtigen bzw. redundante, von denen ich Backups habe.

Die beschädigte HDD (bzw. viel eher der Klon davon) wurde jetzt "leer-kopiert" bzw. alles notwendige gesichert und wird dann entsorgt.

Vielen Dank an alle, die mir hier und auch im anderen Thread tatkräftig Unterstützung gegeben haben. dd_rescue ist schon ein feines Tool. Bei Ontrack hätte ich jetzt sicherlich über 2000€ bezahlt, vor allem, wenn dann auch noch Verschlüsselungen etc mit ins Spiel kommen.

Ich denke, jetzt ist erst mal für ne Weile gut mit Datenrettung. Ich arbeite künftig eher mit VC-Containern auf einem bereits bestehenden, nicht-verschlüsselten NTFS-Partitionssystem. Auch VC-Container kann man zusätzlich absichern, indem man deren Header/Kopfdaten extern sichert. Zudem lassen sich VC-Container, genau wie WinRAR-Verschlüsselungsdateien, auch in der Cloud und damit multilokal (als Backup) ablegen, falls ein Container mal defekt sein sollte.

 

[Donnerkind]

Letztlich sind nur 30 kB kaputt, das ist eine kleine JPG-Datei. Diese verteilen sich auch noch auf 16 Bereiche, also im Schnitt 2 kB kleine Einzel„löcher“.

Weil ichs auf dem Bild gerade sehe: wenn man root ist, braucht man kein sudo zu benutzen. Sudo holt sich root-Rechte, wenn man eben nicht root ist.

 

[Marvolo]

Letztlich sind nur 30 kB kaputt, das ist eine kleine JPG-Datei. Diese verteilen sich auch noch auf 16 Bereiche, also im Schnitt 2 kB kleine Einzel„löcher“.

Krass! Und wegen diesesn 30 KB hat die Originalplatte so derart Stress gemacht und das gesamte Windowssystem derart verlangsamt, dass irgendwann nicht mal mehr das Mounten mit VC ging...

 

[Donnerkind]

Vielleicht hat ddrescue mehrere Anläufe gebraucht, bestimmte Sektoren zu lesen. Das würde die hohe Dauer erklären. Wenn Windows einen Fehler bekommt, dann denkte es ein paar Minuten nach und hebt dann die Hände in die luft.
Ich dachte noch an eine ungünstige Sektorengröße; ddrescue nutzt standardmäßig 512 Byte. Aber bei Festplatten ist das eigentlich korrekt, außer es ist eine native 4K-Platte, was aber eher selten ist.

 

[Fusionator]

Ich arbeite künftig eher mit VC-Containern auf einem bereits bestehenden, nicht-verschlüsselten NTFS-Partitionssystem.

Es gibt da noch einen "Trick", den man machen kann. Ohne 100% Gewähr meinerseits, aber ein kurzer Test bei mir hat erwartungsgemäß funktioniert.
Man legt sich eine (oder meinetwegen auch mehrere) große recovery Partition an, die nicht formatiert wird und auch keinen Laufwerksbuchstaben zugewiesen bekommt.
Zusätzlich werden die gpt attribute verändert, so dass die Partition als nicht löschbar in der Datenträgerverwaltung erscheint.
Nach dem erstellen der Partition mittels Diskpart, kann man die Partition(!) mit Veracrypt verschlüsseln.
Der Vorteil ist, dass man im Exlorer nichts formatieren oder löschen kann (Container) und die Datenträgerverwaltung lässt die Platte auch in Ruhe.

Hier ein Beispiel (für Diskpart) für eine theoretische Disk 6

sel disk 6
clean
convert gpt
create partition primary
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001

Den relevanten Befehl habe ich mir von hier geklaut. Rest sollte Grundwissen Diskpart sein.
DiskGenius sollte auch in der Lage sein, so eine Aktion durchzuführen (vermutlich bis auf die GPT Attribute; die kann man dann im Nachgang mit Diskpart setzen)

Ergänzung (11. Dezember 2024)

Kleiner Nachtrag, weil irgendwo mal der Einwand kam, dass auch eine normale Partition funktionieren würde.
Möglich, dass man durch setzen der gpt Attribute auch mit einer Basic Partition das Gleiche erreicht.
Ich habe es nicht ausprobiert! Also einfach mal ein paar kleine Testdatenträger organisieren und der Kreativität freien Lauf lassen

 

[Marvolo]

@Fusionator

Wäre diese Partition auch außerhalb eines laufenden Windows vor Löschen sicher?
Weil in meinem anderen Thread hat mir ja der Windows-Setup ohne mein Wollen und Wissen die 50mb system-reserviert-Partition auf meine verschlüsselte VC-Platte geschrieben.

Die war unter Windows nicht-initialisiert und hatte demnach auch keinen Laufwerksbuchstaben o.Ä..

 

[Fusionator]

Wäre diese Partition auch außerhalb eines laufenden Windows vor Löschen sicher?

Unter Linux wohl eher nicht. Aber da muss man auch aktiv Mist bauen

Weil in meinem anderen Thread

Den Thread habe ich still genossen Die Windows Installationsumgebung ist ja trotzdem ein "laufendes" Windows. Da siehst du die Partition exakt so, wie in der Datenträgerverwaltung.
Es ist ein WindowsPE. Halt stark abgespeckt.
Würdest du Windows absichtlich anweisen in der Partition zu installieren, würde es mit einer Fehlermeldung abbrechen (falls die überhaupt auswählbar sein sollte)

 

[recu]

dd_rescue

Nein, ddrescue. Dein ddrescue ist das von der GNU-Foundation.
dd_rescue ist von Knut Garloff.

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

Das weiß ich nicht genau, ich glaube, auf der Wurzelebene des Benutzerverzeichnisses.

Sinnvoll ist folgende Vorgehensweise:

Du mountest Deinen externen "Protokoll"-Datenträger entweder über die graphische Oberfläche, falls vorhanden, oder mit Hilfe des mount-Befehls.
Der "Protokoll"-Datenträger ist nun im Dateisystem eingehängt und statt logfile gibst Du einen vollständigen Pfad zum logfile an, z.B.

ddrescue -f /dev/sda /dev/sdb /mnt/sticks/mylogfile.txt.

Wenn Du Angst hast, dass Dein USB-Stick die zahreiche Schreibvorgänge auf Dein logfile nicht überlebt, kannst Du auch alternativ eine kleine HDD im externen Gehäuse anschließen.

Ergänzung (13. Dezember 2024)

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)

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?

Mit STRG C den Prozess abbrechen und warten! bis das "Command Prompt" wieder erscheint.
Dann logfile zum Ziel hin kopieren.
Kopie mit Editor öffnen, gucken ob die Aktion erfolgreich war.

Ich gebe der Logdatei immer die .TXT-Endung, dann öffnet das Rettungs-Linux die Datei auch gleich mit einem Editor, wenn ich draufklicke.

 

[Marvolo]

Hi @recu

Danke für die Erläuterungen. Das Projekt ist aber bereits abgeschlossen. Auch hier war ich erfolgreich, wie im anderen Thread auch.

Das nächste Vorhaben bezieht sich auf 2 selbstgebrannte CDs á 700MB. Da löst sich aufgrund des Alters (20 Jahre) punktartig die obere Datenschicht. Das normale PC-Laufwerk kann sie deshalb nicht mehr kopieren in eine ISO-Datei, bzw. hängt sich an den nicht-lesbaren Stellen auf.

Ob hierfür auch gnu_ddrescue geeignet ist?
Oder eher sowas wie DVDisaster?
https://secnigma.wordpress.com/2022/05/08/a-guide-to-recovering-damaged-and-rotten-cds/

Oder braucht man dafür womöglich komplett andere Auslesetools und evtl. auch spezielle CD-Laufwerke, die sich nicht direkt beim ersten Lesefehler aufhängen und irgendwann abbrechen?

 

[kieleich]

ddrescue wäre geeignet, und du kannst mehrere Durchgänge, mit verschieden Laufwerken machen.

Aber, wenn sich die Datenschicht ablöst ist einfach Game Over. Wirst nicht weit kommen, aber probiers aus

 

[BFF]

Da kann man einfach unstoppable copier nehmen.