¿Este comando ddrescue está haciendo algo?

En el curso de intentar recuperar datos de un disco duro que falla , estoy ejecutando el comando ddrescue.

El comando ha estado ejecutándose durante 9 días y, por el sonido de la actividad del disco, pensé que tal vez estaba haciendo algo. La salida de la línea de comando se ha visto más o menos estática todo este tiempo:

$ sudo ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:         0 B,  errsize:    500 GB,  current rate:        0 B/s
   ipos:     2539 MB,   errors:       1,    average rate:        0 B/s
   opos:     2539 MB,     time from last successful read:     9.7 d
Splitting failed blocks... 

La única parte que ha estado cambiando es donde dice iposy opos. Tardaron 9 días en llegar 500000 MB, que es el tamaño de la unidad de disco que falla. Sin embargo, cuando llegó allí, volvió a caer 0y comenzó a levantarse nuevamente. Mientras escribo esto, se trata de 2580 MBcontar.

El archivo de imagen que se está creando tiene 0 bytes de longitud.

El archivo de registro tiene un tamaño de aproximadamente 3 MB y se ve así:

# Rescue Logfile. Created by GNU ddrescue version 1.14
# Command line: ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile
# current_pos  current_status
0x975C3000     /
#      pos        size  status
0x00000000  0x00862000  -
0x00862000  0x00014800  /
0x00876800  0x00800400  -
~~~~~~edited for brevity ~~~~~~~~
0x74702CCE00  0x00320000  -
0x74705ECE00  0x00025800  /
0x7470612600  0x005F3A00  -

Estoy empezando a preocuparme porque esto es solo una pérdida de tiempo y no se está recuperando ningún dato.

¿Hay alguna indicación de esta salida de que algo útil está sucediendo?

¿Hay alguna razón para dejar que el ddrescuecomando continúe como está, o debería detenerlo y hacer otra cosa?

Este es el contenido más reciente de /var/log/syslog

Jun 10 07:29:17 homebase-i3 kernel: [568470.316436] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.316443] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.316450] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00
Jun 10 07:29:17 homebase-i3 kernel: [568470.316465] end_request: critical target error, dev sdb, sector 301925016
Jun 10 07:29:17 homebase-i3 kernel: [568470.346640] sd 5:0:0:0: [sdb] Unhandled sense code
Jun 10 07:29:17 homebase-i3 kernel: [568470.346646] sd 5:0:0:0: [sdb]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jun 10 07:29:17 homebase-i3 kernel: [568470.346651] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.346656] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.346662] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00

No sé si todavía está tratando de extraer datos de ese disco duro o si ya tuvo éxito, pero en caso de que no lo haya hecho y le gustaría intentarlo para ver si puede recuperarse, tal vez, perdido Bitcoins o lo que sea, he realizado algunas modificaciones en los ddrescueparámetros de la línea de comandos, he agregado lo siguiente:

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R

• -d que le dice a ddrescue que use el acceso directo al disco,
• --force que le dice a ddrescue que use y lea / escriba con fuerza en su archivo de registro en caso de que se queje de que no puede usarlo con fines de lectura / escritura
• -R (sí, con CAPITAL R) que le indica ddrescueque realice las operaciones de recuperación en reversa en lugar de leer el disco duro fallido en modo de reenvío. A veces, la lectura en reversa ayuda cuando el daño es considerable, ya que esto evita el caché del disco duro en caso de que haya problemas allí.

