Image einer NTFS-Partition verhält sich anders als sie selbst

[Herr_Krolik]

Liebe Forumsmitglieder!

Nach dem Tod eines alten Notebooks (Motherboard war unwiederbringlich kaputtgegangen) wurde ein neues Laptop gekauft, auf dem jetzt ein Dualboot-System (mit Vista und Ubuntu 8.04) angelegt ist. Die kleine 2,5 Zoll Festplatte von dem alten NB scheint trotz allen Befürchtungen gerettet zu sein und kann (mittels IDE/USB-Adapter) unter Linux gemountet werden. Um die alten Daten von der NTFS-Partition (/dev/sdc1) sauber zu retten, habe ich nun wie folgt gehandelt:

1. Die gemounteten Partitionen der alten Festplatte Sicherheitshalber aushängen

myname@SARTAN:~$ df | grep sdc 
/dev/sdc1              5118088   4607809    510279  91% /media/disk 
/dev/sdc4              2217480   1275920    828916  61% /media/disk-1 
/dev/sdc3              2267924   1769252    498672  79% /media/disk-2 
myname@SARTAN:~$ sudo umount /dev/sdc1 
[sudo] password for myname: 
myname@SARTAN:~$ sudo umount /dev/sdc3 
myname@SARTAN:~$ sudo umount /dev/sdc4

2. Entsprechend dem Artikel http://groups.google.de/group/ch.comp.os.linux/msg/29977f6f8bc994c3

myname@SARTAN:~$ ls -l /dev/sd 
sda   sda1  sda2  sda3  sda4  sda5  sda6  sda7  sda8  sdc   sdc1  sdc2  sdc3  sdc4  
myname@SARTAN:~$ sudo dd if=/dev/sdc1 bs=512 conv=noerror,sync | gzip -1 > /home/myname/Bilder/PRINZESSIN_sdb1.gz 
dd: Lesen von „/dev/sdc1“: Input/output error 
2912+0 Datensätze ein 
2912+0 Datensätze aus 
1490944 Bytes (1,5 MB) kopiert, 5,40569 s, 276 kB/s
...
1555456 Bytes (1,6 MB) kopiert, 84,0148 s, 18,5 kB/s 
dd: Lesen von „/dev/sdc1“: Input/output error 
2912+127 Datensätze ein 
3039+0 Datensätze aus 
1555968 Bytes (1,6 MB) kopiert, 84,0148 s, 18,5 kB/s 
10236049+128 Datensätze ein 
10236177+0 Datensätze aus 
5240922624 Bytes (5,2 GB) kopiert, 1706,97 s, 3,1 MB/s

3. Image wird auf die große Partition der neuen Festplatte (/dev/sda entpackt und gemountet

myname@SARTAN:~$ gzip -cd Bilder/PRINZESSIN_sdb1.gz > /media/Common/PRINZESSIN_sdb1
myname@SARTAN:~$ sudo mount -o loop /media/Common/PRINZESSIN_sdb1 /media/sdb1
[sudo] password for myname: 
myname@SARTAN:~$ mount | grep 512
/dev/sdc1 on /media/disk type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=512)
/dev/loop1 on /media/sdb1 type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=512)

4. Inhalt eines Dateiverzeichnisses im Image ("Eigene Dateien") wird zu Testzwecken gelesen

myname@SARTAN:~$ ls -l /media/sdb1/Dokumente\ und\ Einstellungen/Sergej/ | grep Dateien
drwxrwxrwx 1 root root   45056 2008-06-30 12:56 Eigene Dateien
myname@SARTAN:~$ ls -l /media/sdb1/Dokumente\ und\ Einstellungen/Sergej/Eigene\ Dateien/
ls: lese Verzeichnis /media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/: Input/output error
insgesamt 0

5. Inhalt desselben Dateiverzeichnisses der alten Festplatte lässt sich aber problemlos auf das Terminal ausgeben

