La mejor manera de copiar millones de archivos entre 2 servidores

Tengo aproximadamente alrededor de 5 millones de archivos pequeños (5-30k) en un solo directorio que me gustaría copiar en otra máquina en la misma red gigabit. Intenté usar rsync, pero se ralentizaría al rastrear después de unas horas de ejecución, supongo que debido a que rsync tiene que verificar el archivo de origen y de destino cada vez.

Mi segundo pensamiento sería usar scp, pero quería obtener una opinión externa para ver si había una mejor manera. ¡Gracias!

Algo como esto debería funcionar bien:

tar c some/dir | gzip - |  ssh host2 tar xz

Quizás también omita gzip y la bandera "z" para la extracción, ya que está en una red gigabit.

Estoy seguro de que el hecho de que tenga todos los CINCO MILLONES de archivos en un solo directorio arrojará muchas herramientas a un tizzy. No me sorprende que rsync no haya manejado esto con gracia, es una situación bastante "única". Si pudiera encontrar una manera de estructurar los archivos en algún tipo de estructura de directorios, estoy seguro de que las herramientas de sincronización estándar como rsync responderían mucho mejor.

Sin embargo, solo para dar algunos consejos reales, tal vez una solución sería mover el disco físicamente a la máquina de destino temporalmente para que pueda hacer una copia de los archivos en el servidor real (no a través de la red). Luego, mueva la unidad hacia atrás y use rsync para mantener las cosas actualizadas.

Para copiar millones de archivos a través de un conmutador gigabit (en un entorno confiable), también puede usar una combinación de netcat (or nc)y tar, como ya lo sugirió el usuario 55286. Esto transmitirá todos los archivos como un archivo grande (consulte Copia rápida de archivos - Linux! (39 GB) ).

# requires netcat on both servers
nc -l -p 2342 | tar -C /target/dir -xzf -   # destination box
tar -cz /source/dir | nc Target_Box 2342    # source box

Teníamos aproximadamente 1 millón de archivos en un directorio (aproximadamente 4 años de archivos).

Y usamos robocopy para mover archivos al directorio AAAA / MM (alrededor de 35-45,000 archivos por mes) ... colocamos el script robocopy en un archivo .bat como este:

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081201 /MINAGE:20090101 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\12
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090101 /MINAGE:20090201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\01
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090201 /MINAGE:20090301 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\02

notas breves ... /ns /nc /nfl /npes evitar hinchar el archivo de registro con información adicional /log+...es escribir información de resumen en el archivo de registro.

/minage and /maxage is to copy files modified with in that date range. 

así, por ejemplo, archivos modificados> = 01 / Nov / 2008 (inclusive) a archivos modificados <01 / Dec / 2008 (no incluido)

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11

/mov mover los archivos

luego viene el directorio fuente

luego viene el directorio de destino (los directorios se crearán sobre la marcha cuando sea necesario).

Tomó alrededor de 40 - 60 minutos para 1 mes de transferencia (aproximadamente 35-45,000 archivos) Consideramos que toma alrededor de 12 horas o menos para 1 año de transferencia.

Usando Windows Server 2003.

Todo el material se registra en el archivo de registro ... Hora de inicio, Hora de finalización y Número de archivos copiados.

Robocopy salvó el día.

Sabes, agregué más de 1 a la solución de alquitrán, pero, dependiendo del entorno, hay otra idea que ocurre. Puede pensar en usar dd (1) . El problema de la velocidad con algo como esto es que se necesitan muchos movimientos de la cabeza para abrir y cerrar un archivo, lo que harás cinco millones de veces. En caso de que pueda asegurarse de que estos se asignen de forma contigua, podría dd en su lugar, lo que reduciría el número de movimientos de la cabeza en un factor de 5 o más.

Prefiero usar lz4 como la herramienta de compresión más rápida en este momento. La opción SSH -c arcfour128 utiliza un algoritmo de cifrado más rápido que el predeterminado. [1]

Entonces la transferencia de directorio se parece a:

tar -c folder | lz4 -c | ssh -carcfour128 somehost 'lz4 -d | tar -x > folder'

Tenga en cuenta que en Debian el comando lz4 es lz4c y en CentOS es lz4.

Robocopy es genial para cosas como esta. Intentará nuevamente después de que se agote el tiempo de espera de la red y también le permite establecer un retardo de brecha entre paquetes para ahora inundar la tubería.

[Editar]

Tenga en cuenta que esta es una aplicación solo para Windows.

Sé que esto puede ser estúpido, pero ¿ha pensado en copiarlos en un disco externo y llevarlos al otro servidor? En realidad, puede ser la solución más eficiente y simple.

Estamos investigando este problema actualmente. Necesitamos transferir unos 18 millones de archivos pequeños, unos 200 GB en total. Logramos el mejor rendimiento usando XCopy antiguo, pero todavía tomó mucho tiempo. ¡Aproximadamente 3 días de 1 servidor a otro, aproximadamente 2 semanas a una unidad externa!

