Récemment, mon boîtier de disque dur externe est tombé en panne (le disque dur lui-même est mis sous tension dans un autre boîtier). Cependant, il en résulte que son système de fichiers EXT4 est corrompu.
Le lecteur a une seule partition et utilise une table de partitions GPT (avec l’étiquette ears).
fdisk -l /dev/sdb montre:
Device Boot Start End Blocks Id System
/dev/sdb1 1 1953525167 976762583+ ee GPT
testdisk montre que la partition est intacte:
1 P MS Data 2049 1953524952 1953522904 [ears]
... mais la partition ne parvient pas à monter:
$ 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 rapporte un superbloc invalide:
$ 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
et e2fscksignale une erreur similaire:
$ 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 aussi:
$ 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(note, -n) renvoie les superblocs:
$ 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
... mais échouer en essayant "e2fsck -b [block]" pour chaque bloc:
$ sudo e2fsck -b 71663616 /dev/sdb1
e2fsck 1.42 (29-Nov-2011)
e2fsck: Invalid argument while trying to open /dev/sdb1
Cependant, si j'ai bien compris, ce sont les superblocs qui se trouvaient lors de la création du système de fichiers, ce qui ne signifie pas nécessairement qu'ils sont toujours intacts.
J'ai également effectué une testdisk recherche approfondie si quelqu'un peut déchiffrer le journal. Il mentionne de nombreuses entrées comme:
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
Lancer e2fsck avec ces valeurs donne:
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1
J'ai essayé cela avec tous les superblocs de la testdisk.log
for i in $(grep e2fsck testdisk.log | uniq | cut -d " " -f 4); do
sudo e2fsck -b $i -B 4096 /dev/sdb1
done
... tous avec le même e2fsckmessage d'erreur.
Lors de ma dernière tentative, j'ai essayé différents décalages de systèmes de fichiers. Pour chaque décalage i, où iest l'un des 31744, 32768, 1048064, 1049088:
$ sudo losetup -v -o $i /dev/loop0 /dev/sdb
... et en courant testdisk /dev/loop0, je n'ai rien trouvé d'intéressant.
J'ai été assez exhaustif, mais existe-t-il un moyen de récupérer le système de fichiers sans recourir aux outils de récupération de fichiers de bas niveau ( foremost/ photorec)?
testdisk, comme mentionné ci-dessus, j’ai essayé différents types de compensation en utilisant losetup( i * 512où iest l’un des 62, 64, 2047 ou 2049).
sudo fdisk -l /dev/sdbmontre?