Ostatnio moja zewnętrzna obudowa dysku twardego uległa awarii (sam dysk twardy włącza się w innej obudowie). Jednak w rezultacie wydaje się, że jego system plików EXT4 jest uszkodzony.
Dysk ma jedną partycję i korzysta z tablicy partycji GPT (z etykietą ears).
fdisk -l /dev/sdb przedstawia:
Device Boot Start End Blocks Id System
/dev/sdb1 1 1953525167 976762583+ ee GPT
testdisk pokazuje, że partycja jest nienaruszona:
1 P MS Data 2049 1953524952 1953522904 [ears]
... ale nie można zamontować partycji:
$ 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 zgłasza nieprawidłowy superblok:
$ 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
i e2fsckzgłasza podobny błąd:
$ 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 również:
$ 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(uwaga -n) zwraca superbloki:
$ 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
... ale próba „e2fsck -b [blok]” dla każdego bloku kończy się niepowodzeniem:
$ sudo e2fsck -b 71663616 /dev/sdb1
e2fsck 1.42 (29-Nov-2011)
e2fsck: Invalid argument while trying to open /dev/sdb1
Jednak, jak rozumiem, to właśnie tam były superbloki podczas tworzenia systemu plików, co niekoniecznie oznacza, że nadal są nienaruszone.
Przeprowadziłem również testdisk głębokie wyszukiwanie, czy ktoś może rozszyfrować dziennik. Wymienia wiele wpisów, takich jak:
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
Uruchomienie e2fsck z tymi wartościami daje:
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1
Próbowałem tego ze wszystkimi superblokami w testdisk.log
for i in $(grep e2fsck testdisk.log | uniq | cut -d " " -f 4); do
sudo e2fsck -b $i -B 4096 /dev/sdb1
done
... wszystkie z tym samym e2fsckkomunikatem o błędzie.
Podczas mojej ostatniej próby spróbowałem różnych przesunięć systemu plików. Dla każdego przesunięcia i, gdzie ijest jeden z 31744, 32768, 1048064, 1049088:
$ sudo losetup -v -o $i /dev/loop0 /dev/sdb
... i biegnąc testdisk /dev/loop0, nie znalazłem nic ciekawego.
Byłem dość wyczerpujący, ale czy jest jakiś sposób na odzyskanie systemu plików bez uciekania się do narzędzi do odzyskiwania plików niskiego poziomu ( foremost/ photorec)?
testdisk, jak wspomniano powyżej, próbowałem różnych przesunięć przy użyciu losetup( i * 512gdzie ijest jeden z 62, 64, 2047 lub 2049).
sudo fdisk -l /dev/sdbpokazuje