RAW-Lesen von USB-Massenspeicher oder SCSI

RAW-Lesen von USB-Massenspeicher oder SCSI

Die USB-Festplatte meiner Frau hat ein kleines Problem, da sich ein Ordner nicht öffnen lässt (NTFS-Dateisystem). Ich konnte das Laufwerk mit Linux abbilden, allerdings nur für einen Sektor (Sektoren sind 4096 Bytes groß). Das Lesen dieses Sektors schlägt fehl:

sudo dd if=/dev/sdb von=Block skip=21647245 bs=4096 count=1
dd: Fehler beim Lesen von „/dev/sdb“: Eingabe-/Ausgabefehler
0+0 Datensätze in
0+0 Datensätze ausgegeben
0 Bytes (0 B) kopiert, 22,9317 s, 0,0 kB/s

Das Ersetzen dieses Sektors durch Nullbytes führt zum gleichen Symptom wie unter Windows, der Sektor scheint also mit dem problematischen Verzeichnis in Zusammenhang zu stehen.

Beim Zugriff auf diesen Sektor lautet die dmesg-Ausgabe:

[20381.842495] sd 7:0:0:0: [sdb] Unbehandelter Sense-Code
[20381.842506] sd 7:0:0:0: [sdb]  
[20381.842510] Ergebnis: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[20381.842514] sd 7:0:0:0: [sdb]  
[20381.842517] Sense Key: Hardwarefehler [aktuell]
[20381.842531] sd 7:0:0:0: [sdb]  
[20381.842535] Zus. Sinn: Keine zusätzlichen Sinninformationen
[20381.842539] sd 7:0:0:0: [sdb] CDB:
[20381.842542] Lesen(10): 28 00 01 4a 4f 8d 00 00 01 00
[20381.842557] end_request: E/A-Fehler, dev sdb, Sektor 173177960
[20381.842572] Puffer-E/A-Fehler auf Gerät sdb, logischer Block 21647245

Gibt es eine Möglichkeit, diesen Sektor im Rohzustand zu lesen, ohne CRC-Prüfung oder ähnliches, um tatsächlich zu versuchen, einige der beschädigten Daten wiederherzustellen?

Ich habe das Gehäuse geöffnet: Die Festplatte ist nativ USB, keine USB-zu-SATA-Konvertierung.

Bearbeiten: Habe ddrescue ausprobiert, konnte den fehlerhaften Sektor aber auch nicht wiederherstellen. Habe 2Gigs um den fehlerhaften Sektor herum gelesen und die Köpfe nach dem Suchen stabilisiert:

sudo ddrescue -s 2Gi -o 0 -i 87593373696 /dev/sdb blkk
GNU ddrescue 1.19
Drücken Sie Strg-C, um zu unterbrechen
gerettet: 2147 MB, Fehlergröße: 4096 B, aktuelle Rate: 0 B/s
   ipos: 88667 MB, Fehler: 1, Durchschnittsrate: 8488 kB/s
   opos: 1073 MB, Laufzeit: 4,21 Min., erfolgreich gelesen vor: 1,06 Min.
Fertig

Das Rückwärtslesen (Flag -R) schlug ebenfalls fehl.

Bearbeitung 2:Mein geplanter zweiter Schritt war, mithilfe von Forensik zu versuchen, die fehlenden Dateien zu finden. Ich begann zunächst damit, die MFT manuell zu untersuchen, aber das wird schnell sehr, sehr mühsam. Daher hatte ich die folgenden Tools auf meiner Liste:

  1. das Sleuthkit
  2. ntfs-3g
  3. Skalpell
  4. schnorren-ntfs

Das Sleuthkit konnte nichts Sinnvolles tun und brach sehr früh ab, da es Fehler in den Metadatenstrukturen bemängelte.

Mit Ntfs-3g (jetzt Tuxera) ist es möglich, das Image mit Debug-Ausgabe zu mounten:

sudo mount -o loop,ro,offset=258048,debug image2 ./mnt -t ntfs-3g

Der Versuch, das fehlerhafte Verzeichnis aufzurufen, würde einen Fehler auslösen:

Der Indexpuffer (VCN 0x0) des Verzeichnis-Inodes 101874 hat eine Größe (24), die von der im Verzeichnis angegebenen Größe (4096) abweicht.

Die Suche nach diesem Fehler in DuckduckGo führte mich zum folgenden Beitrag: http://www.tuxera.com/forum/viewtopic.php?f=3&t=27054 Es stellt sich heraus, dass die Leute bei Tuxera / ntfs-3g tatsächlich die Verwendung von Microsofts CHKDSK zur Behebung von NTFS-Fehlern empfehlen

Das Ausführen von chkdsk auf der Festplatte war mein dritter und letzter geplanter Schritt. Es sollte jedoch viel früher versucht werden, da bekannt ist, dasses KANN auf einem Disk-Image ausgeführt werden, zum Beispiel mit OSFMount (http://www.osforensics.com/tools/mount-disk-images.html).

Die meisten fehlenden Dateien und Verzeichnisse (wenn nicht alle) wurden durch chkdsk /f auf dem gemounteten Disk-Image wiederhergestellt. Mehr als hundert Fehler (die meisten davon waren verwaiste Dateien) wurden behoben.

Bearbeitung 3:Ich akzeptiere die Antwort von psusi. Obwohl es nicht unmöglich ist, ist der Versuch, die fehlerhaften Sektoren zu lesen, sicherlich der unsicherste und schwierigste Weg, um Daten von einer leicht beschädigten Festplatte wiederherzustellen.

Antwort1

Nein, das ist nicht möglich. Es gibt einen SCSI-Befehl, mit dem Sie das tun können, aber Sie würden trotzdem nur Müll erhalten, und es wird auf Laufwerken auf Verbraucherebene nicht unterstützt, insbesondere nicht auf USB. Was auch immer in diesem Sektor war, ist weg.

verwandte Informationen