☰

Partición ext4 perdida: testdisk enumera archivos, pero no logra reparar la tabla de particiones

tag-icon • tag-icon linux ubuntu partitioning data-recovery partition-recovery
Partición ext4 perdida: testdisk enumera archivos, pero no logra reparar la tabla de particiones

Resumen:

Testdisk encuentra la partición ext4 perdida y puede enumerar los archivos que la contienen, pero intentar escribir la estructura de la partición en el disco no hace nada.

Actualizar: Después de ejecutarlo e2fsck -f /dev/sdc1, el disco se montó y parece funcionar normalmente. Sin embargo, también informó algunos errores (consulte el punto 15 a continuación).

Qué pasó:

Intentaré enumerar todo lo que hice relacionado con el problema:

  1. Obtuve un nuevo disco duro externo de 5 TB preformateado como FAT32 (llamado Intenso).
  2. Eliminé esa partición y creé una nueva partición ext4 usando gparted (llamada Intenso5TB).
  3. Como la partición pertenecía a root, cambié de propietario y de grupo a mi usuario.
  4. Moví unos cientos de GB de datos a esa partición y luego los eliminé de forma segura.
  5. La siguiente vez que conecté el disco duro, se montó como de sólo lectura. Mi usuario seguía siendo el propietario.
  6. Agregué "rw" a las opciones de montaje en la utilidad "Discos" de Ubuntu y desmonté la unidad.
  7. La utilidad Discos luego mostró la partición /dev/sdc1 como "tipo desconocido" y no se pudo montar.
  8. Elegí "Editar partición" y seleccioné "Tipo Linux (0x83)" (no se seleccionó ningún tipo). No hubo cambios (aún se desconoce el tipo).

  9. Corrí sudo testdisk /dev/sdce hice un análisis rápido, que encontró:

    * Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]

    Al presionar pse muestran los archivos que moví a la partición., entonces le dije a Testdisk que escribiera la estructura de la partición en el disco.

  10. Después de otro reinicio para actualizar la tabla de particiones, el comportamiento volvió a ser el descrito en 7.

  11. Rehice 9.; esta vez intenté usar

    partprobe /dev/sdc

    para evitar reiniciar nuevamente, pero recibí el mensaje:

    Error: Partition(s) 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64 on /dev/sdc have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.

  12. sudo fdisk -ludevoluciones

    Disk /dev/sdc: 4,6 TiB, 5000981078016 bytes, 1220942646 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33550336 bytes
Disklabel type: dos
Disk identifier: 0x4400838c

Device     Boot Start        End    Sectors  Size Id Type
/dev/sdc1  *      256 1220942591 1220942336  4,6T 83 Linux

  13. sudo parted /dev/sdcLuego ejecuté rescue 256 1220942591lo que no hizo nada (sin demora, sin salida, solo un nuevo símbolo del sistema dentro de la partición), lo mismo con rescue 0 1220942591, rescue 1 1220942591o rescue 1 -1.

  14. Realicé una búsqueda profunda con Testdisk, que informó varias líneas idénticas de:

    Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]

    así como también:

    check_FAT: can't read FAT boot sector
Invalid FAT boot sector
 0 D FAT16 LBA            252822 192 45 254047 161 57   19677685
  FAT16 LBA            252822 192 45 254047 161 57   19677685

    mientras corre y cerrado con:

    TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org

Disk /dev/sdc - 5000 GB / 4657 GiB - CHS 76000 255 63

The harddisk (5000 GB / 4657 GiB) seems too small! (< 16 TB / 15 TiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partition can't be recovered:
     Partition               Start        End    Size in sectors
>  FAT16 LBA            252822 192 45 254047 161 57   19677685










[ Continue ]
80 GB / 75 GiB

  15. Después de ejecutar e2fsck -f /dev/sdc1, el disco apareció en el iniciador. Cancelé e2fsckcon Ctrl+Cpara evitar más cambios hasta que sepa más. Luego, la unidad se montó exitosamente al hacer clic. Parece que puedo leer y escribir. Salida de e2fsck:

    e2fsck -f /dev/sdc1
e2fsck 1.42.13 (17-May-2015)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
Intenso5TB: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Inode 59883521 is in use, but has dtime set.  Fix<y>? yes
Inode 59883521 has imagic flag set.  Clear<y>? yes
Inode 59883521 has compression flag set on filesystem compression support.  Clear<y>? yes
Inode 59883521 has INDEX_FL flag set but is not a directory.
Clear HTree index<y>? yes
Inode 59883521, i_blocks is 16777216, should be 0.  Fix<y>? yes
Deleted inode 59885573 has zero dtime.  Fix<y>? yes
Deleted inode 59885574 has zero dtime.  Fix<y>? yes
^CIntenso5TB: e2fsck cancelled.

Intenso5TB: ***** FILE SYSTEM WAS MODIFIED *****

Mis preguntas:

  1. ¿He cometido algún error obvio que podría haber causado este problema en primer lugar?

  2. ¿Existe alguna esperanza de recuperar la partición perdida? Nueva pregunta: ¿Los errores reportados son e2fsckmotivo de preocupación? ¿Podrían insinuar un disco físicamente dañado?

  3. ¿Qué causa el mensaje de error partprobeen 11?

(Los datos se movieron desde otro disco que no he tocado desde entonces, por lo que, aunque no están visibles en este momento, deberían poder recuperarse desde allí).

Respuesta1

La ejecución e2fsck -f /dev/sdc1solucionó un superbloque defectuoso y el dispositivo fue reconocido sin problemas. Luego dejé que e2fsckse solucionaran todos los problemas que descubrió. En una ejecución posterior e2fsckno se informaron más errores.

Una prueba fuera de línea extendida que smartctlse completó después de 9 horas sin informar errores (para evitar que el giro automático cancele la prueba, apliquéesta solución).

información relacionada