Copie archivos grandes de un servidor Linux a otro

Estoy intentando copiar un tgz de 75 gigabytes (instantánea de mysql lvm) de un servidor Linux en nuestro centro de datos de Los Ángeles a otro servidor Linux en nuestro centro de datos de Nueva York a través de un enlace de 10 MB.

Estoy obteniendo aproximadamente 20-30Kb / s con rsync o scp que fluctúa entre 200-300 horas.

Por el momento es un enlace relativamente silencioso ya que el segundo centro de datos aún no está activo y he obtenido excelentes velocidades de transferencias de archivos pequeños.

He seguido diferentes guías de ajuste de TCP que he encontrado a través de Google en vano (tal vez estoy leyendo las guías incorrectas, ¿tengo una buena?).

He visto la sugerencia del túnel tar + netcat, pero entiendo que solo es bueno para MUCHOS archivos pequeños y no te actualiza cuando el archivo termina de transferirse.

Antes de recurrir al envío de un disco duro, ¿alguien tiene alguna buena información?

ACTUALIZACIÓN: Bueno ... puede ser el enlace después de todo :( Ver mis pruebas a continuación ...

Traslados desde NY a LA:

Obteniendo un archivo en blanco.

[nathan@laobnas test]$ dd if=/dev/zero of=FROM_LA_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.412 seconds, 164 MB/s
[nathan@laobnas test]$ scp -C obnas:/obbkup/test/FROM_NY_TEST .
FROM_NY_TEST                                    3%  146MB   9.4MB/s   07:52 ETA

Obteniendo la instantánea tarball.

[nathan@obnas db_backup]$ ls -la db_dump.08120922.tar.gz
-rw-r--r-- 1 root root 30428904033 Aug 12 22:42 db_dump.08120922.tar.gz

[nathan@laobnas test]$ scp -C obnas:/obbkup/db_backup/db_dump.08120922.tar.gz .
db_dump.08120922.tar.gz            0%   56MB 574.3KB/s 14:20:40 ET

Traslados de LA a NY:

Obteniendo un archivo en blanco.

[nathan@obnas test]$ dd if=/dev/zero of=FROM_NY_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.2501 seconds, 165 MB/s
[nathan@obnas test]$ scp -C laobnas:/obbkup/test/FROM_LA_TEST .
FROM_LA_TEST                                    0% 6008KB 497.1KB/s 2:37:22 ETA

Obteniendo la instantánea tarball.

[nathan@laobnas db_backup]$ ls -la db_dump_08120901.tar.gz
-rw-r--r-- 1 root root 31090827509 Aug 12 21:21 db_dump_08120901.tar.gz

[nathan@obnas test]$ scp -C laobnas:/obbkup/db_backup/db_dump_08120901.tar.gz .
db_dump_08120901.tar.gz                0%  324KB  26.8KB/s 314:11:38 ETA

Supongo que hablaré con las personas que administran nuestras instalaciones. El enlace está etiquetado como un enlace MPLS / Ethernet de 10 MB. (encogimiento de hombros)

Sneakernet Alguien?

Suponiendo que se trata de una copia única, no creo que sea posible copiar el archivo en un CD (u otro medio) y pasar la noche en el destino.

Esa podría ser su opción más rápida ya que una transferencia de archivos de ese tamaño, a través de esa conexión, podría no copiarse correctamente ... en cuyo caso puede comenzar de nuevo.

rsync

Mi segunda opción / intento sería rsync ya que detecta transferencias fallidas, transferencias parciales, etc. y puede retomar desde donde se quedó.

rsync --progress file1 file2 user@remotemachine:/destination/directory

La bandera --progress te dará algunos comentarios en lugar de solo quedarte allí sentado y dejarte dudar de ti mismo. :-)

Vuze (torrente de bits)

La tercera opción probablemente sería intentar usar Vuze como un servidor torrent y luego hacer que su ubicación remota use un cliente bitorrent estándar para descargarlo. Sé de otros que han hecho esto, pero ya sabes ... para cuando lo pusieron todo en marcha, etc. Podría haber pasado por alto los datos ...

Depende de tu situación, supongo.

¡Buena suerte!

ACTUALIZAR:

Sabes, pensé un poco más en tu problema. ¿Por qué el archivo tiene que ser un gran tarball enorme? Tar es perfectamente capaz de dividir archivos grandes en archivos más pequeños (para abarcar medios, por ejemplo), entonces, ¿por qué no dividir ese enorme tarball en piezas más manejables y luego transferir las piezas?

Lo hice en el pasado, con un archivo tbz2 de 60GB. Ya no tengo el script, pero debería ser fácil reescribirlo.

Primero, divida su archivo en partes de ~ 2GB:

split --bytes=2000000000 your_file.tgz

Para cada pieza, calcule un hash MD5 (esto es para verificar la integridad) y guárdelo en algún lugar, luego comience a copiar las piezas y su md5 en el sitio remoto con la herramienta que elija (yo: netcat-tar-pipe en una pantalla sesión).

Después de un tiempo, verifique con el md5 si sus piezas están bien, luego:

