¿Cómo aceleraría un disco completo dd?

51

Estoy haciendo un dd en dos unidades idénticas con este comando:

 dd if=/dev/sda of=/dev/sdb bs=4096

Ambos discos duros tienen exactamente el mismo número de modelo y ambos tienen 1TB de espacio de almacenamiento. /dev/sda usa un tamaño de bloques de 4096. /dev/sda es un disco local y /dev/sdb es un caddy remoto. Es posible que pueda usar los siguientes protocolos:

  • USB2.0 HighSpeed ​​(actualmente el plan)
  • Clon Gigabit Over-The-Network (realmente no quiero ni probar esto)
  • USB3.0 (si encuentro mi otro carrito de unidad)
  • eSATA (si encuentro / compro un cable)
  • SATA (Si encuentro / compro un cable, me encantan las unidades de CD portátiles)

¿Hay alguna manera de ejecutar esta copia de la unidad que demora menos de 96 horas? Estoy abierto a usar herramientas que no sean dd .

Necesito clonar las siguientes particiones (incluidos los UUID)

  • Fat32 EFI Partition (*)
  • Partición NTFS de Windows (*)
  • Partición HFS + OSX
  • EXT4 Partición de Ubuntu (*)
  • Partición de intercambio (*)

* Compatible con Clonezilla

He probado Clonezilla (y fue MUCHO más rápido), pero no es compatible con la copia inteligente HFS +, que necesito. Tal vez la versión más reciente es compatible con esto?

Cuando hice mi primer clon, hice todas las particiones excepto HFS + y fue muy rápido. (No más de 3 horas en total)

    
pregunta Kaz Wolfe 12.09.2014 - 02:39

9 respuestas

54

En mi experiencia, no creo que haya algo más rápido en la línea de comando como dd . Ajustar el parámetro bs puede aumentar la velocidad, por ejemplo, tengo 2 discos duros que sé que tienen una velocidad de lectura / escritura superior a 100 MB / s, así que hago esto:

dd if=/dev/sda of=/dev/sdb bs=100M

También hay pv (Necesita instalarse primero) que comprueba la velocidad más rápida en ambas unidades y luego continúa con la clonación. Esto debe hacerse, por supuesto, desde la raíz:

pv < /dev/sda > /dev/sdb

Con PV obtuve 156 MB / s

Lo bueno de pv aparte de la velocidad es que muestra el progreso, la velocidad actual, el tiempo desde que comenzó y la ETA. Con respecto a HFS + no lo sabría, estoy tratando de ayudar en la parte de "velocidad". Con pv o un parámetro bs muy optimizado, puede hacer un disco de 4 TB en menos de 7 horas (6 horas y 50 minutos a una velocidad actual de 150 MB / s).

Hice un par de pruebas con los tipos de conexión que estaba usando y otros que tenía disponibles. Estaba usando el Asus Z87 Pro y el Intel DZ68DP. Estos fueron mis resultados, pero primero debemos saber que las velocidades teóricas para muchas velocidades de transferencia (velocidades brutas) son solo eso, teoría . Hacer pruebas reales reveló que están entre el 40% y el 80% de esa velocidad bruta. Estas pruebas pueden cambiar según el dispositivo utilizado, el tipo de conexión, la placa base, el tipo de cable de conexión, el tipo de sistema de archivos y más. Con esto en mente, esto es lo que obtuve (solo probé Velocidad de escritura en el dispositivo, la lectura suele ser más alta):

Connected Device  -  Connection Type  -  Speed (Write Speed)
  USB 2.0                 USB 2.0              25 MB/s
  USB 3.0                 USB 2.0              35 MB/s
  USB 3.0                 USB 3.0              73 MB/s
  eSata                   eSata                80 MB/s
  Sata 2G HDD             Sata 2G              120 MB/s
  Sata 3G HDD             Sata 2G              140 MB/s
  Sata 3G HDD             Sata 3G              190 MB/s
  Sata 2G SDD             Sata 2G              170 MB/s
  Sata 3G SDD             Sata 2G              210 MB/s
  Sata 3G SDD             Sata 3G              550 MB/s 
    
respondido por el Luis Alvarado 12.09.2014 - 03:27
12

El problema es su tipo de conexión y tamaño de bloque. Para obtener los resultados más rápidos, su tamaño de bloque debe ser la mitad de la velocidad de escritura más baja que recibe normalmente. Esto le dará un margen seguro, pero aún permitirá un gran número; por supuesto, debe tener suficiente memoria RAM para contener los datos también.

