Quincena de las pifias (parte 2): ddrescue al rescate

[zup]

Y, como las desgracias no vienen solas, uno de mis discos duros está agonizando. La víctima es un WD Blue de 1Tb, y el historial reciente es el siguiente:
- Hace unos días, el equipo se quedo "colgado" mientras lo apagaba. En principio lo atribuí a que tenía enchufado un pendrive no muy de fiar, y acabé apagándolo de botonazo.
- Habitualmente hago copias de seguridad de algunos datos usando Syncback Pro y ROBOCOPY, cuando estaba haciendo una de esas copias ví que ROBOCOPY estaba diciendo que había errores de lectura.
- Ahí ya me saltaron las alertas y utilicé Crystal Disk Info para ver los atributos SMART... el disco tenía 3 sectores pendientes de relocalizar.
- Al día siguiente, Windows iba de pena. El (según ví en Linux) no solo eran sectores "averiados", sino que el disco de vez en cuando se "desconecta" del bus (¿hace un reset?) lo que podría indicar problemas en la electrónica.

Así que ahora esto se ha convertido en una carrera para recuperar los datos con el mínimo daño posible. Las buenas noticias es que tengo un disco duro WD de 1Tb con exactamente el mismo número de bloques; las malas es que es un WD Green (=leeeeeento) algo viejo. Así que voy a seguir este plan:

Paso 1:
Es una variación de lo expuesto en este hilo. Utilizando mi Debian 11 (que no está en ese disco), utilizaré este comando:

Código: Seleccionar todo

ddrescue -f -r25 /dev/sdb /dev/sdc map_sdb.log

Básicamente voy a copiar de disco a disco directamente. Como voy a copiar a un dispositivo (en vez de generar a una imagen), necesito utilizar el switch -f. Además, voy a hacer que reintente la lectura 25 veces (switch -r25) ya que asumo que se va a generar algún error debido a las "desconexiones" aleatorias del disco y de esta manera quizás pueda recuperar esos errores. Por último, el tercer parámetro me va a generar un "mapa" de los trozos erróneos del disco, para el paso 2. Como nota, no voy a utilizar el parámetro -b (aunque debería definir un bloque de 4K) ya que el programa del paso 2 no está bien probado con sectores de 4K.

No hay que olvidar que -r25 no significa que haga 25 pasadas completas, cada pasada se hace solo para intentar reconstruir los datos no leídos de pasadas previas. Por ello, aunque la primera pasada parece que me va a durar unas 5 horas, espero que las otras 24 no lleven más de media hora entre todas.

Además, otra de las cosas buenas de ddrescue es que puedes interrumpirlo en cualquier momento usando Ctrl+C... si luego repites exactamente la misma orden seguirá dónde lo dejó (por eso tengo metida la orden que estoy utilizando en un fichero .sh).

Paso 2:
Una vez copiado el disco y generado el mapa, voy a utilizar ddrutility para saber qué tengo entre manos. Afortunadamente este paquete está disponible en los repositorios de Debian, lo cual es un gran alivio. Es un alivio porque no compila bien en las últimas versiones de GCC y no está en desarrollo... además, al ser de Debian está parcheado para funcionar correctamente (cierto script no me ha funcionado bien cuando he compilado el paquete a manija). En fin, el plan es utilizar este comando:

Código: Seleccionar todo

ddru_findbad /dev/sdb map_sdb.log

Este comando me genera una salida que lista los sectores ilegibles relacionados con los ficheros que los contienen. De esta manera tengo una idea precisa de qué es lo que tengo corrompido.

Paso 3:
Poner el disco "rescatado" en el sistema para que al menos Windows sea operativo. Luego, borraré los ficheros corrompidos para poder sustituirlos por copias correctas. Además, recortaré el tamaño de partición unos 100 megas para que cuando me llegue el disco nuevo que he pedido no haya problemas al clonarlo. He mirado el modelo en la ficha de la tienda, y me he asegurado que sea un modelo que no usa SMR... habrá que ver si me sirven ese mismo modelo o tengo que devolverlo.

Paso 4:
Machacar el contenido del disco duro averiado antes de decidir su futuro. No sé si tirarlo directamente al punto limpio, donarlo a alguien que quiera usarlo conociendo sus defectos o desmantelarlo (y quedarme los imanes y hacer un reloj con los platos).

[zup]

Ya he terminado los pasos 1 y 2. Para documentar un poco el proceso...

Leyendo el disco:

Código: Seleccionar todo

