Récupération des superblocs ext4

Récemment, mon boîtier de disque dur externe a échoué (le disque dur lui-même s'active dans un autre boîtier). Cependant, il semble que son système de files EXT4 soit corrompu.

Le lecteur a une seule partition et utilise une table de partition GPT (avec les ears l'label).

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 signale 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 e2fsck signale 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) Ssortingde=0 blocks, Ssortingpe 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 en essayant "e2fsck -b [bloc]" pour chaque bloc échoue:

 $ sudo e2fsck -b 71663616 /dev/sdb1 e2fsck 1.42 (29-Nov-2011) e2fsck: Invalid argument while trying to open /dev/sdb1 

Cependant, si je comprends bien, ce sont là les superblocs lorsque le système de files a été créé, ce qui ne signifie pas nécessairement qu'ils sont toujours intacts.


J'ai aussi fait une search approfondie de testdisk si quelqu'un peut décrypter le journal. Il mentionne de nombreuses inputs 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 

Exécuter 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 dans le 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 message d'erreur e2fsck .


Dans ma dernière tentative, j'ai essayé différents décalages de système de files. Pour chaque offset i , où i est un de 31744, 32768, 1048064, 1049088:

 $ sudo losetup -v -o $i /dev/loop0 /dev/sdb 

… et exécutant testdisk /dev/loop0 , je n'ai rien trouvé d'intéressant.


J'ai été assez exhaustif, mais y a-t-il un moyen de récupérer le système de files sans recourir à des outils de récupération de files de bas niveau ( foremost / photorec )?

Malheureusement, je n'ai pas pu récupérer le système de files et j'ai dû recourir à des techniques de récupération de données de niveau inférieur (bien résumées dans l'input wiki Data Recovery d' Ubuntu), dont Sleuth Kit s'est avéré le plus utile.

Marquage comme réponse pour l'amour de la propreté.

Cela peut être déjà obsolète, mais quelques suggestions:

Si vous êtes absolument sûr que la taille de testdisk origine est 4096, comme le prétend testdisk , vous pouvez réécrire les superblocs sur le disque en utilisant mke2fs -S . De l'homme:

  -S Write superblock and group descriptors only. This is useful if all of the superblock and backup superblocks are corrupted, and a last- ditch recovery method is desired. It causes mke2fs to reinitialize the superblock and group descriptors, while not touching the inode table and the block and inode bitmaps. The e2fsck program should be run immediately after this option is used, and there is no guarantee that any data will be salvageable. It is critical to specify the correct filesystem blocksize when using this option, or there is no chance of recovery. 

Si vous n'êtes pas sûr de la bonne taille de bloc, utilisez mke2fs -n -b 2048 /dev/sdb1 et essayez toutes les sauvegardes superblocs que cette command donne, et ensuite la même chose mais en utilisant la dernière taille 1024.

Comme mentionné, probablement périmé, mais fdisk (AFAIK) ne supporte pas les disques GPT. Vous devez utiliser un outil séparé ou un autre outil.

Je viens de tester une machine virtuelle exécutant Debian squeeze (kernel 2.6.32-5-486) ​​et formaté un disque virtuel comme GPT en utilisant …

 # parted /dev/sde (parted) mklabel GPT (parted) mkpart part1 0 10G (parted) quit # fdisk -l /dev/sde . WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted. . Disk /dev/sde: 85.9 GB, 85899345920 bytes 255 heads, 63 sectors/track, 10443 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 . Device Boot Start End Blocks Id System /dev/sde1 1 10444 83886079+ ee GPT 

C'est la version 2.17.2 de fdisk (util-linux-ng).

mkfs et fsck devraient ramasser la partition «réelle», mais pour vérifier que la table de partition GPT n'est pas corrompue, vous devriez avoir utilisé GNU parted.

J'ai eu le même problème de assembly après le redémarrage de mon ordinateur. Dans mon cas, il suffisait de courir part et d'émettre une command comme:

 set 1 lvm on 

et puis quittez et essayez de remonter. Peut-être que cela vous aidera aussi.