Clonado de Discos y Particiones por Red con Terminal de Comandos GNU-linux .
FUENTE: http://www.vicente-navarro.com/blog/2008/12/07/usando-ntfsclone-y-dd-para-clonado-por-red-con-netcat/
Para empezar es bueno aclarar que, SSH es mucho más seguro y recomendable, pero si tienes que clonar un disco de 500 GB, tenemos que tener en cuenta el coste en tiempo procesador de encriptar y desencriptar los datos en ambos extremos. Si trabajamos sobre una red controlada, creo que podemos considerar razonable el usar el netcat.
A mí me gusta netcat para este propósito. netcat se autodenomina “la navaja suiza de TCP/IP”, y es verdad que lo es. De las varias implementaciones existentes, si usamos la original (cuyo autor es *Hobbit*) y leemos su README (en Debian/Ubuntu en /usr/share/doc/netcat-traditional/README.gz), veremos unos pocos ejemplos de sus posibilidades, suficientes para sorprendernos de la enorme versatilidad de esta herramienta.
En su forma más sencilla de uso, a mí me gusta ver a netcat como una tubería (pipe) que se extiende a otra máquina de la red. Por ejemplo, si hacemos:
FUENTE: http://www.vicente-navarro.com/blog/2008/12/07/usando-ntfsclone-y-dd-para-clonado-por-red-con-netcat/
Para empezar es bueno aclarar que, SSH es mucho más seguro y recomendable, pero si tienes que clonar un disco de 500 GB, tenemos que tener en cuenta el coste en tiempo procesador de encriptar y desencriptar los datos en ambos extremos. Si trabajamos sobre una red controlada, creo que podemos considerar razonable el usar el netcat.
A mí me gusta netcat para este propósito. netcat se autodenomina “la navaja suiza de TCP/IP”, y es verdad que lo es. De las varias implementaciones existentes, si usamos la original (cuyo autor es *Hobbit*) y leemos su README (en Debian/Ubuntu en /usr/share/doc/netcat-traditional/README.gz), veremos unos pocos ejemplos de sus posibilidades, suficientes para sorprendernos de la enorme versatilidad de esta herramienta.
En su forma más sencilla de uso, a mí me gusta ver a netcat como una tubería (pipe) que se extiende a otra máquina de la red. Por ejemplo, si hacemos:
sistema1 $ echo "Hola Mundo" | nc -q 0 -lp 2222
sistema2 $ nc sistema2 2222 | cat
Hola Mundo
es como si hiciéramos:
echo "Hola Mundo" | envia_por_red_a_sistema2 | cat
Para clonar una particion esta el comando dd que no dice absolutamente nada de cuanto lleva leído o escrito, hasta que finaliza. Como clonar un disco de muchos Gigabytes puede ser una tarea bastante larga, puede ser muy útil introducir entre los comandos de la tubería un pv para saber por dónde va la copia. El pv es un interesante comando que, usado en una tubería (pipe), copia directamente la información de la entrada estándar en la salida estándar y además nos informa del volumen de datos que ha movido por la tubería por la salida de error:
sisdest # nc -lp 2222 | pv | gzip -d -c | dd of=/dev/sda
sisorig # dd if=/dev/sda | gzip | pv | nc -q 0 sisdest 2222
En el ejemplo anterior, como hemos puesto el pv entre el gzip y el nc, medimos la tasa de datos comprimidos que enviamos a la red. Si lo comparamos con el informe que nos da el dd al final de su ejecución de datos escritos en el dispositivo (sin comprimir), podremos ver cuánto se han comprimido los datos antes de ser enviados por la red.
sisdest # nc -lp 2222 | pv | gzip -d | dd of=/dev/sda2sisorgi # dd if=/dev/sda2 | gzip | pv | nc -q 0 sisdest 2222
También podríamos poner el pv entre el dd y el gzip para ver qué cantidad de datos sin comprimir, de los que tiene el disco o partición, hemos procesado ya.
Sin embargo, si vamos a hacer esta operación de clonado de discos muy a menudo, tal vez nos interese probar si no nos interesa eliminar el comando gzip de las tubería de ambos sistemas remotos: Si los sistemas de ambos extremos no son capaces de comprimir y descomprimir datos a más velocidad de la que tiene la red, es muy posible que nos interese más enviar los datos por la red sin comprimir:
sisdest # nc -lp 2222 | pv | dd of=/dev/sda2
sisorig # dd if=/dev/sda2 | pv | nc -q 0 sisdest 2222
Por cierto, la diferencia en cantidades es porque dd usa Gigabytes y pv usa Gibibytes:
$ bcHay una forma de obtener estadísticas del trabajo que lleva hecho dd, y que está hasta documentado en la página de man de dd.
52954352640/1000/1000/1000
52.9543526400
52954352640/1024/1024/1024
49.3175840377
En otro terminal (en cada una de las máquinas) podemos hacer un “ps -ef | grep dd” para buscar el PID del proceso y luego, al hacer el kill, en el terminal donde habíamos lanzado el dd, encontraremos, en la salida de error, las estadísticas del trabajo hecho hasta el momento por dd:
sisdest # ps -ef | grep dd
root 23772 23745 5 19:24 pts/1 00:00:01 dd of /dev/hda
sisorig # kill -USR1 23772
sisorig # kill -USR1 23772
sisorig # ps -ef | grep ddroot 34675 24619 28 11:23 pts/1 00:00:05 dd if /dev/hdasisdest # kill -USR1 34675sisdest # kill -USR1 34675
sisdest # nc -lp 2222 | dd of=/dev/hda
340522+0 records in
340522+0 records out
174347264 bytes (174 MB) copied, 21.9449 seconds, 7.9 MB/s
363920+0 records in
363920+0 records out
186327040 bytes (186 MB) copied, 23.4599 seconds, 7.9 MB/s
sisorig # dd if=/dev/hda | nc -q 0 sisdest 2222
242172+0 records in
242172+0 records out
123992064 bytes (124 MB) copied, 17.1812 seconds, 7.2 MB/s
270881+0 records in
270881+0 records out
138691072 bytes (139 MB) copied, 19.0057 seconds, 7.3 MB/s
Para finalizar, comentar que si vamos a usar dd y gzip y vamos a clonar un mismo disco multitud de veces, nos puede interesar mucho llenar todos los espacios vacíos de los sistemas de ficheros del disco con ceros para que el gzip pueda comprimir lo máximo posible. Para ello, tendríamos que hacer en cada partición del disco un “dd if=/dev/zero of=ceros; rm ceros” o un sdelete.
.
