Retten Sie Dateien aus einem Ext3-Dateisystem mit physischen Fehlern

Retten Sie Dateien aus einem Ext3-Dateisystem mit physischen Fehlern

Ich habe eine Festplatte von einem abgestürzten Linux-Laptop mit Dateien darauf, die der unzufriedene Besitzer, wenn möglich, gerne zurückhaben würde (bitte keine Backup-Lösungen). Ich hatte noch nie etwas damit zu tun. Die Festplatte wird sowohl von OS X als auch von Ubuntu 11.10 erkannt:

root@ubuntu1110:~# fdisk -l /dev/sdc

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x80d549b4

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *          63   953602334   476801136   83  Linux
/dev/sdc2       953602335   976768064    11582865    5  Extended
/dev/sdc5       953602398   976768064    11582833+  82  Linux swap / Solaris

Dies scheint mit einer Standardinstallation einer Linux-Distribution mit einer Swap-Partition übereinzustimmen.

Leider erscheinen einige ziemlich unangenehme Meldungen in dmesg, nachdem Ubuntu sagt, dass es die sdc1-Partition nicht mounten kann:

[  181.228092] sd 6:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[  181.232176] sd 6:0:0:0: [sdc] Write Protect is off
[  181.232181] sd 6:0:0:0: [sdc] Mode Sense: 21 00 00 00
[  181.236359] sd 6:0:0:0: [sdc] No Caching mode page present
[  181.236364] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  181.246696] sd 6:0:0:0: [sdc] No Caching mode page present
[  181.246707] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  182.835915]  sdc: sdc1 sdc2 < sdc5 >
[  182.854199] sd 6:0:0:0: [sdc] No Caching mode page present
[  182.854204] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  182.854208] sd 6:0:0:0: [sdc] Attached SCSI disk
[  218.250174] sd 6:0:0:0: [sdc] Unhandled sense code
[  218.250179] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  218.250182] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  218.250187] Info fld=0x0
[  218.250188] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  218.250193] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 01 08 00 00 08 00
[  218.250200] end_request: I/O error, dev sdc, sector 264
[  218.250206] Buffer I/O error on device sdc, logical block 33
[  255.398994] sd 6:0:0:0: [sdc] Unhandled sense code
[  255.399029] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  255.399032] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  255.399037] Info fld=0x0
[  255.399038] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  255.399053] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 01 08 00 00 08 00
[  255.399061] end_request: I/O error, dev sdc, sector 264
[  255.399066] Buffer I/O error on device sdc, logical block 33
[  281.340599] sd 6:0:0:0: [sdc] Unhandled sense code
[  281.340609] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  281.340618] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  281.340653] Info fld=0x0
[  281.340655] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  281.340659] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 00 67 00 00 08 00
[  281.340667] end_request: I/O error, dev sdc, sector 103
[  281.340739] EXT3-fs (sdc1): error: can't read group descriptor 4

Meine derzeitige Theorie ist, dass die Festplatte keine freien Blöcke mehr hat, sodass jetzt ein wirklich fehlerhafter Block eingeführt wurde und dieser sich in dem Bereich befindet, der beim Mounten der Partition verwendet wurde. Dies wird durch dd bestätigt:

