web-dev-qa-db-fra.com

Récupération de superblocs ext4

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

Le lecteur a une seule partition et utilise une table de partition 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 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 (Remarque, -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 essayer "e2fsck -b [block]" 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, c'est là que se trouvaient les superblocs lorsque le système de fichiers a été créé, ce qui ne signifie pas nécessairement qu'ils sont toujours intacts.

J'ai également exécuté un testdiskrecherche 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

L'exécution d'e2fsck avec ces valeurs donne:

e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

J'ai essayé 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 e2fsck Message d'erreur.

Lors de ma dernière tentative, j'ai essayé différents décalages du système de fichiers. Pour chaque décalage i, où i est l'un des 31744, 32768, 1048064, 1049088:

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

... et en cours d'exécution 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 à des outils de récupération de fichiers de bas niveau (foremost/photorec)?

filesystemsdata-recoveryext4superblock
51
tlvince

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

Marquage comme répondu par souci de propreté.

17
tlvince

Cela peut être déjà dépassé, mais quelques suggestions:

Si vous êtes absolument sûr que la taille de bloc d'origine est 4096, comme le prétend testdisk, vous pouvez réécrire les superblocs sur le disque à l'aide de 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 de superblocs que cette commande donne, et ensuite les mêmes mais en utilisant la dernière taille de bloc 1024.

10
Jari Laamanen

Comme mentionné, probablement obsolète, mais fdisk (AFAIK) ne prend pas en charge les disques GPT. Vous devez utiliser parted ou un autre outil.

Je viens de tester une machine virtuelle exécutant Debian Squeeze (noyau 2.6.32-5-486) ​​et j'ai formaté un disque virtuel en GPT à l'aide de Parted ...

# 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

Il s'agit de la version 2.17.2 de fdisk (util-linux-ng).

mkfs et fsck devraient récupérer la "vraie" partition OK, mais pour vérifier que la table de partition GPT n'est pas corrompue, vous devriez avoir utilisé GNU parted.

1
StarNamer

J'ai eu le même problème de montage après le redémarrage de mon ordinateur. Dans mon cas, il suffisait d'exécuter parted et d'émettre une commande comme:

set 1 lvm on

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

0
user30192