Después de investigar con expertos en este tema, programadores de deferentes áreas y maestros hemos dado con la solución al problema y la dejamos plasmada en esta publicación.
Solución:
-
Está utilizando los 512 bytes predeterminados
ddtamaño de bloque. Mejoraría significativamente el rendimiento utilizando un tamaño de bloque más grande, digamos128ko incluso1m. -
Hay dos salidas porque está ejecutando dos
ddcomandos, el primero es el lector del dispositivo y muestra un error de E/S. -
Es probable que esté usando LVM dado el nombre del dispositivo que usa:
/dev/Storage/Storage. ¿Está seguro de que se trata de todo el disco y no de un subconjunto? Usarlvdisplaypara averiguar qué hay detrás de este nombre de dispositivo.
Busque en los mensajes de registro de su núcleo (dmesgo /var/log/kern.log) para obtener mensajes más detallados de los controladores SATA, si se trata de un error de hardware. También útil: smartctl -x /dev/sda. Si fue solo un intento de leer más allá del final de una partición o algo así, eso también podría aparecer en el registro del kernel.
Para hacer que dd continúe después de un error de E/S, para leer las partes legibles que siguen al error, use
dd if=... of=... conv=noerror bs=128k # it doesn't get any faster beyond about 128k, because of L2 cache size
(Como se menciona en los comentarios sobre el OP, ddrescue tiene esto y más. conv=noerror fue añadido a GNU dd después ddrescue existió, IIRC.)
Si desea continuar donde lo dejó, puede utilizar el seek y skip opciones, con conv=notrunc.
Si realmente desea ver qué tan avanzado está dd, mire la posición del archivo de su stdin:
cat /proc/$(pidof dd)/fdinfo/0 # dd opens its infile as fd #0
(o ls -lh el tamaño del archivo de salida). Me parece una tontería copiar un disco duro completo con datos 2 veces adicionales canalizándolos a través de algo, como si solo hiciera que su computadora fuera un poco más lenta de lo necesario durante las horas que tomará la copia.
O al menos hacer:
dd if=... conv=noerror bs=128k | pv > Storage.img