Vor kurzem ist mein externes Festplattengehäuse ausgefallen (die Festplatte selbst wird in einem anderen Gehäuse hochgefahren). Infolgedessen scheint das EXT4-Dateisystem jedoch beschädigt zu sein.
Das Laufwerk verfügt über eine einzelne Partition und verwendet eine GPT-Partitionstabelle (mit der Bezeichnung ears).
fdisk -l /dev/sdb zeigt an:
Device Boot Start End Blocks Id System
/dev/sdb1 1 1953525167 976762583+ ee GPT
testdisk Zeigt an, dass die Partition intakt ist:
1 P MS Data 2049 1953524952 1953522904 [ears]
... aber die Partition kann nicht gemountet werden:
$ sudo mount /dev/sdb1 a
mount: you must specify the filesystem type
$ sudo mount -t ext4 /dev/sdb1 a
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
fsck meldet einen ungültigen Superblock:
$ sudo fsck.ext4 /dev/sdb1
e2fsck 1.42 (29-Nov-2011)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb1
und e2fsckmeldet einen ähnlichen Fehler:
$ sudo e2fsck /dev/sdb1
Password:
e2fsck 1.42 (29-Nov-2011)
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1
dumpe2fs ebenfalls:
$ sudo dumpe2fs /dev/sdb1
dumpe2fs 1.42 (29-Nov-2011)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1
mke2fs -n(Anmerkung, -n) gibt die Superblöcke zurück:
$ sudo mke2fs -n /dev/sdb1
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
61054976 inodes, 244190363 blocks
12209518 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
7453 block groups
32768 blocks per group, 32768 fragments per group
8192 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, 214990848
... aber der Versuch "e2fsck -b [block]" für jeden Block schlägt fehl:
$ sudo e2fsck -b 71663616 /dev/sdb1
e2fsck 1.42 (29-Nov-2011)
e2fsck: Invalid argument while trying to open /dev/sdb1
Soweit ich weiß, befanden sich hier die Superblöcke, als das Dateisystem erstellt wurde, was nicht unbedingt bedeutet, dass sie noch intakt sind.
Ich habe auch eine gründliche testdisk Suche durchgeführt, wenn jemand das Protokoll entschlüsseln kann. Es erwähnt viele Einträge wie:
recover_EXT2: s_block_group_nr=1/7452, s_mnt_count=6/20,
s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 244190363
recover_EXT2: part_size 1953522904
recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed
Wenn Sie e2fsck mit diesen Werten ausführen, erhalten Sie:
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1
Ich habe das mit allen Superblöcken im versucht testdisk.log
for i in $(grep e2fsck testdisk.log | uniq | cut -d " " -f 4); do
sudo e2fsck -b $i -B 4096 /dev/sdb1
done
... alle mit der gleichen e2fsckFehlermeldung.
Bei meinem letzten Versuch habe ich verschiedene Dateisystem-Offsets ausprobiert. iWo iist für jeden Offset einer von 31744, 32768, 1048064, 1049088:
$ sudo losetup -v -o $i /dev/loop0 /dev/sdb
... und beim Laufen testdisk /dev/loop0fand ich nichts interessantes.
Ich war ziemlich ausführlich, aber gibt es eine Möglichkeit , das Dateisystem wiederherzustellen, ohne auf einfache Tools zur Wiederherstellung von Dateien ( foremost/ photorec) zurückzugreifen?
testdiskich, wie oben erwähnt, verschiedene Offsets ausprobiert losetup( i * 512wobei ieiner von 62, 64, 2047 oder 2049 ist).
sudo fdisk -l /dev/sdbzeigt?