Mi partición de inicio en una instalación de Debian Wheezy es un volumen LVM cifrado. Es ext3. Hoy temprano, recibí un mensaje extraño en una ventana de terminal sobre un intento de escribir en un archivo en mi /homeárbol que falló debido a que tenía un sistema de archivos de solo lectura. Reinicié y terminé con un mensaje de error que decía /dev/sda1 is reported as clean. fsck.ext3, que se ejecuta automáticamente e informa que no existe tal dispositivo /dev/mapper/sda1_crypte informa el código de salida 8. Me llevan a un shell de mantenimiento y me dicen que hubo un intento de escribir un registro en /var/log/fsck/checkfs.
Ese registro dice:
[Timestamp]
fsck from util-linux 2.20.1
/dev/mapper/sda1_crypt: Super blocks need_recovery flag is clear, but journal has data.
/dev/mapper/sda1_crypt: Run journal anyway
/dev/mapper/sda1_crypt: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
(i.e., without -a or -p options)
fsck died with exit status 4
yo corrí
$ fsck -vnM /dev/mapper/sda1
Un montón de illegal block #nnnn (mmmmmmmmm) in inode ppppppp IGNOREDmensajes pasaron volando, seguidos de
too many blocks in Inode somenumberhere
Luego ejecutar pases adicionales para resolver bloques reclamados por más de un inodo
Luego sale
Pass 1B: Rescanning for multiply claimed blocks
Después de un rato, tengo una pared de
Illegal block number passed to ext2fs_test_block_bitmap somenumberhere for multiply claimed block map
Estos fueron seguidos por 2 bloques Multiplicar reclamados en el nodo I otro número: [listas de 5 y 8 números de bloque]
Luego obtuve una serie de estrofas como
[ 3828.181915] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 3828.182462] ata1.01 BMDMA stat 0x64
[ 3828.183810] ata1.01 failed command: READ DMA EXT
[ 3828.185889] ata1.01 cmd 25/00:08:08:10:9c/00:00:29:00:00/f0 tag dma 4096 in
[ 3828.185891] res 51/40:00:09:10:9c/40:00:29:00:00/f0 Emask 0x9 (media error)
[ 3828.190071] ata1.01 status: { DRDY ERR }
[ 3828.192153] ata1.01 status: { UNC }
Estos fueron seguidos por
[ 3830.509338] end_request: I/O error, deb SDA, sector 698093577
[ 3830.509841] Buffer I/O error on device dm-3, logical block 87261184
Error reading block 87261184 (Attempt to read block from filesystem resulted in short read) while reading I node and block bitmaps. Ignore error? no
fsck.ext3: Can't read an block bitmap while retrying to read bitmaps for /dev/mappersfa1_crypt
/dev/mapper/sda1_crypt: ******* WARNING: Filesystem still has errors *******
e2fsck: aborted
/dev/mapper/sda1_crypt: ******* WARNING: Filesystem still has errors *******
Y abortó con una advertencia de que el sistema de archivos todavía tenía errores.
Mis preguntas son:
¿Mis datos están tostados? (Mi rigurosa política de respaldo no se ha seguido rigurosamente últimamente; estoy seguro de que estoy siendo castigado por el universo).
¿Qué puedo/debo hacer ahora?
¿Ya hice algo incorrecto?
¿Alguien me abrazará hasta que cese el temblor?
EDITAR
También pregunté en mi lista de correo LUG local. El consejo que recibí fue tomar una imagen del disco con ddrescue y ejecutar fsck en una copia de esa imagen. Eso parece sensato y es poco probable que empeore las cosas. Entonces, ese es el plan de ataque actual, a la espera de sugerencias mejores.
Respuesta1
Parece que el disco duro tiene problemas. ("lectura corta", etc.). Si es así, dmesg | tailprobablemente mostrará algunos errores de E/S.
Otra forma de comprobar esto es ejecutar badblocks -nen la partición problemática. O mejor, en todo el disco. Independientemente de lo que pruebes, es necesario desmontarlo. Esto llevará horas en un disco moderno grande. Si hay algo en las particiones que se montan y sin el cual no puede vivir, cópielo primero en un medio extraíble o en un volumen de red.
La sugerencia de duplicar el disco también es buena. Es una especie de versión "ligera" de la badblocks -nverificación, porque al obligar al disco a leer en cada sector, puede hacer que el disco reubique los bloques problemáticos, como badblocks -nlo hará. badblocks -nes más efectivo porque los sectores dudosos pueden ser apenas legibles y solo mostrarse en el disco como lo suficientemente malos como para moverse al intentar escribir en ellos. Aún así, si al disco le queda suficiente vida para sobrevivir a un rescate, el pase de lectura adicional no será suficiente para acabar con él.
No tengo muchas esperanzas de que al ejecutar fsckla imagen del disco se recupere todo. Es casi seguro que perderá sectores en este proceso, lo que significa que algunos archivos serán ilegibles o estarán dañados hasta el punto de no poder usarse. Un JPEG se decodificará parcialmente con datos corruptos, por ejemplo, pero un JPEG con los ⅔ inferiores recortados podría no resultarle útil.
¿Mis datos están tostados?
Posiblemente, posiblemente no. A veces, el badblocks -npase puede solucionar el problema. Si es así, aún necesita reemplazar el disco duro, ya que un disco solo puede llegar a un estado tan malo si está casi muerto al comenzar.
¿Ya hice algo incorrecto?
Aparte de olvidar el significado de la palabra "riguroso", no. :)
Respuesta2
Esperemos que tenga una imagen de copia de seguridad actual desde la cual restaurar.
Haría una copia de seguridad limitada AHORA de todo lo que desee conservar y luego verificaría si el disco aún se puede utilizar. Un truco que solía usar era usar el dispositivo de partición RAW y agregarlo a /dev/null.....con una opción apropiada se identificaría un área que no se podía leer.