Cómo copiar una gran cantidad de archivos rápidamente entre dos servidores

Necesito transferir una gran cantidad de mp3 entre dos servicios (Ubuntu). Por enorme quiero decir alrededor de un millón de archivos que son en promedio 300K. Lo intenté scppero me habría llevado alrededor de una semana. (aproximadamente 500 KB / s) Si transfiero un solo archivo por HTTP, obtengo 9-10 MB / s, pero no sé cómo transferirlos todos.

¿Hay alguna manera de transferirlos todos rápidamente?

Yo recomendaría alquitrán. Cuando los árboles de archivos ya son similares, rsync funciona muy bien. Sin embargo, dado que rsync realizará múltiples pases de análisis en cada archivo y luego copiará los cambios, es mucho más lento que tar para la copia inicial. Este comando probablemente hará lo que quieras. Copiará los archivos entre las máquinas, así como preservará tanto los permisos como la propiedad de usuarios / grupos.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Según el comentario de Mackintosh a continuación, este es el comando que usaría para rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Disco duro externo y entrega por mensajería el mismo día.

Yo usaría rsync.

Si los ha exportado a través de HTTP con listas de directorios disponibles, también puede usar wget y el argumento --mirror.

Ya está viendo que HTTP es más rápido que SCP porque SCP está encriptando todo (y, por lo tanto, el cuello de botella en la CPU). HTTP y rsync se moverán más rápido porque no están encriptados.

Aquí hay algunos documentos sobre cómo configurar rsync en Ubuntu: https://help.ubuntu.com/community/rsync

Esos documentos hablan sobre tunelizar rsync a través de SSH, pero si solo está moviendo datos en una LAN privada, no necesita SSH. (Supongo que está en una LAN privada. Si obtiene 9-10MB / seg por Internet, ¡quiero saber qué tipo de conexiones tiene!)

Aquí hay algunos otros documentos muy básicos que le permitirán configurar un servidor rsync relativamente inseguro (sin dependencia de SSH): http://transamrit.net/docs/rsync/

Sin mucha discusión, use netcat, navaja suiza de red. Sin sobrecarga de protocolo, está copiando directamente al socket de red. Ejemplo

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

Con muchos archivos si va con rsync, trataría de obtener la versión 3 o superior en ambos extremos . La razón es que una versión menor enumerará cada archivo antes de que comience la transferencia. La nueva característica se llama recursividad incremental .

Ahora se usa un nuevo algoritmo de recursividad incremental cuando rsync está hablando con otra versión 3.x. Esto inicia la transferencia más rápidamente (antes de que se hayan encontrado todos los archivos) y requiere mucha menos memoria. Consulte la opción --recursive en la página de manual para conocer algunas restricciones.

rsync, como otros ya lo han recomendado. Si la sobrecarga de la CPU del cifrado es un cuello de botella, use otro algoritmo menos intensivo de la CPU, como blowfish. Por ejemplo, algo como

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

Al mover 80 TB de datos (millones de archivos pequeños) ayer, el cambio de rsynca tar resultó ser mucho más rápido , ya que dejamos de intentarlo

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

y cambió a su tarlugar ...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

Dado que estos servidores están en la misma LAN, el destino está montado en NFS en el sistema de origen, que está haciendo el empuje. No lo hagas aún más rápido, decidimos no preservar los atimearchivos:

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

El siguiente gráfico muestra la diferencia que hizo el cambio de rsync a tar. Fue idea de mi jefe y mi colega lo ejecutó e hizo la gran reseña en su blog . Simplemente me gustan las fotos bonitas . :)

Al copiar una gran cantidad de archivos, descubrí que las herramientas como tar y rsync son más ineficientes de lo que deberían ser debido a la sobrecarga de abrir y cerrar muchos archivos. Escribí una herramienta de código abierto llamada fast-archiver que es más rápida que tar para estos escenarios: https://github.com/replicon/fast-archiver ; funciona más rápido al realizar múltiples operaciones concurrentes de archivos.