Actualmente estoy usando estos comandos (excepto que no estoy usando el 3comando ya que no quiero que [AÚN] vuelva ddrescuea intentar sectores defectuosos, lo dejaré para el final, después de que termine mi primer barrido, y estoy teniendo un gran éxito al rescatar datos de mi disco duro Seagate de 1TB donde supuse que podría tener algunos bitcoins que podría haber estado extrayendo entre 2009 y 2010, probablemente encontré de 1 a 3 bloques de 50 BTC cada uno, espero que esté en este disco duro, bueno, Me llevará un total de más de 15 días completar la operación a una velocidad de lectura de 634 kbps promedio.

Además, me gustaría agregar que es probable que, basándose en su historial anterior de más de 9 DÍAS de "actividad de última lectura", se encuentre con una situación en la que el disco duro simplemente se negará a seguir leyendo. situación, simplemente presione CTRL + C para cancelar, ya que está utilizando un archivo de registro, retire el cable SATA del disco duro defectuoso, pero no el controlador USB del puerto USB (sí, use un controlador SATA USB en lugar de conectarlo a una placa base para que no bloquee toda su computadora, lo que le obliga a reiniciar por completo, y luego vuelva a conectar la alimentación SATA para reiniciar el disco duro, déle unos 10 segundos y luego presione la flecha hacia arriba o hacia abajo para volver a cargar su terminal anterior ordenar y reiniciar elddrescueoperación, gracias a su registro anterior, continuará donde lo dejó por última vez y se realizará la lectura y la "última lectura exitosa" siempre permanecerá en "0s" (cero segundos) donde debería, lo que indica que ddrescueestá teniendo éxito en leer desde el disco duro, y si alguna vez nota que la "última lectura de" comienza a contar segundos, simplemente termine una vez más ddrescuecon CTRL+ C, apague y encienda el disco duro y reinicieddrescue, no tiene sentido esperar para ver si la "última lectura de" se reinicia por sí sola, según mi experiencia, nunca va a suceder, esperará la eternidad. Tuve que encender y apagar mi disco duro de 1 TB aproximadamente 20 veces en total, han pasado como 7 días y estoy muy cerca de alcanzar la marca de 500 GB recuperados, a mitad de camino, espero no encontrarme con fallas importantes. Me acerco al 100%, ya que ha estado funcionando sin problemas durante los últimos 3 días, nuevamente a más de 634 kbps.

Además, no sea codicioso al tratar de obtener una velocidad de lectura de rendimiento de datos más rápida, ya que mi intento de probar muchos parámetros y diferentes tamaños de bloque casi me dejó con un remache completamente muerto que dejará de funcionar en más de 1 segundo después de apagarlo. (eso fue hace 5 días), pero afortunadamente comenzó a mostrar signos de vida una vez más, inicialmente leyendo a 2.000 bs (sí BYTES por segundo) un poco menos de 2 kbps, estaba muy decepcionado, pero después de cancelarddrescuecon CTRL + C y solo reiniciando una vez más (en reversa con el parámetro -R) agregado, luego la velocidad volvió a 630, antes de leer hacia adelante a 930 kbps, al menos estoy contento de que estoy haciendo 630 kbps en reversa y no tener que posponer 2kbps, por lo que si tiene éxito a cualquier velocidad de lectura, como en el rango de 500 kbps, manténgalo y no intente nada para aumentar aún más la velocidad, puede ser su último intento exitoso de obtener Cualquier velocidad de lectura.

Alternativamente, si no ddrescuees bueno para usted porque no puede leer nada, independientemente de los parámetros que intente, es posible que desee considerar reemplazar la placa lógica del disco duro, ya que el 90% del tiempo es la placa lógica la que funciona mal, pero primero, quítese la placa lógica y limpie todos los contactos que hacen contacto con los pines del disco duro, algunas veces estos contactos obtienen una mezcla pegajosa negruzca, cortando el contacto que podría ser la fuente de su falla. Pero tenga en cuenta que si tiene que reemplazar la placa lógica de su disco duro, tendrá que obtener uno de la misma marca, número de serie (cercano), número de modelo, número de revisión porque debe ser tan cercano como el original para la junta de donantes para trabajar.

Debería poder detenerse, ddrescueya que utiliza el archivo de registro para poder reiniciar su operación (cerrar) desde donde se quedó. Sin embargo, comprobaría si el archivo de registro se ha actualizado recientemente mirando la marca de tiempo o haciendo tail -f /home/dave/recovery_usb500.logfile.

El hecho de que su archivo de imagen sea tan pequeño podría tener que ver con que aún no se hayan recuperado los bloques de la unidad con éxito. Sin embargo, ese sería un mal resultado después de todo este tiempo en ejecución. Suponiendo que solo haya algunos bloques defectuosos en el dispositivo y que no estén al principio, el estado de sus primeras entradas sería +. IIRC ddrescuecomienza a leer hasta que encuentra un error y luego comienza a dividir el resto del disco. Su disco parece fallar desde el principio.

A menos que haya (múltiples) +entradas en el registro y el tamaño de su archivo aún sería 0, no creo que ddrescueesté mal. No +significa que nada de su disco sea recuperable. Eso podría significar electrónica frita o una mala cabeza, ya que en el caso de que algunos sectores estén defectuosos, habría tenido resultados mucho más rápidos.

En cuanto a hacer otra cosa. Supongo que ya intentaste leer algunos bloques con dd normal. ¿Has mirado el syslog basado en eso y buscaste en Google algún mensaje que encontraste allí?

La búsqueda de "Resultado: hostbyte = driverbyte no válido = DRIVER_SENSE" da como resultado algunas lecturas interesantes (en parte alemanas) con algunas sugerencias más:

• Intente conectarse a través de USB 1.1 en lugar de 2.0
• Es posible que la unidad se caliente, por lo tanto, envuélvala en plástico y póngala en el refrigerador por 10 minutos, esto le dará un poco de tiempo de lectura antes de que la unidad se caliente nuevamente.
• interruptor de SMART en el BIOS (y conéctese con SATA).
• Asegúrese de que la unidad USB tenga suficiente energía (fuente de alimentación adicional)
• Si la lectura a través de USB falla después de un tiempo, use un concentrador USB controlado de forma remota donde cambie mediante programación la alimentación del HUB USB a la unidad durante unos segundos.

Aparte de enfriar un disco ilegible (con spray de enfriamiento), no he probado ninguno de estos.