¿Hay alguna forma de acelerar ddrescue?

Tuve un bloqueo de disco duro de 500 GB hace unos 5 días. Utilicé ddrescuela partición importante hace unos días, y ha estado en "Recorte de bloques fallidos" durante casi 2 días.

Comando original:

ddrescue -n /dev/rdisk1s2 /Volumes/OSXBackup/rdisk1s2.img /Volumes/OSXBackup/rdisk1s2.log

Salida de corriente:

Initial status (read from logfile)
rescued:   248992 MB,  errsize:   1007 MB,  errors:   15867
Current status
rescued:   249021 MB,  errsize:    978 MB,  current rate:    17408 B/s
   ipos:    44405 MB,   errors:   15866,    average rate:     2784 B/s
   opos:    44405 MB,     time from last successful read:       0 s
Trimming failed blocks...

El comando original usó el ddrescue -nparámetro, y he reiniciado el proceso varias veces según sea necesario (y parecía que retomaba exactamente donde lo dejó cada vez).

¿Hay alguna forma de acelerar este proceso?

Editar: Seis horas después, este es el estado actual:

rescued:   249079 MB,  errsize:    920 MB,  current rate:      409 B/s
   ipos:    39908 MB,   errors:   15851,    average rate:     2698 B/s
   opos:    39908 MB,     time from last successful read:       0 s
Trimming failed blocks...

Parece que mientras los "errores" están haciendo una cuenta atrás insoportablemente lenta, ipos / opos está haciendo una cuenta regresiva de la cantidad de datos que tiene que pasar, y parece estar funcionando a una velocidad de 750MB / hora. A este ritmo, se completará en ~ 53 horas. Yikes

Edición n. ° 2: dos días después, aún ejecutándose. Sin embargo, hay esperanza. Se ha pasado la porción "Recorte de bloques fallidos" y pasa a la siguiente fase "División de bloques fallidos". En todo caso, lo que debería evitarse al ver esta pregunta es que esto definitivamente lleva mucho tiempo cuando se trata de una buena cantidad de datos / errores. Mi única esperanza es que pueda recuperar con éxito algunos datos importantes cuando todo esté dicho y hecho.

rescued:   249311 MB,  errsize:    688 MB,  current rate:        0 B/s
ipos:    26727 MB,   errors:   15905,    average rate:     1331 B/s
opos:    26727 MB,     time from last successful read:      20 s
Splitting failed blocks...

Observé que usar la -nopción (sin división) junto con -r 1(reintentar una vez) y establecer -c(tamaño del clúster) en un valor menor puede ayudar.

Mi impresión es que el paso de división es muy lento ya que ddrescuedivide y divide nuevamente las áreas dañadas. Esto lleva mucho tiempo porque ddrescueintenta restaurar porciones muy pequeñas de datos. Por lo tanto, yo prefiero usar -n(sin-split) junto con -c 64, -c 32, -c 16, aso

Probablemente el -n(sin división) siempre se debe usar para un primer pase en direcciones hacia adelante y hacia atrás. Parece que cuanto más se dividieron los datos, más lenta será la clonación, aunque no estoy seguro de esto. Supongo que cuanto más grandes son las áreas no tratadas, mejor cuando se ejecuta ddrescuenuevamente, porque los sectores más contiguos son para clonar.

Como estoy usando un archivo de registro, no dudo en cancelar el comando con Ctrl+ Ccuando la velocidad de lectura de datos se reduce a dos.

También uso el modo -R(Reversa) y después de una primera pasada, a menudo me da velocidades más altas al leer hacia atrás que hacia adelante.

No me queda claro cómo -r Nse manejan los sectores ya reintentados ( ) cuando se ejecuta el ddrescuecomando nuevamente, especialmente cuando se alternan los -Rcomandos de clonación hacia adelante (predeterminado) e inverso ( ). No estoy seguro de si la cantidad de veces que se probaron se almacena en el archivo de registro y probablemente el trabajo se vuelva a hacer inútil.

Probablemente la -ibandera (posición de entrada) también puede ayudar a acelerar las cosas.

Puede ser muy difícil ver el progreso de ddrescue, pero hay otro comando incluido llamado ddrescuelog.

Un comando simple ddrescuelog -t YourLog.txtgenerará estas buenas informaciones:

current pos:     2016 GB,  current status: trimming
domain size:     3000 GB,  in    1 area(s)
rescued:     2998 GB,  in 12802 area(s)  ( 99.91%)
non-tried:         0 B,  in    0 area(s)  (  0%)

errsize:     2452 MB,  errors:   12801  (  0.08%)
non-trimmed:   178896 kB,  in 3395 area(s)  (  0.00%)
non-split:     2262 MB,  in 9803 area(s)  (  0.07%)
bad-sector:    10451 kB,  in 19613 area(s)  (  0.00%)

Incluso puedes usarlo mientras se ddrescueestá ejecutando ...

Una forma más de monitorear el progreso de ddrescue (al menos en Linux) es mediante el uso de strace.

Primero, encuentre el PID para el proceso ddrescue usando "ps aux | grep ddrescue"

root@mojo:~# ps aux | grep ddrescue
root     12083  0.2  0.0  15764  3248 pts/1    D+   17:15   0:04 ddrescue --direct -d -r0 /dev/sdb1 test.img test.logfile
root     12637  0.0  0.0  13588   940 pts/4    S+   17:46   0:00 grep --color=auto ddrescue