Aquí hay un ejemplo de archivador rápido versus tar en una copia de seguridad de más de dos millones de archivos; el archivador rápido tarda 27 minutos en archivarse, mientras que el tar tarda 1 hora 23 minutos.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Para transferir archivos entre servidores, puede usar el archivador rápido con ssh, como este:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

También uso el netcatmétodo tar through , excepto que prefiero usar socat, mucha más potencia para optimizar su situación, por ejemplo, ajustando mss. (Además, ríete si quieres, pero encuentro socatargumentos más fáciles de recordar porque son consistentes). Entonces, para mí, esto es muy común últimamente, ya que he estado moviendo cosas a nuevos servidores:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Los alias son opcionales.

Otra alternativa es Unison . Podría ser un poco más eficiente que Rsync en este caso, y es algo más fácil configurar un oyente.

Parece que puede haber un par de errores tipográficos en la respuesta superior. Esto puede funcionar mejor:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'

• Sistema de archivos de red (NFS) y luego cópielos con lo que quiera, por ejemplo, Midnight Commander (mc), Nautilus (de gnome). He usado NFS v3 con buenos resultados.
• Samba (CIFS) y luego copie los archivos con lo que quiera, pero no tengo idea de cuán eficiente es.
• HTTP con lo wget --mirrorque Evan Anderson ha sugerido o cualquier otro cliente http. Tenga cuidado de no tener enlaces simbólicos desagradables o archivos de índice engañosos. Si todo lo que tienes es MP3, debes estar seguro.
• rsync . Lo he usado con muy buenos resultados y una de sus buenas características es que puedes interrumpir y reanudar la transferencia más tarde.

He notado que otras personas han recomendado usar netcat . Según mi experiencia con él, puedo decir que es lento en comparación con las otras soluciones.

Gracias a la maravillosa respuesta de Scott Pack (no sabía cómo hacer esto con ssh antes), puedo ofrecer esta mejora (si bashes su shell). Esto agregará compresión paralela, un indicador de progreso y comprobará la integridad en el enlace de red:

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pves un buen programa visor de progreso para su canalización y pigzes un programa gzip paralelo que usa tantos subprocesos como su CPU tiene por defecto (creo que hasta 8 máx.). Puede ajustar el nivel de compresión para ajustarse mejor a la relación de la CPU a la red de ancho de banda e intercambiarlo con pxz -9ey pxz -dsi tiene mucha más CPU que el ancho de banda. Solo tiene que verificar que las dos sumas coincidan al finalizar.

Esta opción es útil para grandes cantidades de datos, así como para redes de alta latencia, pero no es muy útil si el enlace es inestable y se cae. En esos casos, rsync es probablemente la mejor opción, ya que puede reanudarse.

Salida de muestra:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

Para dispositivos de bloque:

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

Obviamente, asegúrese de que tengan el mismo tamaño o límite con count =, skip =, seek =, etc.

Cuando copio los sistemas de archivos de esta manera, a menudo primero pongo dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefsa cero la mayor parte del espacio no utilizado, lo que acelera el xfer.

No creo que vaya a hacerlo mejor que scp a menos que instale tarjetas de red más rápidas. Si está haciendo esto a través de Internet, eso no ayudará.

Yo recomendaría usar rsync . Puede que no sea más rápido, pero al menos si falla (o si lo cierra porque está tardando demasiado), puede continuar donde lo dejó la próxima vez.

Si puede conectar las 2 máquinas directamente usando Gigabit Ethernet, probablemente será la más rápida.

Para 100 Mb / s, el rendimiento teórico es de 12.5 MB / s, por lo que a 10 MB / s lo está haciendo bastante bien.

También haría eco de la sugerencia de hacer rsync, probablemente a través de ssh. Algo como:

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

A 100 Mb / s, sus CPU deberían poder manejar el cifrado / descifrado sin afectar significativamente la velocidad de datos. Y si interrumpe el flujo de datos, debería poder reanudar desde donde lo dejó. Cuidado, con "millones" de archivos, el inicio tardará un tiempo antes de que realmente transfiera algo.

