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)?
fuente
sudo fdisk -l /dev/sdbmuestra?testdisk, como se mencionó anteriormente, probé diferentes compensaciones usandolosetup(i * 512dondeies uno de 62, 64, 2047 o 2049).Respuestas:
Desafortunadamente, no pude recuperar el sistema de archivos y tuve que recurrir a técnicas de recuperación de datos de nivel inferior (muy bien resumidas en la entrada wiki de Recuperación de Datos de Ubuntu ), de las cuales el Kit de Detección resultó más útil.
Marcado como respondido por el bien de la limpieza.
fuente
Esto puede estar desactualizado ya, pero algunas sugerencias:
Si está absolutamente seguro de que el tamaño de bloque original es 4096, como afirma
testdisk, puede reescribir los superbloques en el disco utilizandomke2fs -S. Del hombre:Si no está seguro sobre el tamaño de bloque correcto, use
mke2fs -n -b 2048 /dev/sdb1e intente todas las copias de seguridad de superbloque que le da este comando, y luego lo mismo pero usando el último tamaño de bloque 1024.fuente
Como se mencionó, probablemente esté desactualizado, pero fdisk (AFAIK) no admite discos GPT. Necesita usar una herramienta separada o alguna otra.
Acabo de probar una máquina virtual que ejecuta Debian squeeze (kernel 2.6.32-5-486) y formateé un disco virtual como GPT usando parted ...
Esta es la versión 2.17.2 de fdisk (util-linux-ng).
mkfs y fsck deberían recoger la partición 'real' OK, pero para verificar que la tabla de particiones GPT no esté dañada, debería haber usado GNU parted.
fuente
Tengo el mismo problema de montaje después de reiniciar mi computadora. En mi caso, fue suficiente para ejecutar parted y emitir un comando como:
y luego salga e intente volver a montar. Quizás también te ayude.
fuente