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 (Heute um 14:50)

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 (Heute um 17:06)

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)