Recuperar archivos del sistema de archivos ext3 con errores físicos

Recuperar archivos del sistema de archivos ext3 con errores físicos

Tengo un disco de una computadora portátil Linux averiada con archivos que al infeliz propietario le gustaría recuperar si es posible (no hay soluciones de respaldo, por favor). No he tenido nada que ver con eso antes. El disco es reconocido tanto por OS X como por Ubuntu 11.10:

root@ubuntu1110:~# fdisk -l /dev/sdc

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x80d549b4

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *          63   953602334   476801136   83  Linux
/dev/sdc2       953602335   976768064    11582865    5  Extended
/dev/sdc5       953602398   976768064    11582833+  82  Linux swap / Solaris

Esto parece consistente con una instalación estándar de una distribución de Linux con una partición de intercambio.

Desafortunadamente, aparecen algunos mensajes bastante desagradables en dmesg, después de que Ubuntu dice que no puede montar la partición sdc1:

[  181.228092] sd 6:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[  181.232176] sd 6:0:0:0: [sdc] Write Protect is off
[  181.232181] sd 6:0:0:0: [sdc] Mode Sense: 21 00 00 00
[  181.236359] sd 6:0:0:0: [sdc] No Caching mode page present
[  181.236364] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  181.246696] sd 6:0:0:0: [sdc] No Caching mode page present
[  181.246707] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  182.835915]  sdc: sdc1 sdc2 < sdc5 >
[  182.854199] sd 6:0:0:0: [sdc] No Caching mode page present
[  182.854204] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  182.854208] sd 6:0:0:0: [sdc] Attached SCSI disk
[  218.250174] sd 6:0:0:0: [sdc] Unhandled sense code
[  218.250179] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  218.250182] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  218.250187] Info fld=0x0
[  218.250188] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  218.250193] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 01 08 00 00 08 00
[  218.250200] end_request: I/O error, dev sdc, sector 264
[  218.250206] Buffer I/O error on device sdc, logical block 33
[  255.398994] sd 6:0:0:0: [sdc] Unhandled sense code
[  255.399029] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  255.399032] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  255.399037] Info fld=0x0
[  255.399038] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  255.399053] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 01 08 00 00 08 00
[  255.399061] end_request: I/O error, dev sdc, sector 264
[  255.399066] Buffer I/O error on device sdc, logical block 33
[  281.340599] sd 6:0:0:0: [sdc] Unhandled sense code
[  281.340609] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  281.340618] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  281.340653] Info fld=0x0
[  281.340655] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  281.340659] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 00 67 00 00 08 00
[  281.340667] end_request: I/O error, dev sdc, sector 103
[  281.340739] EXT3-fs (sdc1): error: can't read group descriptor 4

Mi teoría actual es que el disco duro se ha quedado sin bloques de repuesto, por lo que ahora se ha introducido un bloque realmente defectuoso y se encuentra en el área utilizada al montar la partición. Esto lo confirma dd:

root@ubuntu1110:~# dd if=/dev/sdc1 of=/dev/null bs=10240 conv=noerror
dd: reading `/dev/sdc1': Input/output error
2+0 records in
2+0 records out
20480 bytes (20 kB) copied, 44.7084 s, 0.5 kB/s
dd: reading `/dev/sdc1': Input/output error
9+1 records in
9+1 records out
96256 bytes (96 kB) copied, 162.933 s, 0.6 kB/s
dd: reading `/dev/sdc1': Input/output error
9+1 records in
9+1 records out
96256 bytes (96 kB) copied, 180.083 s, 0.5 kB/s

Bloqueos defectuosos temprano y velocidad de transmisión muy lenta incluso más adelante en el proceso (no se muestra)

Mi problema ahora es cómo acercarme desde aquí. Necesito algo que pueda leer desde un sistema de archivos ext2/ext3 roto para que podamos copiar esos archivos que aún están allí fuera del disco, y no he realizado mucha administración del sistema Linux en los últimos 15 años, por lo que no conozco los términos correctos para la búsqueda. .

Probablemente podría copiar una imagen de disco durante la noche, pero luego se pierde la información "este bloque es malo".

¿Qué tipo de programa sería útil en esta situación?

Respuesta1

Primera regla de recuperación de disco:Deja de usar el disco. Si hay problemas de hardware (como un choque de cabeza), cualquier uso corre el riesgo de sufrir daños mayores; si el sistema de archivos está corrupto, cualquiera mounto fscktiene el potencial de empeorarlo. (¡Incluso en romodo! Tenga en cuenta quemount -t ext3 -o ro voluntad¡Intente reproducir el diario y escribir en el disco!)

Usardd_rescueoddrescatePara copiar la mayor cantidad posible de la imagen del disco a otro sistema, guarde el disco y haga copias de la imagen. Realice todos los intentos de recuperación de una de las copias.

Ahora, di algunos consejos para la recuperación de datos externos.aquí. En breve,

  • El diseño de su partición parece seguir siendo válido. Si no fuera así, podrías usarDisco de pruebaopartepara intentar recuperar la tabla de particiones.
  • e2fsckes posible que pueda volver a colocar el sistema de archivos en un estado montable. Colocará inodos colgantes /lost+founde informará errores.
  • ext4magiaintenta recuperar datos de metadatos registrados. Que los archivos se puedan recuperar del diario depende de la suerte y el azar, pero es posible que haya cosas allí.
  • El kit de detectivePuede analizar y generar la mayoría de las estructuras del sistema de archivos. Si sabe bastante sobre el diseño interno del sistema de archivos y tiene a mano un editor hexadecimal (para hacer cosas como "el superbloque está corrupto y el superbloque de respaldo está desactualizado, pero puedo seleccionar suficientes datos para reconstruirlo yo mismo"), en mi opinión, esto es la herramienta absolutamente más útil para recuperar la mayor cantidad de datos.
  • FotoRecIntentará encontrar secuencias de bytes que parezcan archivos. Solo adivina el inicio/final del archivo, no sabrá nada sobre la estructura del sistema de archivos, como directorios y nombres de archivos, y no encontrará archivos fragmentados.

Respuesta2

Suponiendo que haya analizado todos los pros y los contras habituales de los servicios profesionales de recuperación de datos, haya sopesado el costo de los datos perdidos frente al riesgo de hacerlo usted mismo... el usuario decidió que los datos no valían miles de dólares, peroesvale horas y horas de tu tiempo...

Esto es lo que haría.

Si obtuve 0,5 kB/s consistentemente en el dd, probablemente no valga la pena intentar esto.

podríaejecute Testdisk contra el disco. Élpodríatrabajar. Si el costo/riesgo no dicta otras opciones, entonces... es su decisión. Podría funcionar.

En general, en serio, estos problemas son un campo minado político. El usuario se siente demasiado avergonzado como para pedir a sus compañeros de trabajo que le vuelvan a enviar sus archivos, o no quiere enfrentarse a su gestión y admitir que no realizó copias de seguridad periódicas y que ahora necesita gastar miles de dólares en recuperación de datos. Esperan que tal vez puedas solucionarlo y hacer que todos sus problemas desaparezcan... y si el disco se autodestruye en el proceso. TE LANZARÁN DEBAJO DEL AUTOBÚS para salvar su propio pellejo.

información relacionada