Luego ejecuta "strace" contra ese proceso. Verás algo como:

root@mojo:~# strace -p 12083
Process 12083 attached - interrupt to quit
lseek(4, 1702220261888, SEEK_SET)       = 1702220261888
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(3, 1702220261376, SEEK_SET)       = 1702220261376
read(3, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(4, 1702220261376, SEEK_SET)       = 1702220261376
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
^C

...y así. El resultado es rápido y feo, así que luego lo canalizo a través de "grep" para filtrar las cosas que me interesan:

root@mojo:/media/u02/salvage# nice strace -p 12083 2>&1|grep lseek
lseek(4, 1702212679168, SEEK_SET)       = 1702212679168
lseek(3, 1702212678656, SEEK_SET)       = 1702212678656
lseek(4, 1702212678656, SEEK_SET)       = 1702212678656
lseek(3, 1702212678144, SEEK_SET)       = 1702212678144
lseek(4, 1702212678144, SEEK_SET)       = 1702212678144
lseek(3, 1702212677632, SEEK_SET)       = 1702212677632
lseek(4, 1702212677632, SEEK_SET)       = 1702212677632
lseek(3, 1702212677120, SEEK_SET)       = 1702212677120
lseek(4, 1702212677120, SEEK_SET)       = 1702212677120
lseek(3, 1702212676608, SEEK_SET)       = 1702212676608
^C

En ese ejemplo, el "1702212676608" equivale a "la cantidad de datos que aún deben procesarse en ese disco de 2 Tb que está tratando de recuperar". (Sí. Ay.) Ddrescue está escupiendo un número similar, aunque como "1720 GB", en su salida de pantalla.

strace le brinda un flujo de datos de granularidad MUCHO más alto para que lo examine; Es una forma más de evaluar la velocidad de ddrescue y estimar una fecha de finalización.

Ejecutarlo constantemente es probablemente un mal plan ya que competiría con ddrescue por el tiempo de CPU. He decidido ponerlo en "cabeza" para poder tomar los primeros 10 valores:

root@mojo:~# strace -p 4073 2>&1 | grep lseek | head

Espero que esto ayude a alguien.

Si su objetivo es obtener la mayor parte de los datos intactos, entonces podría acelerar su extracción. Pero si realmente desea rescatar la mayor cantidad de datos posible, entonces dejar que ddrecue mordisquee en todos y cada uno es el camino a seguir.

He descubierto que jugar con el parámetro -K puede acelerar las cosas. Por lo que he visto si ddrescue encuentra un error cuando se ejecuta con la opción -n intenta saltar una cantidad fija de sectores. Si aún no puede leerlo, salta el doble del tamaño. Si tiene grandes áreas dañadas, puede indicar un gran valor de K (por ejemplo, 100M) y, por lo tanto, saltar sobre un error será mayor la primera vez y será más fácil evitar áreas problemáticas rápidamente en el primer pasado.

Por cierto, hay una maravillosa aplicación gráfica para analizar el registro.

http://sourceforge.net/projects/ddrescueview/

¿Cuál es el sistema de archivos del disco duro donde guarda la imagen de rescate y el archivo de registro? Acabo de experimentar que rescatar un disco duro interno de 500 GB (conectado a través de SATA) en una computadora portátil con Linux Mint desde un dispositivo USB, guardar la imagen de rescate y el archivo de registro en un exFatdisco duro USB formateado, estaba comenzando bastante lento (1-2 MB / seg), pero después de alrededor de 250 GB solo se arrastraba a <100 KB / seg. Parecía ser más lento a medida que crecía el archivo de imagen de rescate.

Luego moví la imagen de rescate y el archivo de registro a otro lugar temporal, volví a formatear el disco duro USB con el ext4sistema de archivos, moví los archivos nuevamente y reanudé el proceso de ddrescue, y ahora se ejecuta con 1-20MB / seg nuevamente (fluctuante pero alrededor de 7 MB / seg en promedio)

Parece exFatque no juega muy bien con archivos muy grandes (varios cientos de gigabytes).

Para una opción más rápida y rápida para rescatar el disco, puede usar un archivo de secuencia de comandos sh y ejecutar el archivo con "sh filename.sh". Contiene esta línea que se muestra, solo repita "sudo ddrescue" y "sleep 3" unas pocas veces más, la suspensión se usa para que la unidad descanse unos segundos, puede ser buena por algunas razones:

#! /bin/sh -e  
sudo ddrescue -d -r0 -e +0 -T 1s -n /dev/drivepartition file.img log.logfile 
sleep 3

El -r0 no tiene respuestas. -E +0 es para salir en 1 error. El -T 1s sale con 1 segundo de lectura fallida. Hay opciones que se pueden usar como -d para directo y -n sin raspado que puede acelerar.

Puede usar -R después de finalizar con la opción -A una vez, que revertirá y eliminará todos los errores y comenzará de nuevo hacia atrás. Significa que leerá los errores de manera diferente.

dd_rhelp es un script de shell que usa dd_rescue "[...] en todo el disco, PERO intentará reunir los datos máximos válidos antes de intentar durante siglos en grupos de sectores defectuosos".

es bastante antiguo (2012) pero aún funciona. No he probado ddrescue todavía.