A través de otro proceso, necesitábamos duplicar el servidor. Esto se hizo con Acronis. ¡Tomó alrededor de 3 horas!

Vamos a investigar esto un poco más. La sugerencia dd anterior probablemente proporcionaría resultados similares.

Ya hay toneladas de buenas sugerencias, pero quería incluir Beyond Compare . Recientemente transferí unos 750,000 archivos entre 5 KB y 20 MB de un servidor a otro a través de un conmutador gigabit. Ni siquiera tuvo hipo en absoluto. De acuerdo, tomó un tiempo, pero esperaría eso con tantos datos.

Vería cómo funciona un zip-> copy-> unzip

o cualquiera que sea su sistema de compresión / archivo favorito.

Empaquételos en un solo archivo antes de copiarlo, luego descomprímalos nuevamente después de copiarlo.

En una situación similar, intenté usar tar para agrupar los archivos. Escribí un pequeño script para canalizar la salida del comando tar a la máquina de destino directamente en un proceso de recepción de tar que desglosó los archivos.

El enfoque tar casi duplicó la velocidad de transferencia en comparación con scp o rsync (YMMV).

Aquí están los comandos tar. Tenga en cuenta que deberá habilitar los comandos r creando archivos .rhosts en los directorios de inicio de cada máquina (elimínelos una vez que se hayan completado, son problemas de seguridad notorios). Tenga en cuenta también que, como de costumbre, HP-UX es incómodo, mientras que el resto del mundo usa 'rsh' para el comando de shell remoto, HP-UX usa 'remsh'. 'rsh' es algún tipo de shell restringido en el lenguaje HP.

box1> cd source_directory; tar cf - . | remsh box2 "cd target_directory; tar xf - "

El primer comando tar crea un archivo llamado '-', que es un token especial que significa 'salida estándar' en este caso. El archivo creado contiene todos los archivos en el directorio actual (.) Más todos los subdirectorios (tar es recursivo por defecto). Este archivo está conectado al comando remsh que lo envía a la máquina box2. En el cuadro 2, primero cambio al directorio de recepción adecuado, luego extraigo de '-' o 'entrada estándar' los archivos entrantes.

Tenía 6 de estos comandos tar ejecutándose simultáneamente para garantizar que el enlace de red estuviera saturado de datos, aunque sospecho que el acceso al disco puede haber sido el factor limitante.

Omitir el sistema de archivos.

¿Puede desmontar esta partición en la que viven los archivos o montarla solo de lectura? Haz eso, luego algo como:

dd if=/dev/PARTITION | ssh username@host "dd of=diskimage.bin"

Luego puede montarlo diskimage.bincomo un dispositivo de bucle invertido en el lado de destino y copiar archivos de él a su sistema de archivos de destino real, o tal vez usar las herramientas adecuadas para volver a unirlo en una partición vacía en el lado de destino (peligroso, pero probablemente posible , aunque nunca lo he hecho.)

Si eres realmente valiente, puedes ddvolver directamente a una partición en el lado de destino. No lo recomiendo

puede intentar lo siguiente (puede estar en lotes de archivos)

• tar el lote de archivos
• gzip ellos
• copiar usando scp si es posible
• pistolas
• descomprimir los archivos

Según lo sugerido por sth, puede probar tar sobre ssh.

Si no necesita cifrado (originalmente usó rsync, pero no mencionó que era rsync + ssh), puede probar tar sobre netcat para evitar la sobrecarga de ssh.

Por supuesto, también puede acortar el tiempo que lleva usando gzip u otro método de compresión.

Hay algo más a tener en cuenta. Prueba esto:

• Crea un VHD, de tamaño dinámico
• Montarlo, posiblemente como un directorio
• Establezca el atributo 'comprimir todo el disco'

Al hacer esto, NO hay gastos generales para la iteración o compresión del directorio, porque eso se hizo en el momento en que se escribieron los archivos. Solo hay un archivo para mover: el VHD.

En Windows, configuro el tamaño predeterminado del paquete TCP para que sea más grande, como 16348. Esto significa menos sobrecarga del encabezado IP.

Sin embargo, una cosa con la que me he encontrado es que es mejor mantener el tamaño de los archivos por debajo de 100 Mb para una transferencia de red o USB. Utilizo Rar.exe para eso, para dividir los archivos.

Funciona como un campeón. Este es el equivalente de 'dd' en Linux. El concepto de montar un sistema de archivos comprimido en un directorio también es normal para Linux, por lo que se aplica la misma lógica. Debe asegurarse de que todos los archivos estén cerrados antes de que comience la operación, como en los otros métodos.

Esto tiene el beneficio adicional de hacer posible poner una cuota de tamaño en una carpeta. Si el VHD es de un tamaño fijo, superar ese límite no derribará el servidor, solo causará un error al crear o escribir el archivo.

Un VHD formateado como NTFS también puede manejar millones de archivos en una carpeta.