
Estoy clonando una unidad de 1 TB en otra unidad de 1 TB usando el comando dd en Ubuntu usando un USB activo. He estado monitoreando el progreso ejecutando en otra terminal:
sudo kill -USR1 $(pgrep ^dd)
Al principio todo iba bien y esperaba que la copia estuviera lista en poco más de un día. Regresé dos días después y vi que el ritmo se había reducido hasta casi detenerse.
1055628+0 records in
1055628+0 records out
69181636608 bytes (69 GB, 64 GiB) copied, 160488 s, 431 kB/s
1055629+0 records in
1055629+0 records out
69181702144 bytes (69 GB, 64 GiB) copied, 160491 s, 431 kB/s
¿Hay algo que pueda hacer?
editar: El comando exacto que utilicé fue:
sudo dd if=/dev/sdb of=/dev/sdd bs=64K conv=notrunc,noerror
No ha habido errores ni advertencias. No esperaba errores y por eso no utilicé ningún otro comando para comprobar el disco por adelantado, aunque en retrospectiva hubiera sido lo más inteligente. Ante esto, ¿cuál sería ahora el mejor curso de acción?
Edit2: Ejecuté dmesg
y ahora veo que se produjeron algunos errores de E/S y probablemente sea el culpable.
Cancelaré dd
, instalaré y usaré ddrescue
. ¡Gracias por la ayuda!
Respuesta1
Considere usar ddrescue
en su lugar. Si la unidad tiene una o dos áreas defectuosas (ilegibles), ddrescue omitirá las partes lentas al principio (asegurándose de que obtendrámayoríadel disco clonado lo suficientemente rápido), y volverá a "raspar" las áreas omitidas en una etapa posterior. Sin embargo, si la unidad tienemuchosEn los sectores defectuosos, el raspado aún llevará mucho tiempo (posiblemente días), sin importar lo que hagas.
ddrescue /dev/sdb /dev/sdd /tmp/sdb-sdd.log
(El archivo de registro se puede ver usando ddrescueview
.)