Datenrettung von beschädigtem Laufwerk mit Markierung beschädigter Dateien

[Telefonkatze]

Hallo,

meine 870EVO erzeugt Fehler beim Lesen und im SMART steigen die Fehlerwerte (z.B. Reallocated Sector Count) an.

Mit Gparted (e2image und ntfsclone) konnte ich das Meiste auslesen. Allerdings zeigen mir die Tools nur während der Kopierprozesse an, welche Blöcke fehlerhaft sind, aber nicht, welche Dateien betroffen sind. Ich kann daher anschließend nicht gezielt überprüfen, welche Dateien defekt sind.

Gibt es ein Tool, welches beim Auslesen die kopierten Dateien markiert, sodass ich diese gezielt prüfen oder aus einem etwaigen Backup nehmen kann? Idealerweise würde ein Kopiertool nur auf die benutzten Bereiche zugreifen, also nicht wie dd auch die ungenutzten Bereiche kopieren wollen. Außerdem sollte das Tool eine Datei entweder mit einem Suffix umbenennen oder alternativ eine Datei mit gleichem Namen und Suffix anlegen. Dann könnte ich anschließend danach suchen und aufräumen.

Ich habe je eine ntfs- und eine ext4-Partition, die zu kopieren/retten sind. Windows habe ich nicht, bzw. nur XP und Linux Mint.

 

[coasterblog]

Windows habe ich nicht, bzw. nur XP und Linux Mint.

Ich gehe mal nur darauf ein....
Wenn du noch eine SSD/HDD da hast (leer, zum rumspielen) dann kannst du dir Win 10 oder 11 auch installieren ohne Key. Wenn du Windows Software nutzen möchtest. Bis auf das Personalisieren bist du rel frei mit dem Windows und auch legal unterwegs.

Also, ein USB Stick und ein weiterer Datnträger reichen.

 

[JumpingCat]

Das übliche Vorgehen: mit ddrescue ( oder dd_rescue) ein Image erzeugen. Dann mit Testdisk die Dateien retten.

Falls die Daten wichtig sind: Professionelle Firma beauftragen.

 

[gaym0r]

Ich bin irritiert. SSDs haben keine Sektoren - sicher, dass die SMART Werte richtig ausgelesen werden?

 

[GrumpyCat]

Mit Gparted (e2image und ntfsclone) konnte ich das Meiste auslesen. Allerdings zeigen mir die Tools nur während der Kopierprozesse an, welche Blöcke fehlerhaft sind, aber nicht, welche Dateien betroffen sind.

Mit debugfs (=> googeln) kann man sich bei Ext2-4 den zu einem Block zugehörigen Dateinamen rausfischen lassen, aber die Liste der defekten Blöcke muss man dann schon vorher mitschneiden.

@gaym0r Freilich sind SSDs intern auch blockweise organisiert. Ich würde allerdings "Reallocated Sectors" auch nicht trauen.

 

[Inzersdorfer]

Das Filesstem hat logische Sektoren, die SSD als kleinste Verwaltungseinheit Pages (4KiB).
Im günstigsten Fall sind Pages und Sektoren gleich groß (4 KiB), also eh wurscht.

 

[Telefonkatze]

Sektoren, Pages, Blöcke, ... ich konnte mir das nie merken und habe nur das wiederholt, was im SMART angegeben wird. Die SSD hat ne Macke, für die das Modell 870EVO bekannt ist. Je mehr ich darauf zugreife, desto mehr Fehler entstehen.

Da ich irgendwo gelesen habe, dass die Fehler fälschlicherweise vom Controller erzeugt werden, möchte ich so wenig wie möglich auf die SSD zugreifen.
Deswegen möchte ich es möglichst vermeiden die kompletten Partitionen mit sowas wie dd oder ddrescue auszulesen. debugfs klingt schon mal ganz gut, werde ich mir ansehen. Schöner wäre natürlich ein Programm, was einem den manuellen Vergleich abnehmen würde.

Hier ist noch ein Screenshot der SMART-Werte.

 

[coasterblog]

möchte ich so wenig wie möglich auf die SSD zugreifen.
Deswegen möchte ich es möglichst vermeiden die kompletten Partitionen mit sowas wie dd oder ddrescue auszulesen

Eine 1:1 Kopie ist das sensibelste was du machen kannst. Ein einmaliger Zugriff und dann arbeitet man mit der Kopie.

Mit Software auf dem Laufwerk wild arbeiten ist nicht so gut; zur Not werden noch Trim Befehler bei SSD ausgelöst oder irgendwas greift schreibend auf die Platte zu.

Sind es sehr wichtige Daten dann sofort alles stoppen und ab zum Datenretter. Mit Umweg über den Geldautomaten, denn diese Anbieter sind sehr teuer.

 

[Telefonkatze]

Von den wichtigen Daten hatte ich Backups, aber es wäre sehr aufwendig gewesen, alles wieder herzustellen.
Wild gearbeitet habe ich nicht, sondern nur einmalig ausgelesen. Die Partitionen habe ich nacheinander nur mit Leserechten eingebunden, sodass kein Byte geschrieben wurde. TRIM läuft hier nur manuell.

Ich habe es letztlich mit rsync gemacht und mir die Ausgabe in zwei Dateien umleiten lassen. So konnte ich sehen, welche Dateien betroffen waren. Da es insgesamt nur 11 Stück waren, war der Wiederherstellungsaufwand minimal.
Hätte ich es mit dd/ddrescue gemacht, hätte ich nicht gesehen, welche Dateien betroffen gewesen wären, denn wenn ich anschließend mit den Images gearbeitet hätte, hätte es nicht unbedingt an den gleichen Stellen Lesefehler gegeben.