cat your_file* > your_remote_file.tgz

Si también ha hecho un MD5 del archivo original, verifíquelo también. Si está bien, puede descomprimir su archivo, todo debería estar bien.

(Si encuentro el tiempo, volveré a escribir el guión)

Normalmente soy un gran defensor de rsync, pero cuando transfiero un solo archivo por primera vez, no parece tener mucho sentido. Sin embargo, si volviese a transferir el archivo con solo pequeñas diferencias, rsync sería el claro ganador. Si elige usar rsync de todos modos, le recomiendo ejecutar un extremo en --daemonmodo para eliminar el túnel ssh que mata el rendimiento. La página del manual describe este modo completamente.

¿Mi recomendación? FTP o HTTP con servidores y clientes que admiten reanudar descargas interrumpidas. Ambos protocolos son rápidos y livianos, evitando la penalización del túnel ssh. Apache + wget estaría gritando rápido.

El truco de la tubería netcat también funcionaría bien. Tar no es necesario al transferir un solo archivo grande. Y la razón por la que no te avisa cuando está hecho es porque no se lo dijiste. Agregue una -q0bandera en el lado del servidor y se comportará exactamente como esperaría.

servidor $ nc -l -p 5000> outfile.tgz

cliente $ nc -q0 server.example.com 5000 <infile.tgz

La desventaja del enfoque de netcat es que no le permitirá reanudar si su transferencia muere 74GB en ...

Dale una oportunidad a netcat (a veces llamado nc). Lo siguiente funciona en un directorio, pero debería ser lo suficientemente fácil de modificar solo para hacer frente a un archivo.

En el cuadro de destino:

netcat -l -p 2342 | tar -C /target/dir -xzf -

En el cuadro de origen:

tar czf * | netcat target_box 2342

Puede intentar eliminar la opción 'z' en ambos comandos tar para obtener un poco más de velocidad, ya que el archivo ya está comprimido.

SCP y Rsync predeterminados (que usan SCP) son muy lentos para archivos grandes. Supongo que buscaría usar un protocolo con una sobrecarga más baja. ¿Has intentado usar un cifrado de cifrado más simple o no lo has hecho? Intente buscar en la --rshopción rsync para cambiar el método de transferencia.

¿Por qué no FTP o HTTP?

Aunque agrega un poco de sobrecarga a la situación, BitTorrent es en realidad una buena solución para transferir archivos grandes. BitTorrent tiene muchas características interesantes, como fragmentar de forma nativa un archivo y suma de comprobación de cada fragmento que se puede retransmitir si está dañado.

Un programa como Azureus [ahora conocido como Vuze] contiene todas las piezas que necesitará para crear, servidor y descargar torrents en una sola aplicación. Ten en cuenta que Azureus no es la solución más magra disponible para BitTorrent y creo que también requiere su GUI; sin embargo, hay muchas herramientas de torrent impulsadas por línea de comandos para Linux.

Bueno, personalmente, 20-30Kb / s parece bastante bajo para un enlace de 10Mb (suponiendo 10Mb y no 10MB).

Si fuera usted, haría una de dos cosas (suponiendo que el acceso físico no esté disponible):

Cualquiera de los dos, le aconsejo que divida el archivo grande en fragmentos más pequeños, alrededor de 500 MB. En caso de corrupción en tránsito.

Cuando tenga los fragmentos más pequeños, use rsync nuevamente, o personalmente prefiero usar una sesión privada segura de ftp, y luego CRC los archivos al finalizar.

Algunas preguntas pueden ayudar en las discusiones: ¿cuán importantes son los datos que se transferirán? ¿Es esto para recuperación ante desastres, respaldo en caliente, almacenamiento fuera de línea o qué? ¿Tiene la intención de hacer una copia de seguridad de la base de datos mientras está activa o inactiva? ¿Qué pasa con la configuración de una base de datos en el sistema remoto y mantenerlos sincronizados mediante la agrupación o la actualización a través de registros de cambios (no estoy totalmente versado en las capacidades de un sistema de base de datos MySql). Esto podría ayudar a reducir la cantidad de datos que deben transferirse a través del enlace.

bbcp fragmentará el archivo por usted y lo copiará con múltiples transmisiones.

Respuesta tardía para googlers:

Al transferir grandes conjuntos de datos, rsync se puede usar para comparar el origen y el destino, y luego escribir un archivo por lotes en medios extraíbles locales utilizando el indicador --only-write-batch. Luego, envía los medios locales a la ubicación remota, lo conecta y ejecuta rsync nuevamente, usando --read-batch para incorporar los cambios en el conjunto de datos remoto.

Si los archivos de origen cambian durante el transporte físico, o si el medio de transporte se llena, puede seguir repitiendo el --only-write-batch | barco | --ciclo de lectura-lote hasta que el destino esté atrapado.

(Ref: fui uno de los autores de esta característica en rsync; para obtener más información y casos de uso, consulte esta discusión sobre la implementación del prototipo: https://lists.samba.org/archive/rsync/2005-March/011964 .html )