Recientemente, mi gabinete del disco duro externo falló (el disco duro se enciende en otro gabinete). Sin embargo, como resultado, parece que su sistema de archivos EXT4 está dañado.
La unidad tiene una única partición y utiliza una tabla de partición GPT (con la etiqueta ears).
fdisk -l /dev/sdb muestra:
Device Boot Start End Blocks Id System
/dev/sdb1 1 1953525167 976762583+ ee GPT
testdisk muestra que la partición está intacta:
1 P MS Data 2049 1953524952 1953522904 [ears]
... pero la partición no se puede montar:
$ 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 informa un superbloque no válido:
$ 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
e e2fsckinforma un error similar:
$ 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 además:
$ 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(nota -n) devuelve los superbloques:
$ 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
... pero falla "e2fsck -b [bloque]" para cada bloque:
$ sudo e2fsck -b 71663616 /dev/sdb1
e2fsck 1.42 (29-Nov-2011)
e2fsck: Invalid argument while trying to open /dev/sdb1
Sin embargo, según tengo entendido, aquí es donde estaban los superbloques cuando se creó el sistema de archivos, lo que no significa necesariamente que todavía estén intactos.
También he realizado una testdisk búsqueda profunda si alguien puede descifrar el registro. Menciona muchas entradas como:
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
Ejecutar e2fsck con esos valores da:
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1
Lo intenté con todos los superbloques en el testdisk.log
for i in $(grep e2fsck testdisk.log | uniq | cut -d " " -f 4); do
sudo e2fsck -b $i -B 4096 /dev/sdb1
done
... todo con el mismo e2fsckmensaje de error.
En mi último intento, probé diferentes compensaciones del sistema de archivos. Para cada desplazamiento i, donde ies uno de 31744, 32768, 1048064, 1049088:
$ sudo losetup -v -o $i /dev/loop0 /dev/sdb
... y corriendo testdisk /dev/loop0, no encontré nada interesante.
He sido bastante exhaustivo, pero ¿hay alguna forma de recuperar el sistema de archivos sin recurrir a herramientas de recuperación de archivos de bajo nivel ( foremost/ photorec)?
testdisk, como se mencionó anteriormente, probé diferentes compensaciones usando losetup( i * 512donde ies uno de 62, 64, 2047 o 2049).
sudo fdisk -l /dev/sdbmuestra?