Primero asegúrese de que el volumen lógico no esté montado. Si es así y desea hacer una "copia en caliente", cree primero una instantánea y úsela en su lugar:
lvcreate --snapshot --name transfer_snap --size 1G
Tengo que transferir una gran cantidad de datos (7 TB) entre dos servidores conectados de 1 Gbit, por lo que necesitaba la forma más rápida posible de hacerlo.
¿Deberías usar SSH?
El uso de ssh está fuera de discusión, no por su encriptación (si tiene una CPU con soporte AES-NI, no duele tanto) sino por sus buffers de red. Esos no están escalando bien. Hay una versión de Ssh parcheada que soluciona este problema, pero como no hay paquetes precompilados, no es muy conveniente.
Usando Compresión
Al transferir imágenes de disco sin formato, siempre es recomendable usar compresión. Pero no desea que la compresión se convierta en un cuello de botella. La mayoría de las herramientas de compresión de Unix, como gzip, son de un solo subproceso, por lo que si la compresión satura una CPU, será un cuello de botella. Por esa razón, siempre uso pigz, una variante de gzip que usa todos los núcleos de CPU para la compresión. Y esto es necesario si desea subir y superar las velocidades de GBit.
Usando cifrado
Como se dijo antes, ssh es lento. Si tiene una CPU AES-NI, esto no debería ser un cuello de botella. Entonces, en lugar de usar ssh, podemos usar openssl directamente.
Velocidades
Para darle una idea del impacto de la velocidad de los componentes, aquí están mis resultados. Esas son las velocidades de transferencia entre dos sistemas de producción que leen y escriben en la memoria. ¡Sus resultados reales dependen de la velocidad de la red, la velocidad del disco duro y la velocidad de la CPU de origen! Estoy haciendo esto para mostrar que al menos no hay una gran caída en el rendimiento.
Simple nc dd:
5033164800 bytes (5.0 GB, 4.7 GiB) copied, 47.3576 s, 106 MB/s
+pigz compression level 1 (speed gain depends on actual data):
network traffic: 2.52GiB
5033164800 bytes (5.0 GB, 4.7 GiB) copied, 38.8045 s, 130 MB/s
+pigz compression level 5:
network traffic: 2.43GiB
5033164800 bytes (5.0 GB, 4.7 GiB) copied, 44.4623 s, 113 MB/s
+compression level 1 + openssl encryption:
network traffic: 2.52GiB
5033164800 bytes (5.0 GB, 4.7 GiB) copied, 43.1163 s, 117 MB/s
Conclusión: el uso de la compresión proporciona una aceleración notable, ya que reduce mucho el tamaño de los datos. Esto es aún más importante si tiene velocidades de red más lentas. Cuando use la compresión, observe el uso de su CPU. si el uso se maximiza, puedes intentarlo sin él. Usar la compresión como solo un pequeño impacto en los sistemas AES-NI, en mi opinión solo porque roba entre un 30 y un 40% de CPU de la compresión.
Usando la pantalla
Si está transfiriendo una gran cantidad de datos como yo, no desea que se interrumpa por una desconexión de la red de su cliente ssh, por lo que es mejor comenzar con la pantalla en ambos lados. Esto es solo una nota, no escribiré un tutorial en pantalla aquí.
Permite copiar
Instale algunas dependencias (en origen y destino):
apt install pigz pv netcat-openbsd
luego cree un volumen en el destino con el mismo tamaño que la fuente. Si no está seguro, use lvdisplay en la fuente para obtener el tamaño y crear el objetivo, es decir:
lvcreate -n lvname vgname -L 50G
a continuación, prepare el destino para recibir los datos:
nc -l -p 444 | openssl aes-256-cbc -d -salt -pass pass:asdkjn2hb | pigz -d | dd bs=16M of=/dev/vgname/lvname
y cuando esté listo, comience la transferencia en la Fuente:
pv -r -t -b -p -e /dev/vgname/lvname | pigz -1 | openssl aes-256-cbc -salt -pass pass:asdkjn2hb | nc <destip/host> 444 -q 1
Nota: Si está transfiriendo los datos localmente o no le importa el cifrado, simplemente quite la parte Openssl de ambos lados. Si le importa, asdkjn2hb es la clave de cifrado, debe cambiarla.