Die Partitionen waren nur zu 10 - 20 % belegt und die Fehlerwerte der SSD im SMART sind beim Auslesen stark gestiegen. dd hätte auf die gesamten Bereiche zugegriffen, dabei deutlich mehr Zugriffe verursacht und womöglich Reserven ausgeschöpft und zu einem Totalausfall des Laufwerks geführt. Bei einer Festplatte ist mir das schon mal passiert.

 

[Evil E-Lex]

Gibt es ein Tool, welches beim Auslesen die kopierten Dateien markiert, sodass ich diese gezielt prüfen oder aus einem etwaigen Backup nehmen kann?

Ja, gibt es: ddrutility Du musst allerdings zuvor ein Image des Laufwerks mit GNU ddrescue (nicht dd_rescue!) gemacht haben, da das Mapfile benötigt wird. Das Tool wird zwar nicht mehr weiterentwickelt, ein Test kann aber nicht schaden.

 

[Telefonkatze]

Danke. Die Erstellung eines Images mit ddrescue läuft gerade.
Für ntfs kann man nur die belegten Bereiche durchsuchen lassen. Für ext4 habe ich keine solche Funktion gefunden. Gibt es dafür einen technischen Grund oder hat das nur noch niemand umgesetzt?

 

[Evil E-Lex]

Gute Frage. Technische Hürden gibt es da nicht. Es scheint nur niemand benötigt zu haben. Bei ext-Dateisystemen kann man die Prüfung auch manuell durchführen: Identify damaged files
Will man sich den Aufwand sparen, kann man kommerzielle Tools wie DMDE, R-Studio oder UFS Explorer nutzen.

 

[JumpingCat]

Gibt es ein Tool, welches beim Auslesen die kopierten Dateien markiert, sodass ich diese gezielt prüfen oder aus einem etwaigen Backup nehmen kann?

Bein auslesen der Dateien tritt auch bein Image ein CRC Fehler auf. Der wird zusätzlich im syslog /journalctl mit geloggt.

Triggern kannst du das ganz einfach mit z.B. find auf nur Dateien und dann md5sum (oder cat, Hauptsache die Datei komplett lesen) gegen jeden Treffer. Die Ausgabe kannst du direkt gegen /dev/null leiten, weil die read Errors kommen auf stderr.

 

[Telefonkatze]

Ich habe nun endlich die Zeit gefunden, ddrutility (ddru_findbad) auszuprobieren. Das funktioniert ausgezeichnet und da auf der getesteten Partition nur 3 Dateien von bad sectors betroffen sind, konnte ich die leicht manuell als fehlerhaft markieren und demnächst als aus einem Backup fischen.

Bei ext-Dateisystemen kann man die Prüfung auch manuell durchführen: Identify damaged files

Das sieht ziemlich aufwendig aus, weil man für jede Datei mehrere Schritte durchführen muss. Das könnte man bestimmt auch mit einem Skript deutlich vereinfachen, aber das ist nix für mich, denn dafür habe ich zu wenig Talent und deswegen auch zu wenig Erfahrung.

Triggern kannst du das ganz einfach mit...

:-) Ich denke, ich weiß, wie das ungefähr ginge, aber auch das bekomme ich selbst nicht hin. Ich würde damit gerne rumexperimentieren, aber dazu fehlt mir die Zeit.

Vielen Dank für die Tipps. Das hat mich schon viel weiter gebracht.

 

[JumpingCat]

find /mnt/tmp -type f  -print0 |  xargs -I{} -0 md5sum {}  2>&1  | grep ^md5sum | sed 's/\:\ Input\/output\ error//g' | sed 's/md5sum: //g' > /root/broken.txt

Als Ansatz falls du doch noch Zeit findest :-)

 

[Telefonkatze]

Ja, super! :-)
Meine Lösung hatte ich mir dann doch einfacher vorgestellt und ich müsste, selbst wenn ich wüsste, welche Kommandos ich in jedem Pipeschritt verwenden müsste, sicher mehrmals stundenlang nach einer Lösung suchen, wenn ich sie denn überhaupt selbst gefunden hätte.

Da du auch etwas von "cat" und "Hauptsache ganz gelesen" geschrieben hast, dachte ich zuerst an so etwas wie:

ls -a /mnt/tmp | cat 2>&1 ...

Und dann kam mir die Idee, dass auch mit cp und rsync alles komplett gelesen würde, also:

rsync -bla /mnt/tmp/ /dev/null 2>&1 |...

So aus der Hüfte müsste das doch auch die gewünschten Fehlermeldungen provozieren und könnte evtl. sogar weniger cpu-Last erzeugen, weil kein Checksumme berechnet werden muss.


BTW: In wesentlichen Teilen habe ich es sogar schon so wie im letzten Beispiel gemacht. Zur Datenrettung habe ich mit rsync partitionsweise alles von der alten SSD auf eine andere SSD kopiert und stdout und stderr in eine Datei umgeleitet. In einem 2. Schritt habe ich dann nach "errors" gefiltert und hatte das, was ich brauchte:

rsync -bla /mnt/alt //mnt/neu &>rsynclog.txt
cat rsynclog.txt | grepp errors > errors.txt