Me he encontrado con esto, excepto que estaba transfiriendo registros de Oracle.

Aquí está el desglose

• scp

  inefficient and encrypted (encrypted = slower than unencrypted 
  depending on the link and your processor) 
  

• rsync

  efficient but typically encrypted (though not necessarily)
  

• FTP / HTTP

  both seem to be efficient, and both are plaintext. 
  

Utilicé FTP con gran éxito (donde un gran éxito es equivalente a ~ 700Mb / s en una red de Gb). Si está obteniendo 10 MB (que es igual a 80 Mb / s), probablemente algo esté mal.

¿Qué nos puede decir sobre el origen y el destino de los datos? ¿Es de unidad única a unidad única? RAID a USB?

Sé que esta pregunta ya tiene una respuesta, pero si su red va tan lenta en un cable cruzado de Gb / s, es absolutamente necesario solucionar algo.

No mencionó si las dos máquinas están en la misma LAN, o si un canal seguro (es decir, usando SSH) es obligatorio, pero otra herramienta que podría usar es netcat .

Usaría lo siguiente en la máquina receptora:

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

Luego en el lado de envío:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

Tiene las siguientes ventajas:

• Sin sobrecarga de CPU para el cifrado que tiene ssh.
• El gzip -1proporciona una compresión ligera sin saturar una CPU por lo que tiene una buena compensación, dando un poco de compresión, manteniendo el máximo rendimiento. (Probablemente no sea tan ventajoso para los datos MP3, pero no hace daño).
• Si puede dividir los archivos en grupos, puede ejecutar dos o más canalizaciones en paralelo y realmente asegurarse de que está saturando el ancho de banda de su red.

p.ej,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

Notas:

• Independientemente de cómo se transfiera, probablemente ejecute un rsync o unísono después para asegurarme de que tenga todo.
• Puede usar en tarlugar de cpiosi lo prefiere.
• Incluso si terminas usando ssh, me aseguraría de que no esté usando ninguna compresión en sí, y me canalizaré en gzip -1tu lugar para evitar la saturación de la CPU. (O al menos establezca el CompressionLevel en 1.)

Un scp simple con las opciones adecuadas alcanzará fácilmente 9-10 MB / s a ​​través de LAN:

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

Con esas opciones, es probable que el rendimiento sea 4x o 5x más rápido que ninguna opción (predeterminado)

Si tiene un servidor ftp en el lado src, puede usar ncftpget desde el sitio ncftp . Funciona perfecto con archivos pequeños, ya que utiliza alquitrán internamente.

Una comparación muestra esto: mover archivos pequeños de 1.9GB (33926 archivos)

1. Usar scp toma 11m59s
2. Usar rsync toma 7m10s
3. Usar ncftpget toma 1m20s

También puede intentar usar el comando BBCP para hacer su transferencia. Es un ssh paralelo amortiguado que realmente grita. Por lo general, podemos obtener una tasa de línea de 90% + siempre que podamos mantener la tubería alimentada.

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

Normalmente, nos esforzamos mucho para evitar tener que movernos sufriendo. Utilizamos grupos ZFS a los que siempre podemos simplemente "agregar" más espacio en disco. Pero a veces ... solo tienes que mover cosas. Si tenemos un sistema de archivos "en vivo" que puede tardar horas (o días) en copiarse incluso cuando se ejecuta a toda velocidad ... hacemos la rutina de envío zfs de dos pasos:

1. Realice una instantánea de ZFS y transfiérala al nuevo grupo en la nueva máquina. Deja que tome tanto tiempo como sea necesario.
2. Realice una segunda instantánea y envíela como incremental. La instantánea incremental solo incluye el conjunto de cambios (mucho más pequeño) desde el primero, por lo que pasa relativamente rápido.
3. Una vez que se completa la instantánea incremental, puede desactivar el original y pasar a la nueva copia y su "tiempo de inactividad fuera de línea" se mantiene al mínimo.

