ext3 partition da, daten aber weg

[kasperll]

Hallo!

Habe ein NAS (QNAP TS-109) welches mir (vermutlich durch einen Bug in der Firmware) meine Daten "zerschossen" hat. Das NAS lauft unter Linux. Ich habe mittels dd_rescue ein Image der betroffenen Platte auf eine externe gemacht, auf der ich experementieren kann:

Das ist die Platte um die es sich dreht

Disk /dev/sdd: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1   *           1          66      530113+  83  Linux
/dev/sdd2              67         132      530145   82  Linux swap / Solaris
/dev/sdd3             133       60791   487243417+  83  Linux
/dev/sdd4           60792       60800       72292+  83  Linux

sdd1 ist das Betriebssystem der Platte, sdd2 swap, sdd3 sind die Daten und sdd4 ist das home der Linux partition.

sdd1 und sdd4 lassen sich ohne Probleme mounten (hier am Beispiel von sdd1 gezeigt):

root@grml ~ # mount /dev/sdd1 /mnt/floppy 
root@grml ~ # mount
tmpfs on /dev type tmpfs (rw,size=10M,mode=0755)
/dev/pts on /dev/pts type devpts (rw)
rootfs on / type rootfs (rw)
none on /sys type sysfs (rw)
none on /proc type proc (rw)
/dev/hda on /live/image type iso9660 (ro,noatime)
tmpfs on /live/cow type tmpfs (rw,noatime)
aufs on / type aufs (rw,noatime,xino=/live/cow/.aufs.xino,br:/live/cow=rw:/grml.squashfs=ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
/dev/pts on /dev/pts type devpts (rw)
/dev/sdd1 on /mnt/floppy type ext3 (rw)

Moechte ich sdd3 mounten (die "wichtige" Partition) kommt der "alte" Fehler:

 root@grml ~ # mount /dev/sdd3 /mnt/floppy
mount: wrong fs type, bad option, bad superblock on /dev/sdd3,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

in dmesg steht

EXT3-fs: sdd3: couldn't mount because of unsupported optional features (40).

Ich habe versucht, meine Platte mit anderen superblocks zu mounten. Die superblocks hatte ich einmal mit

root@grml ~ # mke2fs -n /dev/sdd3
mke2fs 1.40-WIP (14-Nov-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
60915712 inodes, 121810854 blocks
6090542 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
3718 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
        102400000

und einmal mit Testdisk herausgesucht (Anmerkung: Testdisk fand nur die Superblocks bis 2654208). Mit E2fsk einmal mit Blockgroessenangabe

 root@grml ~ # e2fsck -b 229376 -B 4096 /dev/sdd3
e2fsck 1.40-WIP (14-Nov-2006)
e2fsck: Filesystem has unsupported feature(s) while trying to open /dev/sdd3

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

und einmal ohne Blockgroessenangabe

 root@grml ~ # e2fsck -b 229376 /dev/sdd3
e2fsck 1.40-WIP (14-Nov-2006)
e2fsck: Bad magic number in super-block while trying to open /dev/sdd3

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

zu reparieren versucht, ohne erfolg (natuerlich habe ich es mit allen Superblocks versucht).

Was mich jedoch sehr stutzig macht, ist der umstand das ich die Platte als ext4 mounten kann:

root@grml ~ # mount -t ext4dev /dev/sdd3 /mnt/floppy
root@grml ~ # mount
tmpfs on /dev type tmpfs (rw,size=10M,mode=0755)
/dev/pts on /dev/pts type devpts (rw)
rootfs on / type rootfs (rw)
none on /sys type sysfs (rw)
none on /proc type proc (rw)
/dev/hda on /live/image type iso9660 (ro,noatime)
tmpfs on /live/cow type tmpfs (rw,noatime)
aufs on / type aufs (rw,noatime,xino=/live/cow/.aufs.xino,br:/live/cow=rw:/grml.squashfs=ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
/dev/pts on /dev/pts type devpts (rw)
/dev/sdd3 on /mnt/floppy type ext4dev (rw)

dmesg gibt mir:

EXT4-fs warning: mounting fs with errors, running e2fsck is recommended
EXT4 FS on sdd3, internal journal
EXT4-fs: mounted filesystem with ordered data mode.
EXT4-fs: file extents enabled

Ich kann alle meine Daten sehen (ls) aber beim Kopieren der Daten gibt es I/O Errors. Ein grep -r ueber alle Daten sagt mir, das geschaetzte 80% diesen I/O Error liefern.

Nun, ich glaube nicht dass das NAS auf ext4 setzt um Daten zu speichern, sondern auch auf ext3. Weiters leugne ich (NOCH) die Annahme das 80% meiner Daten fort sind :-). Die Frage an euch: Was kann ich tun?

 

[eijk]

Hallo!

Weiß nicht, ob das noch aktuell ist, aber weil ich mich (aufgrund versehentlichen Löschens) kürzlich intensiv mit dem Filesystem einer QNAP TS-109 Pro II beschäftigen musste (übrigens erfolgreich!), folgendes:

Es wird tatsächlich ein ext3 verwendet, allerdings mit "extent"-Support. Wenn Du die Partition also unter einem Desktop-Linux mounten willst, muss der Kernel "ext3 extents" können.

Extents sind eine neue Form, die zu einer Datei gehörigen Blocks aufzulisten. Dadurch sind größere Partitionen und Dateien möglich.

http://lwn.net/Articles/187321/
http://lwn.net/Articles/186933/

Ein guter kurzer Abriss zu ext2 (Datenstrukturen abgesehen von Journalling identisch):

http://uranus.it.swin.edu.au/~jn/explore2fs/es2fs.htm

Hoffe, das hilft.

eijk

Update:
Ach so, eine Frage noch: Was für ein Bug war das denn? Den würde ich gerne umgehen ;-)

 

[Datenschredder]

Hallo Computer Base Gemeinde,

wie Ihr seht, habe ich tief in der SuFu gegraben, bis ich diesen Fall fand, welcher mein Problem Ansatzweise beschreibt.

Ich habe mein NAS QNAP 219 mit leider noch nur einer Plate, (2TB Samsung HD204UI) zerschossen.
Ich sehe alle Daten bei Anschluss an meinen Windows 7 Rechner (mit Tool Ext2 Volume Manager), kann auch ca. die hälfe der Daten kopieren, bei der anderen hälfte streikt jedoch die Kopierfunktion.

Nun stehe ich etwas mit Angstschweiß auf der Stirn vor der Entscheidung, was tun....

Sicherheitshalber wollte ich mich an das Forum wenden, bevor ich noch mehr kaputt mache.

Das Protokoll sagt folgendes nach dem Quick scan aus:
--------------------------------------------------
Mon Oct 03 23:55:36 2011
Command line: TestDisk

TestDisk 6.12-WIP, Data Recovery Utility, March 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
OS: Windows 7 (7601) SP1
Compiler: GCC 4.5, MinGW 3.11
Compilation date: May 7 2011 12:20:37
ext2fs lib: none, ntfs lib: none, reiserfs lib: none, ewf lib: none
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive0)=320072933376
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive1)=2000398934016
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\C=104752742400
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\D=215212883968
filewin32_getfilesize(\\.\E GetFileSize err Unzulässige Funktion.


filewin32_setfilepointer(\\.\E SetFilePointer err Unzulässige Funktion.


Warning: can't get size for \\.\E:
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\G=542848000
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\I=1998792389632
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\J=509964288
Hard disk list
Disk \\.\PhysicalDrive0 - 320 GB / 298 GiB - CHS 38913 255 63, sector size=512
Disk \\.\PhysicalDrive1 - 2000 GB / 1863 GiB - CHS 243201 255 63, sector size=512
Drive C: - 104 GB / 97 GiB - CHS 12735 255 63, sector size=512
Drive D: - 215 GB / 200 GiB - CHS 26164 255 63, sector size=512
Drive G: - 542 MB / 517 MiB - CHS 65 255 63, sector size=512
Drive I: - 1998 GB / 1861 GiB - CHS 243005 255 63, sector size=512
Drive J: - 509 MB / 486 MiB - CHS 61 255 63, sector size=512

Partition table type (auto): Intel
Disk \\.\PhysicalDrive1 - 2000 GB / 1863 GiB
Partition table type: Intel

Analyse Disk \\.\PhysicalDrive1 - 2000 GB / 1863 GiB - CHS 243201 255 63
Geometry from i386 MBR: head=255 sector=63
check_part_i386 failed for partition type 83
Current partition structure:
1 P Linux 0 0 41 65 254 63 1060250
No ext2, JFS, Reiser, cramfs or XFS marker
2 P Linux 66 0 7 131 254 63 1060284
2 P Linux 66 0 7 131 254 63 1060284
3 P Linux 132 0 5 243137 254 63 3903891386
4 P Linux 243138 0 7 243199 254 63 996024
No partition is bootable

----------------------------------------

C: und D: gehören zum System.

G:, I: und J: zum großen Datensilo.
Die Frage ist, wo ist H:?
Hat dies mit der doppelten 2 P Linux Partition zu tun?

erkennt evtl. jemand auf den ersten Blick was hier faul ist?

Sollte ich die Platte spiegeln bevor ich weiter tätig werde?

Da ich die Daten alle noch sehe, bin ich "noch" optimistisch gestimmt.

Vielen Dank im Voraus für eure Hilfe,
der Datenschredder

 

[eijk]

Ich bin mir nicht sicher, dass das Windows-Tool die Filesystem-Features alle kennt, die bei QNAP verwendet werden (insbesondere Extents). Ich empfehle dringend, ein Linux zu booten (zum Beispiel von Boot-CD oder in einer VM) und zu versuchen, mit dem Linux die Daten rauszukopieren.