Usb 2.0 es de 12 megabits por segundo (Mbps), Usb 2.0 de alta velocidad es de 480 Mbps. Esta es, por supuesto, la velocidad bruta; con 8 bits en un byte y encuadre por encima, la velocidad utilizable en MB / s suele ser un decimal. Entonces, por ejemplo 480 en bruto, se puede utilizar 48MB. Tenga en cuenta que este es el mejor matemático, en el mundo real será un poco más bajo. Para las conexiones de alta velocidad usb 2.0, debe esperar una velocidad de escritura máxima de entre 30 y 35 MB, siempre que el dispositivo de almacenamiento real pueda igualar o superar las velocidades de conexión.

    
respondido por el Fellow 12.09.2014 - 06:17
11

Para copiar una partición al por mayor, use cat en lugar de dd . Ejecuté benchmarks hace un tiempo, copiar un archivo grande en lugar de una partición, entre dos discos (en el mismo disco, los tiempos relativos son diferentes):

dd bs=64M    51.3
dd bs=1M     41.8
dd bs=4k     48.5
dd bs=512    48.9
cat          41.7
cp           45.3

La conclusión de este punto de referencia es que la elección del tamaño de bloque para dd importa (pero no tanto), y cat encuentra automáticamente la mejor manera de hacer una copia rápida: dd solo puede ralentizarte . Con un tamaño de bloque pequeño, dd desperdicia tiempo perdiendo lecturas y escrituras pequeñas. Con un gran tamaño de bloque, un disco permanece inactivo mientras que el otro está leyendo o escribiendo. La velocidad óptima se logra cuando un disco lee mientras el otro disco escribe.

Para copiar una partición, puede ser más rápido copiar los archivos con cp -a . Esto depende de la cantidad de archivos que hay y de la cantidad de espacio del sistema de archivos. Copiar archivos tiene una sobrecarga que es más o menos proporcional a la cantidad de archivos, pero, por otro lado, copiar espacio libre es una pérdida de tiempo.

La velocidad máxima de datos para USB2 es un poco menor de 50 MB / s, lo que equivale a 6-7 horas para transferir 1TB. Esto supone un disco duro lo suficientemente rápido como para saturar el bus USB; Creo que las unidades más rápidas de 7200 rpm pueden hacerlo, pero 5900 rpm podrían no ser tan rápidas (¿tal vez son para escrituras lineales?).

Si cualquiera de los discos está en uso en paralelo, esto puede ralentizar la copia considerablemente ya que las cabezas de disco tendrán que moverse.

    
respondido por el Gilles 12.09.2014 - 12:46
5

Estoy de acuerdo en que la velocidad bruta de un comando dd ('pv') o 'cat' bien ajustado es difícil de superar, pero si hay algún problema con la copia (sector defectuoso, falla de energía, error de usuario, etc. ) entonces tienes que empezar de nuevo.

Me gustaría sugerir ddrescue - una herramienta FOSS que tiene toda la velocidad de dd, pero funcionará alrededor de errores de disco, y reanudar en un punto posterior si hay una falla.

    
respondido por el dan_linder 17.09.2014 - 03:21
2

Moveré Windows 7 de un HDD a SSD y encontré esto y algunas otras respuestas ... Algo que aprendí que podría ayudar a otros. En mi caso, el disco de origen es más grande, de lo contrario habría trabajado en / dev / sda - & gt; / dev / sdb device level.

Win7 y sus 3 particiones ... Usé Xbuntu 14.04 live cd en un usb. Apareció el DVD de la computadora ganadora y colocó el SSD en su lugar. Partclone instalado e intentado esto:

partclone.ntfs -b -N -s /dev/sda3 -o /dev/sdb3

Partclone vomitó en los ntfs que necesitan ejecutar chkdisk en Windows, por lo que una solución rápida consiguió que partclone fuera feliz:

ntfsfix -b /dev/sda3
ntfsfix -d /dev/sda3

Todos los comandos se ejecutan como root. La interfaz de usuario ncurses de Partclone (la opción -N) dijo que la transferencia fue de 7GB / min y terminó en 5GB / min, lo que equivale a 83MB / seg. La gran parte es que partclone no copia el espacio no utilizado, por lo que hizo que el clon fuera notablemente rápido.