También enviamos nuestros volcados zfs a través de BBCP ... maximiza la utilización de nuestra red y minimiza los tiempos de transferencia.

BBCP está disponible gratuitamente, puedes buscarlo en Google y es una compilación directa. Simplemente cópielo en su / usr / local / bin en las máquinas src y de destino y funcionará prácticamente.

Supongo que mi respuesta está un poco tarde aquí, pero hice buenas experiencias con el uso de mc (Midnight Commander) en un servidor para conectarme a través de SFTP al otro servidor.

La opción para conectarse a través de FTP se encuentra en los menús "Izquierda" y "Derecha", ingresando la dirección de esta manera:

/#ftp:name@server.xy/

o

/#ftp:name@ip.ad.dr.ess/

Puede navegar y hacer operaciones de archivos casi como en un sistema de archivos local.

Tiene una opción incorporada para hacer la copia en segundo plano, pero prefiero usar el comando de pantalla y separarlo de la pantalla mientras mc está copiando (creo que también se ejecuta más rápido).

A @scottpack respuesta de la opción rSync

Para mostrar el progreso de la carga, use '--progess' como opción después de -avW en el comando como se muestra a continuación.

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Aquí hay un punto de referencia rápido para comparar algunas técnicas,

• La fuente es una CPU de 4 núcleos Intel (R) Xeon (R) E5-1620 @ 3.60GHz con 250 Mbps y unidad SATA
• El destino es una CPU Intel (R) Xeon (R) de 6 núcleos E-2136 @ 3.30GHz con ancho de banda de 1 Gbps y unidad SSD

Número de archivos: 9632, Tamaño total: 814 MiB, Tamaño promedio: 84 KiB

• RSYNC: 1m40.570s
• RSYNC + COMPRESIÓN: 0m26.519s
• TAR + NETCAT: 1m58.763s
• TAR + COMPRESIÓN + NETCAT: 0m28.009s

El comando para tar / netcat fue:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -

rsync o es posible que desee tarlo para que esté todo dentro de un archivo y luego scp. Si carece del espacio en disco, puede canalizar el alquitrán directamente sobre ssh mientras se está haciendo.

Si envía archivos MP3 y otros archivos comprimidos, no obtendrá mucho de ninguna solución que intente comprimir aún más esos archivos. La solución sería algo que pueda crear múltiples conexiones entre ambos servidores y, por lo tanto, ejercer más presión sobre el ancho de banda entre los dos sistemas. Una vez que esto se maximiza, no se puede ganar mucho sin mejorar su hardware. (Tarjetas de red más rápidas entre esos servidores, por ejemplo).

Intenté un par de herramientas para copiar un archivo de 1GB. El resultado es el siguiente: HTTP el más rápido, con wget -c nc segundo en la línea scp más lento, y falló un par de veces. No hay forma de reanudar rsync utiliza ssh como back-end, por lo tanto, el mismo resultado. En conclusión, elegiría http con wget -bqc y le daría algo de tiempo. Espero que esto ayude

Tuve que copiar el disco BackupPC en otra máquina.

Yo usé rsync.

La máquina tenía 256 MB de memoria.

El procedimiento que seguí fue este:

• ejecutado rsyncsin -H(tomó 9 horas)
• cuando terminó rsync, sincronicé el cpooldirectorio y comencé con el pcdirectorio; Corté la transferencia.
• luego reinició rsynccon la -Hmarca, y todos los archivos vinculados en el pcdirectorio se transfirieron correctamente (el procedimiento encontró todos los archivos reales cpooly luego se vinculó al pcdirectorio) (tomó 3 horas).

Al final pude verificar con df -mque no se gastó espacio adicional.

De esta manera eludo el problema con la memoria y rsync. Todo el tiempo puedo verificar el rendimiento usando top y top y finalmente transferí 165 GB de datos.