myname@SARTAN:~$ ls -l /media/disk/Dokumente\ und\ Einstellungen/Sergej/ | grep Dateien
drwxrwxrwx 1 root root   45056 2008-06-30 12:56 Eigene Dateien
myname@SARTAN:~$ ls -l /media/disk/Dokumente\ und\ Einstellungen/Sergej/Eigene\ Dateien/
insgesamt 2123
-rwxrwxrwx 2 root root  10164 2003-04-20 15:16 AGB_WEB.Cent.txt
-rwxrwxrwx 2 root root  12219 2003-04-20 15:05 AGB_WEB.DE.txt
....
-rwxrwxrwx 2 root root    663 2006-11-30 00:46 ZIPDaten_LinuxPartition.txt

6. Mit Hilfe von strace wird nun versucht die Gründe des ls-Absturzes zu erforschen

myname@SARTAN:~$ strace ls -l /media/sdb1/Dokumente\ und\ Einstellungen/Sergej/Eigene\ Dateien/
execve("/bin/ls", ["ls", "-l", "/media/sdb1/Dokumente und Einste"...], [/* 34 vars */]) = 0
brk(0)                                  = 0x805f000
...
lstat64("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", {st_mode=S_IFDIR|0777, st_size=45056, ...}) = 0
lgetxattr("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", "security.selinux", 0x8068b20, 255) = -1 EOPNOTSUPP (Operation not supported)
getxattr("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP (Operation not supported)
...
open("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3
fstat64(3, {st_mode=S_IFDIR|0777, st_size=45056, ...}) = 0
fcntl64(3, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
getdents64(3, 0x806a860, 512)           = -1 EIO (Input/output error)

Trotz den durchgeführten Schritten bleibt mir unklar, wieso der ls-Befehl abstürzt, wenn er auf das Image zugreift, tut es aber nicht, wenn er auf die Originalpartition (auf die alte Festplatte unmittelbar) zugreift? Kommt es auf die Existenz der geschädigten Blöcke in dieser NTFS-Partition oder auf die schlauen Permission bits des getesteten Dateiverzeichnisses an?

Die alte Festplatte wurde schon auch mal unter MS Vista über die USB-Schnittstelle angehängt und mit der Utility chkdsk getestet, welches ausspuckte: "Das Dateisystem wurde überprüft. Es wurden keine Probleme festgestellt."

Für weitere Kommentare und Ratschläge bin ich im voraus sehr dankbar.

 

[Bâshgob]

Den von dir im Ubuntuforum verlinkten Artikel[1] erneut lesen, richtig verstehen, dd_rescue benutzen und gut.

[1] Den da => http://www.garloff.de/kurt/linux/ddrescue/

 

[Herr_Krolik]

Den von dir im Ubuntuforum verlinkten Artikel[1] erneut lesen, richtig verstehen, dd_rescue benutzen und gut.

Lieber Freund, dd_rescue ist kein Zauberstäbchen! Der Befehl

sudo dd_rescue -A Quelle Ziel

betreibt genau dasselbe wie

sudo dd if=Quelle of=Ziel bs=512 conv=noerror,sync

Es liegt an woanders... Das erzeugte Abbild scheint soweit wie möglich sauber hingekriegt zu sein. Ich mache mit ihm aber etwas falsch, vielleicht mounte ich falsch oder so?

 

[Bâshgob]

Fuck, falsches Programm.

Nicht dd_rescue, sondern ddrescue.

http://www.tuxfutter.de/wiki/Ddrescue
http://www.gnu.org/software/ddrescue/ddrescue.html

Frisch ans Werk, Froind.

 

[Herr_Krolik]

Fuck, falsches Programm.
Nicht dd_rescue, sondern ddrescue.

Also muss das Programm ddrescue als Zauberstäbchen gelten...
Schon allein das Manual für dieses andere Programm liefert recht interessante Information:

You should make a copy of the failing drive with ddrescue, and then try to repair the copy. If your data is really important, use the first copy as a master for a second copy, and try to repair the second copy. If something goes wrong, you have the master intact to try again.
If you are trying to rescue a whole partition, first repair the copy with e2fsck or some other tool appropiate for the type of partition you are trying to rescue, then mount the repaired copy somewhere and try to recover the files in it.

Warum haben die Produzenten von ddrescue diese Worte geschrieben?