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?