GNU ddrescue 1.26
Press Ctrl-C to interrupt
     ipos:  381557 MB, non-trimmed:   225280 B,  current rate:  58130 kB/s
     opos:  381557 MB, non-scraped:        0 B,  average rate:  34644 kB/s
non-tried:  618737 MB,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:  381466 MB,   bad areas:        0,        run time:  3h  3m 31s
pct rescued:   38.13%, read errors:        9,  remaining time:      3h  8m
                              time since last successful read:          0s
Copying non-tried blocks... Pass 1 (forwards)

El trozo anterior es lo que va mostrando por pantalla mientras hace el [/b]ddrescue[/b]. Los parámetros curiosos (en esta fase), son los siguientes:

• ipos/opos: Posición del disco/imagen que está leyendo/escribiendo.
• rescued: Cantidad de datos que ha leído correctamente.
• non-tried: Cantidad de datos que todavía no ha intentado leer.
• non-trimmed: Cantidad de datos con problemas... por ahora
• read errors: Cantidad de lecturas erróneas.
• run time / remaining time: Cuánto tiempo lleva corriendo y cuánto tiempo cree que le va a llevar acabar.

El proceso de ddrescue es leer primero en bloques de 128k (creo). Cada vez que un bloque falla, lo pasa a la lista non-trimmed. Una vez que ha leído todo eso, hace otra pasada para averiguar qué partes de los bloques de 128k son salvables (trim) y pasan de la lista de non-trimmed a la de non-scraped. Por último intenta releer los bloques non-scraped. Todo lo que no ha podido leer se queda en bad-sector (cantidad de bytes erróneos) y bad areas (cantidad de áreas con errores contiguos.

Por ejemplo, un CD-ROM que tuviera 10 bloques defectuosos contiguos tendría un valor de bad sector de 20480 bytes y un valor de bad areas de 1.

Es importante tener en cuenta que, durante la lectura, non-trimmed nos mostrará una cantidad exagerada de errores (pero al final debería quedarse a cero).

Fin de la lectura:
Después de alguna interrupción, ddrescue escupió esto:

Código: Seleccionar todo

GNU ddrescue 1.26
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 1000 GB, tried: 90112 B, bad-sector: 90112 B, bad areas: 22

Current status
     ipos:    3057 MB, non-trimmed:        0 B,  current rate:       0 B/s
     opos:    3057 MB, non-scraped:        0 B,  average rate:       0 B/s
non-tried:        0 B,  bad-sector:    90112 B,    error rate:       0 B/s
  rescued:    1000 GB,   bad areas:       22,        run time:      4m 19s
pct rescued:   99.99%, read errors:      123,  remaining time:         n/a
                              time since last successful read:         n/a
Retrying bad sectors... Retry 1 (backwards)
Finished

Ahí podemos ver que ha terminado todos los procesos (non-trimmed y non-scraped a cero) y que ha encontrado 90112 bytes en 22 áreas erróneas (consistente con el informe de smartctl que anunciaba 22 bloques erróneos, mi disco duro tiene un tamaño de sector de 4096 bytes).

Una lectura "limpia" debería mostrar non-trimmed, non-scrapped, bad-sector y bad-areas a 0 (y pct rescued al 100%). Otra cosa a tener en cuenta es que read errors no muestra la cantidad de errores reales, sino la cantidad de errores que se ha encontrado durante todos los procesos de todas las pasadas.

El fichero mapfile generado viene a ser algo así...

Código: Seleccionar todo

# Mapfile. Created by GNU ddrescue version 1.26
# Command line: ddrescue -f -r1 /dev/sdb /dev/sdc map_sdb.log
# Start time:   2022-07-23 09:47:40
# Current time: 2022-07-23 09:51:59
# Finished
# current_pos  current_status  current_pass
0xB63EC200     +               2
#      pos        size  status
0x00000000  0xB63EC000  +
0xB63EC000  0x00001000  -
0xB63ED000  0x02981000  +
0xB8D6E000  0x00001000  -
0xB8D6F000  0x00CCC000  +
0xB9A3B000  0x00001000  -
0xB9A3C000  0x004C8000  +
0xB9F04000  0x00001000  -
     ...

Lo he recortado porque lo siguiente es muy parecido a estas líneas...

Básicamente es una lista de las áreas del disco. Las líneas tienen tres campos: Posición de inicio, longitud del área y un símbolo. El símbolo (de los que yo he visto) puede ser +, - o ? que indican:

• + indica que el área se ha leído correctamente.
• - indica que el área tiene errores.
• ? indica que ese área todavía no está leída, o que debe volver a releerse (non-trimmed).

Ficheros defectuosos:
Al ejecutar ddru_findbad, nos muestra por pantalla los ficheros a los que corresponden los bloques dañados. También genera una serie de ficheros (results_debug.txt, results_info.txt, results_list.txt y results_summary.txt) con esta y otras informaciones.

Lo que me ha salido por pantalla es más o menos esto:

Código: Seleccionar todo

Command line input was processed succesfully
ddru_findbad 1.11 20141015
Waring! GNU fdisk is not detected!
Therefore GPT partitioned disks will not be able to be processed
and this script may produce errors if trying to do so.
See help file for more info.
Target = /dev/sdc
Logfile = map_sdb.log
Output base name = results
Sector size = 512
Loop wait time = 2
More info = false
Extra output = false
Quick = false
Quick ntfs = false
Target /dev/sdc is detected to be a block device
Target /dev/sdc is found to be a whole dos partitioned disk
Processing ddrescue log file
0xB63EC000 0x00001000 -
0xB8D6E000 0x00001000 -
     ...
0xA02BCB0000 0x00001000 -
0xA5BC87B000 0x00001000 -
5971808 5971815
6056816 6056823
     ...
1343612288 1343612295
1390298072 1390298079
Checking /dev/sdc1
Partition /dev/sdc1 type NTFS is found to be ntfs
Checking cluster 746220 Inode 8 File /$BadClus/$DATA($Bad)
Checking cluster 756846 Inode 2 File /$LogFile/$DATA
     ...
Checking cluster 761361 Inode 2 File /$LogFile/$DATA
Checking cluster 788570 Inode 0 File /$MFT/$DATA
Checking cluster 2450399 Inode 824436 File /PortableApps/LibreOfficePortable/App/libreoffice/help/media/icon-themes/sd/res/$INDEX_ALLOCATION($I30)
Checking cluster 2517351 Inode 733311 File /PortableApps/ThunderbirdPortable/App/Thunderbird/omni.ja/$DATA
Checking cluster 8692402 Inode 198692 File /PortableApps/OperaPortable/App/Opera/89.0.4447.51/opera_browser.dll/$DATA
     ...

Básicamente podemos ver:

• Una primera parte con los datos de lo que queremos hacer.
• La lista de las áreas erróneas en hexadecimal y en decimal.
• Una lista de a qué ficheros están mapeados los bloques erróneos.

He recortado la salida para quitar cosas poco interesantes. En mi caso, la carnicería ha acabado (relativamente) bien. En el extracto que he posteado podemos ver algunos errores en las tablas MFT que espero que se solucionen con un chkdsk (hay varias copias de estas tablas en el disco), además de ficheros pertenecientes a una copia local de PortablesApp (puedo borrar los directorios afectados y volver a descargar esas aplicaciones).

Más adelante se listan algunos ficheros (privados) de documentos que serían los que deberían preocuparme más... pero afortunadamente son copias de cosas que tengo en otros discos. Supongo que hoy he esquivado la bala.

De todas formas, cuando llegue el nuevo disco volveré a copiar todas estas cosas... nunca se sabe si he tenido algo de corrupción silenciosa (también puedo dejar al ordenador verificando todos los ficheros ZIP/RAR/7zip a ver si son descomprimibles).

Otras opciones y algunas dudas:
Por ahora, ddrescue parece insustituible. Sin embargo, ya he dicho que ddrutility está abandonado.

En teoría, los programas de clonación de disco deberían ser capaces de tratar con estas situaciones. Clonezilla tiene la opción de ignorar los errores y seguir adelante (creo que tira de ddrescue), pero no sé si en este caso genera un fichero de log con los errores encontrados o ficheros afectados (tendría que comprobarlo, pero me llevaría un montón de horas). Mis otras dos opciones favoritas (Acronis True Image y Norton Ghost) no sé si son capaces de continuar si el disco tiene errores (me suena que el Ghost sí, pero no sé si genera algún tipo de log que pueda grabar a un pendrive para análisis posteriores), pero seguro que se confunden si hay errores en las MFTs.

El problema de ddrutility es algo más peliagudo. En Linux, existe sleuthkit (de hecho ddrutility se apoya en él) que puede hacer este mapeo de bloques erróneos a ficheros (¡incluso en sistemas de ficheros ISO!), pero habría que hacer a mano los scripts necesarios. ¿Alguien conoce alternativas a estos programas?

[GXY]

yo normalmente cuando me encuentro en una de estas situaciones no intento un procedimiento como el que documenta @zup

primero intento hacer una copia simple, copiar carpetas con windows de toda la vida. y cuando algo falla pues ya vuelvo atras y le dedico mas atencion a la parte que falle.

eso me permite, entre otras cosas, que si es algo que pueda perder (porque me importe un huevo o porque lo pueda recuperar volviendolo a bajar o de alguna otra parte) hacer la copia en un plazo razonable / pequeño de tiempo, con minimas perdidas.

obviamente hablo de un disco que esta en situacion dudosa pero operativa. si esta petado ya tocan otras soluciones.

para mi los WD es junto con IBM/Hitachi los discos duros mas fiables que hay. obviamente depende de gamas y del uso, pero hasta la fecha (toco madera) el numero de averias que he tenido en discos duros de esas marcas es 0.

y hay un hitachi al que entre unas cosas y otras le estoy dando una tralla considerable desde que lo compre hace cosa de 5 años. y era usado cuando lo compre.

ah. muchas averias de disco duro remiten a la electronica que controla su suministro electrico es decir que la averia puede ser de cableado/fuente o tambien mal cableado SATA. no sera la primera vez que me encuentro un disco duro haciendo pirulas porque el cable SATA lo han forzado para que no estorbara y esta medio partido por dentro.

por eso por ejemplo cuando me hablan el tipico tengo un disco externo y esta fallando... lo primero que propongo es siempre lo has abierto has sacado el disco duro y lo has probado conectado directo en el PC¿?. esto, evidentemente, cuando se trata de cajas externas donde se utiliza internamente un disco SATA... que desde hace unos años ya no es la norma (los discos ya vienen con conector USB, sobre todo en tamaño 2.5" aunque creo que incluso algun 3.5" ya viene asi)

pd. yo para recuperaciones de archivos (borrados accidentales, discos semi-petados...) utilizo R-Studio, que tengo una version registrada que tiene ya unos años, pero sigue funcionando bien para NTFS.

[zup]

primero intento hacer una copia simple, copiar carpetas con windows de toda la vida. y cuando algo falla pues ya vuelvo atras y le dedico mas atencion a la parte que falle.

Bueno, parte del problema que tenía era que el disco se quedaba "colgado" e incluso se "reseteaba" durante las lecturas. Eso provocaba que Windows se volviera loco y fuera incapaz de operar con normalidad. Lo de copiar cosas ya lo dejamos en ciencia ficción.

No lo he comentado, pero ddrescue también cascó en medio de una copia (un mensaje raro diciendo que no había recibido todos los datos esperados y que comprobara el tamaño del bloque)... al mirar los mensajes del núcleo con dmesg aparecían:
- Errores de lectura.
- Una desconexión del disco duro (el núcleo no podía acceder al dispositivo conectado a ese puerto SATA).
- Un minuto o dos después, la reinicialización/reconexión del disco duro.

Entre eso y los fallos en la MFT, es hasta normal que Windows se quedara KO (bastante me parece que no soltara ni un pantallazo azul).

eso me permite, entre otras cosas, que si es algo que pueda perder (porque me importe un huevo o porque lo pueda recuperar volviendolo a bajar o de alguna otra parte) hacer la copia en un plazo razonable / pequeño de tiempo, con minimas perdidas.

Una de las opciones que NO he explorado con ddrutility es que es capaz de generar una especie de "mapa" de la partición Windows para pasárselo a ddrescue. De esta manera ddrescue solo intentará copiar los trozos de disco que realmente contienen datos.

De cualquier manera, dado que parte de los sectores erróneos afectaban a la MFT este procedimiento quiźas también estaría abocado al fracaso (pero puedo intentar hacerlo en algún momento aburrido).

para mi los WD es junto con IBM/Hitachi los discos duros mas fiables que hay. obviamente depende de gamas y del uso, pero hasta la fecha (toco madera) el numero de averias que he tenido en discos duros de esas marcas es 0.

El disco duro que ha fallado es un WD Blue WD10EALX que fue fabricado hace casi 11 años. Creo que para una gama de consumo ya había cumplido las expectativas de vida De todas formas, cuando las cosas van cogiendo una edad son más susceptibles de fallar (y supongo que ese disco vivía de prestado). Quizás sería más acertado hablar de que esas marcas son menos propensas a fallar durante la vida estimada del producto.

(Por cierto, tengo bastante experiencia reemplazando discos duros Hitachi. Tuve un cliente que había que cambiar por lo menos un disco duro cada semana, entre Seagate y Hitachi. No creo que fuera por ser malos, es que en un CPD con varias cabinas que sumaban 1200 discos duros operando 24x7 había tantos discos que ese ritmo era normal.)

Me he asegurado de que su sustituto sea CMR... he leído por ahí que muchos discos nuevos utilizan SMR y que esta tecnología no es tan fiable como sería deseable.