Tuve un fallo en el disco duro de 500 GB hace unos 5 días. Lo usé ddrescueen la partición importante hace unos días y ha estado en "Recortar 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 usaba el ddrescue -nparámetro y reinicié el proceso varias veces según fue necesario (y pareció continuar justo donde lo dejó cada vez).
¿Hay alguna manera 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 "errors" cuenta regresivamente lentamente, ipos/opos cuenta regresivamente la cantidad de datos que tiene que procesar, y parece estar funcionando a una velocidad de 750 MB/hora. A este ritmo, se completará en aproximadamente 53 horas. Vaya.
Edición #2:Dos días después, sigue funcionando. Sin embargo, hay esperanza. Pasó la parte "Recortar bloques fallidos" y pasó a la siguiente fase "Dividir bloques fallidos". En todo caso, lo que se debe sacar al ver esta pregunta es que definitivamente lleva mucho tiempo cuando hay una buena cantidad de datos/errores involucrados. Mi única esperanza es poder 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...
Respuesta1
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 ser útil.
Mi impresión es que el paso de división es muy lento ya que ddrescueparte y vuelve a dividir las áreas dañadas. Esto lleva mucho tiempo porque ddrescueintenta restaurar porciones muy pequeñas de datos. Entonces, prefiero usar -n(no-split) junto con -c 64, -c 32, -c 16, también
Probablemente el -n(no-split) siempre debería usarse para una primera pasada en dirección hacia adelante y hacia atrás. Parece que cuanto más se dividían los datos, más lenta era la clonación, aunque no estoy seguro de ello. Supongo que cuanto más grandes sean las áreas no tratadas, mejor será cuando se ddrescuevuelva a ejecutar, 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 es baja.
También uso el -Rmodo (Reversa) y después de una primera pasada a menudo me da velocidades más altas leyendo 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 -Rcomandos de clonación directa (predeterminada) e inversa ( ). No estoy seguro de si la cantidad de veces que se intentaron se almacena en el archivo de registro y probablemente el trabajo se haya realizado nuevamente de manera inútil.
Probablemente la -ibandera (posición de entrada) también pueda ayudar a acelerar las cosas.
Respuesta2
Puede ser muy difícil ver el progreso de ddrescue, pero se incluye otro comando llamado ddrescuelog.
Un comando simple ddrescuelog -t YourLog.txtgenerará esta interesante información:
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 ddrescueestá funcionando...
Respuesta3
Descubrí que jugando con el parámetro -K puedes acelerar las cosas. Por lo que he visto, si ddrescue encuentra un error al ejecutar con la opción -n intenta saltar una cantidad fija de sectores. Si todavía no puede leer, salta el doble de tamaño. Si tiene grandes áreas dañadas, puede indicar un valor K grande (por ejemplo, 100 M) y así el salto en caso de error será mayor la primera vez y será más fácil evitar áreas problemáticas rápidamente en la primera pasada.
Por cierto, existe una maravillosa aplicación gráfica para analizar el registro.
Respuesta4
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 ejecute "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
...etcétera. La salida es rápida y fea, así que luego la 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, "1702212676608" equivale a "la cantidad de datos que aún deben procesarse en ese disco de 2 Tb que estás intentando recuperar". (Sí. Ay.) ddrescue está arrojando un número similar, aunque como "1720 GB", en su salida de pantalla.
strace le brinda un flujo de datos de MUCHA mayor granularidad para que usted los examine; Es una forma más de evaluar la velocidad del ddrescue y estimar una fecha de finalización.
Ejecutarlo constantemente probablemente sea un mal plan ya que competiría con ddrescue por el tiempo de CPU. He decidido conectarlo a la "cabeza" para poder tomar los primeros 10 valores:
root@mojo:~# strace -p 4073 2>&1 | grep lseek | head
Espero que esto ayude a alguien.