Copiar un LV (Volumen lógico) o un disco a una máquina remota

1. En modo simple

1.1 Ejecutado desde la máquina que tiene el disco a copiar. Hay que tener en cuenta que el usuario debe de tener permiso sobre el directorio donde se va a grabar la imagen

dd if=/dev/midisco | ssh user@targetServer 'dd of=/path/to/target'

1.2 Ejecutado desde la máquina remota al disco a copiar. A veces el "sudo" remoto puede dar problemas, y puede que en aqlgunos casos se pueda obviar

ssh user@targetServer "sudo dd if=/dev/midisco" | dd of=/path/to/target

En mi caso, copiando un disco de 180Gb con 80Gb de datos y el resto vacío, tardó 27 min.

2. Ajustes finos en el comando dd (tweaks)

Según Rod en el año 2015

2.1 Averiguamos el tamaño de bloque del LV, para ello nos vamos al directorio donde está montado (en este caso /opt ) y ejecutamos

stat -fc %s /opt

y nos devuelve 4096

Como norma tenemos que utilizar un múltiplo de la longitud de bloque!

2.2 Si la seguridad del sistema lo permite, se puede seleccionar una encriptación ssh poco segura pero rápida como arcfour si lo permite tu versión de Openssh, o segun(/dev/blog) aes128-ctr pueden acelerar la conexión. Para ver los cifrados que se pueden realizar ejecutamos

ssh -Q cipher localhost 

y en mi caso devuelve

3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

vemos que aes126-ctr si está y lo usamos

ssh -c aes128-ctr user@targetServer "sudo dd if=/dev/midisco bs=4M" | dd of=/path/to/target

Pero no se ha visto mejoría!

Lo que si que está claro es que el algoritmo de cifrado 3des-cbc enlentece mucho y no se aconseja usar. Por otra parte  según tdg5 , a él le va mejor un bloque de 128K=131072 (bs=131072) le va un poco mas rápido. Hechas las pruebas, tal vez aumente solo el 1% el rendimiento.

3. ¿Comprimimos?

Si comprimimos, ahorramos disco... pero tardamos 2 horas! o sea se multiplica por 5 el tiempo de la copia. De todas formas se puede intentar.

ssh user@targetServer "sudo dd if=/dev/midisco | gzip -1 -" | dd of=/path/to/target

Hay que tener en cuenta que estoy haciendo una copia de seguridad de Alfresco, y parece ser que los ficheros ya vienen comprimidos, por tanto, poco ganamos con la compresión, excepto para laparte din datos del volumen lógico.

4. Opcion scp. 

OJO: No copia particiones, sino ficheros y/o carpetas

En un blog anterior, queríamos hacer una copia de seguidad de Alfresco y teniendo en cuenta que :
1. Estamos en la máquina local donde queremos copiar la carpeta remota
2. Cuidado econ el scp ya que primero hay que indicar el destino y despues el origen
usábamos:

scp -rp /home/backups.destino/ usuarioRemoto@IP:/opt/alfresco-4.2.f/alf_data

donde las opciones:
  r indica copia recursiva de ficheros y subcarpetas
  p para preservar fechas y autorías de ficheros.

también podemos indicar si queremos compresión la opción C. Pero como hemos dicho en este caso,  poco se gana ya que los ficheros de Alfresco vienen con una tasa de compresión alta.

5. Opción rsync

rsync permite la transferencia rápida de ficheros de forma incremental según el atareao.

Para evitar problemas de borrado, voy a excluir la opción--delete.

Verificar que rsync está instalado tanto en la máquina local como en la remota.

De todas maneras, algunos comandos han tenido que modificarse.  Para ello nos situamos en una carpeta local y después ejecutamos la copia. La primera vez tarda bastante, pero después hace una copia incremental.

cd /mybackup-folder  # Nos situamos en la carpeta local donde descargar el backup

rsync -avzh usuarioRemoto@IP:/opt/alfresco-4.2.f/alf_data .   # Ejecutamos la copia

Para hacer la primera copia se ha tardado 1h-20 min