¿Cómo configurar la clonación de disco con dd, netcat y ssh tunnel?

Me gustaría copiar cosas a granel (reimage usando el disco dd) con netcat del host A a B a través del canal cifrado ssh en Linux.

¿Qué comandos debo escribir en ambos extremos?

Copiar desde el origen al destino donde el destino tiene sshd ejecutándose:

• dd if=/dev/sda | gzip | ssh root@target 'gzip -d | dd of=/dev/sda'

Copiando desde el origen al destino a través de sshd_host cuando el destino no ejecuta sshd.

• Objetivo: nc -l -p 62222 | dd of=/dev/sda bs=$((16 * 1024 * 1024))
• Fuente: ssh -L 62222:target:62222 sshd_host &

• Fuente: dd if=/dev/sda | nc -w 3 localhost 62222

  dd - if = es el origen, of = es el destino, bs = es el tamaño del bloque. Diferentes tamaños de bloque pueden mejorar el rendimiento. 16 es usualmente un punto de partida bastante razonable. También puede usar count = para indicar cuántos bloques copiar.

  nc - -p indica el puerto a usar para los servicios. -l se usa para iniciar un servicio. -w configura el tiempo de espera de datos en la canalización antes de salir.

  ssh - -L configura el túnel en el host remoto. El formato del argumento es, local_port:target_host:target_port. Su programa local (nc) se conecta a local_port, esta conexión se tunela y se conecta a target_port en target_host.

Las opciones definidas son solo las utilizadas para esto. Mire las páginas del manual para más detalles.

Algunas notas

1. Si está haciendo esto sobre cualquier cosa que no sea una LAN, le sugiero que comprima el flujo de datos con gzip o compress. Bzip2 también funcionaría, pero lleva un poco más de tiempo de CPU. El primero tiene un ejemplo de ese uso.
2. Es mejor si la partición de origen no está montada o si está montada de solo lectura. De lo contrario, deberá fsck la imagen de destino.
3. A menos que una de las máquinas tenga netcat pero no ssh, netcat no es realmente necesario aquí. Ese caso se vería así:

source machine dd -> nc -> ssh -> ssh tunnel -> sshd server -> nc on target -> dd

4. dd funciona mejor si el origen y los destinos son del mismo tamaño. Si no, el objetivo debe ser el más grande de los 2.
5. Si está utilizando ext2 / 3 o xfs, el volcado (o xfsdump) y la restauración pueden ser una mejor opción. No manejará el sector de arranque, pero funciona cuando el destino y la fuente son de diferentes tamaños.

Si quieres usar netcat sin ssh. Supongo que es la forma más rápida y no la segura, puede copiar y restaurar todo el disco de esta manera:
en la computadora A con IP 192.168.0.1

cat /dev/hdb | nc -p 9000

nc -l 192.168.0.1 9000 > /dev/hdb

Recuerde que según man nc la opción -l es:

  -l Se usa para especificar que nc debería escuchar una conexión entrante en lugar de iniciar una conexión a un host remoto. Es un error utilizar esta opción junto con las opciones -p, -s o -z.

netcat no es necesario.

en la ejecución de la máquina src:

dd if=/dev/sdX bs=1M | ssh root@dstMachine " dd of=/dev/sdY bs=1M"

Supongo que ninguna de las particiones en SDX y SDY están montadas. puedes arrancar ambas cajas con knoppix u otra distribución en vivo similar.

dd: toma datos de if [si no se proporciona, los toma de stdin], envía datos a de [si no se proporciona, los datos se envían a stdout]. bs - tamaño de bloque ... acelerará las cosas.

ssh: ejecuta el comando proporcionado entre comillas en la caja remota, todos los datos bombeados a stdin de ssh se tunelizarán a la máquina remota y se proporcionarán como stdin al comando ejecutado allí.

El host A es el de la imagen, el host B es el que se almacenará la imagen:

root@A# dd if=/dev/sda | ssh root@B "dd of=/some/file"

Restaurar en el disco simplemente intercambiaría esos dos.

La copia básica con netcat se describe aquí .

Si necesita involucrar a SSH en esto, puede usar el reenvío de puertos sobre eso,

-R [bind_address:]port:host:hostport

Pero, en general, podría hacer la transferencia SSH en primer lugar (sin netcat).

Mientras los sistemas de archivos estén desmontados, dd funciona bien.

(from server1) dd if=/dev/sda bs=32k | ssh <server2> dd of=/dev/sda bs=32k

Necesitará la configuración de autenticación de la clave de host con anticipación o, de lo contrario, la solicitud de contraseña hará que la copia falle.

Hacer esto en un volumen montado producirá malos resultados.

O bien, puede usar clonezilla y "montar" su almacenamiento remoto a través de sshfs.

Intenté una combinación de las opciones proporcionadas anteriormente y comparto los resultados con usted. más rápido a más lento utilizando combinaciones de tamaño de bloque dd, algoritmo de compresión gzip y gzip.

Como puede ver, gzip solo me dio una mejora al usar el algoritmo rápido junto con un tamaño de bloque de 1M.

time dd bs=1M if=/dev/HypGroup00/stage-snapshot  | gzip --fast | ssh hyp5 'gzip -d | dd bs=1M of=/dev/HypGroup00/stage'
12884901888 bytes (13 GB) copied, 326.045 s, 39.5 MB/s

time dd if=/dev/HypGroup00/stage-snapshot  | gzip --fast | ssh hyp5 'gzip -d | dd of=/dev/HypGroup00/stage'
12884901888 bytes (13 GB) copied, 370.158 s, 34.8 MB/s

time dd if=/dev/HypGroup00/stage-snapshot  | ssh hyp5 dd of=/dev/HypGroup00/stage
12884901888 bytes (13 GB) copied, 370.274 s, 34.8 MB/s

time dd bs=1M if=/dev/HypGroup00/stage-snapshot  | ssh hyp5 dd bs=1M of=/dev/HypGroup00/stage
12884901888 bytes (13 GB) copied, 372.906 s, 34.6 MB/s

time dd bs=1M if=/dev/HypGroup00/stage-snapshot  | gzip | ssh hyp5 'gzip -d | dd bs=1M of=/dev/HypGroup00/stage'
12884901888 bytes (13 GB) copied, 520.116 s, 24.8 MB/s

Se utilizaron dos servidores rápidos conectados con GigE a través de un conmutador Enterprise GigE utilizando discos locales a través de LVM.

Parece que estás usando un mazo para romper una nuez aquí, o tal vez una mejor analogía es tratar de cortar el césped con unas tijeras :)

Te sugiero que veas algunas de las herramientas disponibles para hacer un trabajo como este, a menos que tengas buenas razones para hacerlo internamente.

Trinity Rescue Kit es un liveCD gratuito que admite unidades de imagen a través de multidifusión, y puede hacer lo que desee (o incluso cualquier otra persona que piense en las mismas líneas), sin tener que recurrir a sistemas de imagen de gran calibre.