Gotitas adicionales potenciales:

  • si la unidad a la que está transfiriendo se utilizó anteriormente, podría tener restos de un GPT. Las instalaciones de fábrica de Windows 7 suelen ser tablas de partición msdos / mbr. Tendrá que eliminar los fragmentos GPT de la unidad de destino. Este Unix & amp; El QA de Linux me ayudó con esto. Debe usar gdisk en el dispositivo, use x luego z y sí para borrar los datos de GPT y asegúrese de mantener el MBR.

  • Y no olvide que si no hace un dd de nivel de dispositivo, tendrá que copiar el MBR usando
    dd if=/dev/sdb of=/dev/sda bs=446 count=1
    donde sdb es fuente o unidad anterior y sda es el destino o la unidad nueva ( source )

respondido por el Chris K 21.12.2014 - 09:37
1

Hace poco que creé una imagen de una partición de 100 GB (HDD) y la escribí en el nuevo disco SSD.

Aquí hay un consejo que puede acelerar drásticamente el proceso:)

Divide el archivo en partes más pequeñas (cuanto más grande es el archivo, más lento funciona)

sudo dd if=/dev/sda3 conv=sync,noerror bs=2M | split -a 3 -d -b 1G - /maindisk.img

Durante el proceso, puede verificar la velocidad usando (en un terminal separado)

pgrep -l '^dd$' #to find PROCESSID
kill -USR1 PROCESSID #to check the speed

Luego, cuando tenga un directorio lleno de archivos de resultados (maindisk.img000, maindisk.img001, etc.) usar

sudo cat maindisk.img* | sudo dd of=/dev/sda1

para "grabar" la imagen en la nueva partición de SSD (la parición debe ser del mismo tamaño que la anterior)

Para mí funcionó un loooot más rápido de lo normal (sin dividir). La velocidad promedio de creación de la imagen fue ~ 13MB / s. Cuando uso la forma 'normal' comienza con ~ 15MB / sy luego disminuye a 1MB / s.

    
respondido por el matowc1991 01.12.2014 - 15:33
0

Para cualquiera que encuentre este hilo, es mucho más fácil y rápido simplemente usar una herramienta diseñada para la recuperación de datos como ddrescue Primero intenta rescatar las partes buenas en caso de errores de lectura. También puede interrumpir el rescate en cualquier momento y reanudarlo más tarde en el mismo punto.

Ejecutarlo dos veces:

Primera ronda, copie todos los bloques sin error de lectura y registre los errores en rescue.log.

sudo ddrescue -f -n /dev/sdX /dev/sdY rescue.log

Segunda ronda, copia solo los bloques defectuosos y prueba 3 veces para leer de la fuente antes de darte por vencido.

sudo ddrescue -d -f -r3 /dev/sdX /dev/sdY rescue.log

Ahora puede montar la nueva unidad y verificar si el sistema de archivos está dañado.

Más información:
enlace

    
respondido por el goetzc 20.02.2016 - 20:05
0

Id recomienda la entrada / lectura - archivo / disco para estar en SATA para aumentar las velocidades de lectura. La velocidad alta de USB 2.0 también es buena ya que obtengo velocidades promedio de 33816 kb / s con ddrescue en comparación con cuando la configuración era USB 2.0 a SATA en 2014 kb / s

    
respondido por el NateNjugush 24.10.2016 - 11:07
0

Usa un tamaño de bloque diferente. Es la cantidad de datos que dd lee a la vez. Si lee muy poco, se gasta una mayor cantidad de tiempo en la lógica del programa y, si se lee demasiado, se dedicará mucho tiempo a mover los datos de gran tamaño.

Para medir la velocidad en diferentes tamaños de bloques, use la siguiente secuencia de comandos bash :

  • estableció $dev en el dispositivo
  • corrige cbtotal para que sea al menos 5 veces la velocidad de lectura esperada
    (set -o errexit; skip=0; cbtotal=$((120*1024**2)); bs=256;
    for power in 'seq 10'; do
      bs=$((bs*2)); skip=$((skip/2)); count=$((cbtotal/bs));
      if [ "$count" -lt 1 ]; then break; fi;
      echo $bs;
      dd if=$dev of=/dev/null skip=$skip bs=$bs count=$count
      skip=$((skip+count))
    done)

El resultado puede estar sesgado hacia un tamaño mayor debido a la lectura del disco por delante; por eso es importante establecer cbtotal lo suficientemente grande.

    
respondido por el ivan_pozdeev 29.06.2017 - 22:13

Lea otras preguntas en las etiquetas