root@ubuntu1110:~# dd if=/dev/sdc1 of=/dev/null bs=10240 conv=noerror
dd: reading `/dev/sdc1': Input/output error
2+0 records in
2+0 records out
20480 bytes (20 kB) copied, 44.7084 s, 0.5 kB/s
dd: reading `/dev/sdc1': Input/output error
9+1 records in
9+1 records out
96256 bytes (96 kB) copied, 162.933 s, 0.6 kB/s
dd: reading `/dev/sdc1': Input/output error
9+1 records in
9+1 records out
96256 bytes (96 kB) copied, 180.083 s, 0.5 kB/s

Schlechte Blöcke am Anfang und sehr langsame Übertragungsrate auch später im Prozess (nicht dargestellt)

Mein Problem ist nun, wie ich von hier aus vorgehen soll. Ich brauche etwas, das ein defektes ext2/ext3-Dateisystem lesen kann, damit wir die noch vorhandenen Dateien von der Festplatte kopieren können. Außerdem habe ich in den letzten 15 Jahren nicht viel Erfahrung mit der Linux-Systemadministration, daher kenne ich die richtigen Suchbegriffe nicht.

Ich könnte wahrscheinlich über Nacht ein Disk-Image kopieren, aber dann geht die Information „Dieser Block ist fehlerhaft“ verloren.

Welche Art von Programm wäre in dieser Situation nützlich?

Antwort1

Erste Regel der Datenträgerwiederherstellung:Beenden Sie die Verwendung der Festplatte. Wenn Hardwareprobleme auftreten (z. B. ein Head-Crash), besteht bei jeder Verwendung das Risiko weiterer Schäden. Wenn das Dateisystem beschädigt ist, besteht bei jeder Verwendung mountdas fsckPotenzial, die Situation zu verschlimmern. (Auch im ro-Modus! Beachten Sie, dassmount -t ext3 -o ro WilleVersuchen Sie, das Journal wiederzugeben und auf die Festplatte zu schreiben!)

Verwendendd_rescueoderAbonnierenKopieren Sie so viel wie möglich vom Disk-Image auf ein anderes System, legen Sie die Disk weg und erstellen Sie Kopien des Images. Führen Sie alle Wiederherstellungsversuche von einer der Kopien aus durch.

Jetzt habe ich einige Tipps für die Wiederherstellung von Ext-Daten gegebenHier. Zusamenfassend,

  • Ihr Partitionslayout scheint noch gültig zu sein. Wenn nicht, könnten Sie verwendenTestDiskodergpartum zu versuchen, die Partitionstabelle wiederherzustellen.
  • e2fsckkann das Dateisystem möglicherweise wieder in einen mountbaren Zustand bringen. Es platziert hängende Inodes /lost+foundund meldet Fehler.
  • ext4magicversucht, Daten aus aufgezeichneten Metadaten wiederherzustellen. Ob Dateien aus dem Journal wiederhergestellt werden können, hängt vom Glück und Zufall ab, aber es ist möglich, dass sich dort etwas befindet.
  • Das Detektiv-Kitkann die meisten Dateisystemstrukturen analysieren und ausgeben. Wenn Sie sich einigermaßen mit dem internen Layout des Dateisystems auskennen und einen Hex-Editor zur Hand haben (um Dinge wie „Superblock ist beschädigt und Backup-Superblock ist veraltet, aber ich kann genug Daten heraussuchen, um ihn selbst wiederherzustellen“), ist dies meiner Meinung nach das absolut nützlichste Tool, um die meisten Daten wiederherzustellen.
  • FotoRecversucht, Bytefolgen zu finden, die wie Dateien aussehen. Es errät lediglich den Dateianfang/das Dateiende, weiß nichts über die Dateisystemstruktur wie Verzeichnisse und Dateinamen und findet keine fragmentierten Dateien.

Antwort2

Angenommen, Sie haben alle üblichen Vor- und Nachteile professioneller Datenrettungsdienste durchgesehen und die Kosten der verlorenen Daten gegen das Risiko abgewogen, dies selbst zu tun ... Der Benutzer hat entschieden, dass die Daten nicht Tausende von Dollar wert sind, aber esIstes ist viele Stunden Ihrer Zeit wert …

Ich würde Folgendes tun:

Wenn ich beim DD konstant 0,5 kB/s bekomme, lohnt sich ein solcher Versuch wahrscheinlich nicht.

DukönnteFühren Sie Testdisk für die Festplatte aus. EskönnteArbeit. Wenn das Kosten-Risiko-Verhältnis keine anderen Optionen zulässt, dann ... liegt die Entscheidung bei Ihnen. Es könnte funktionieren.

Im Ernst, diese Probleme sind ein politisches Minenfeld. Der Benutzer ist entweder zu verlegen, um seine Kollegen zu bitten, ihm die Dateien erneut zu schicken, oder er möchte seinem Management nicht gegenübertreten und zugeben, dass er keine regelmäßigen Backups gemacht hat und nun Tausende für die Datenwiederherstellung ausgeben muss. Er hofft, dass Sie das Problem vielleicht für ihn lösen und alle Probleme lösen können ... und wenn sich das Laufwerk dabei selbst zerstört, wird er Sie unter den Bus werfen, um seine eigene Haut zu retten.

verwandte Informationen