A menudo me encuentro enviando carpetas con 10K - 100K de archivos a una máquina remota (dentro de la misma red en el campus).

Me preguntaba si hay razones para creer eso,

 tar + rsync + untar

O simplemente

 tar (from src to dest) + untar

podría ser más rápido en la práctica que

rsync 

al transferir los archivos por primera vez .

Estoy interesado en una respuesta que aborde lo anterior en dos escenarios: usar compresión y no usarla.

Actualizar

Acabo de ejecutar algunos experimentos moviendo 10,000 archivos pequeños (tamaño total = 50 MB), y tar+rsync+untarfui consistentemente más rápido que correr rsyncdirectamente (ambos sin compresión).

Cuando envía el mismo conjunto de archivos, rsynces más adecuado porque solo enviará diferencias. tarsiempre enviará todo y esto es un desperdicio de recursos cuando muchos de los datos ya están allí. La tar + rsync + untarpierde esta ventaja, en este caso, además de la ventaja de mantener las carpetas en sincronía con rsync --delete.

Si copia los archivos por primera vez, primero empaqueta, luego envía y luego desempaca (AFAIK rsyncno toma la entrada canalizada) es engorroso y siempre peor que simplemente enviar un mensaje, ya rsyncque no tendrá que hacer ninguna tarea más que de tartodos modos.

Consejo: rsync versión 3 o posterior realiza una recursividad incremental, lo que significa que comienza a copiar casi inmediatamente antes de contar todos los archivos.

Consejo 2: si usa rsyncmás ssh, también puede usar cualquieratar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

o solo scp

scp -Cr srcdir user@server:destdir

Regla general, que sea simple.

ACTUALIZAR:

He creado 59 millones de datos de demostración

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

y probé varias veces la transferencia de archivos a un servidor remoto (no en el mismo lan), usando ambos métodos

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

mientras mantiene registros separados de los paquetes de tráfico ssh enviados

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

En este caso, no puedo ver ninguna ventaja en menos tráfico de red usando rsync + tar, que se espera cuando el mtu predeterminado es 1500 y mientras los archivos tienen un tamaño de 10k. rsync + tar generó más tráfico, fue más lento durante 2-3 segundos y dejó dos archivos basura que tuvieron que limpiarse.

Hice las mismas pruebas en dos máquinas en el mismo lan, y allí el rsync + tar tuvo tiempos mucho mejores y mucho menos tráfico de red. Asumo la causa de los marcos gigantes.

Quizás rsync + tar sería mejor que solo rsync en un conjunto de datos mucho más grande. Pero, francamente, no creo que valga la pena, necesita doble espacio en cada lado para empacar y desempacar, y hay un par de otras opciones como ya he mencionado anteriormente.

rsyncTambién hace compresión. Usa la -zbandera. Si lo atropella ssh, también puede usar el modo de compresión de ssh. Mi sensación es que los niveles repetidos de compresión no son útiles; solo quemará ciclos sin resultados significativos. Recomiendo experimentar con la rsynccompresión. Parece bastante efectivo. Y sugeriría omitir el uso de tarcualquier otra compresión previa / posterior.

Usualmente uso rsync como rsync -abvz --partial....

Tuve que hacer una copia de seguridad de mi directorio personal en NAS hoy y me encontré con esta discusión, pensé que agregaría mis resultados. En pocas palabras, la tarificación a través de la red al sistema de archivos de destino es mucho más rápido en mi entorno que la sincronización al mismo destino.

Entorno: máquina de origen i7 de escritorio con disco duro SSD. Máquina de destino Synology NAS DS413j en una conexión LAN de gigabit a la máquina de origen.

La especificación exacta del kit involucrado afectará el rendimiento, naturalmente, y no conozco los detalles de mi configuración exacta con respecto a la calidad del hardware de red en cada extremo.

Los archivos de origen son mi carpeta ~ / .cache que contiene 1,2 Gb de archivos en su mayoría muy pequeños.

1a/ tar files from source machine over the network to a .tar file on remote machine

$ tar cf /mnt/backup/cache.tar ~/.cache

1b/ untar that tar file on the remote machine itself

$ ssh admin@nas_box
[admin@nas_box] $ tar xf cache.tar

2/ rsync files from source machine over the network to remote machine

$ mkdir /mnt/backup/cachetest
$ rsync -ah .cache /mnt/backup/cachetest

Mantuve 1a y 1b como pasos completamente separados solo para ilustrar la tarea. Para aplicaciones prácticas, recomendaría lo que Gilles publicó anteriormente que involucra la salida de alquitrán de tubería a través de ssh a un proceso sin restricciones en el receptor.

Tiempos:

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

Está muy claro que rsync se desempeñó sorprendentemente mal en comparación con una operación tar, que presumiblemente se puede atribuir tanto al rendimiento de la red mencionado anteriormente.

Recomiendo a cualquiera que quiera hacer una copia de seguridad de grandes cantidades de archivos en su mayoría pequeños, como una copia de seguridad del directorio de inicio, utilice el enfoque tar. rsync parece una muy mala elección. Volveré a esta publicación si parece que he sido inexacto en alguno de mis procedimientos.

Mella

Usar rsync para enviar un archivo tar como se solicitó en realidad sería un desperdicio o recursos, ya que agregaría una capa de verificación al proceso. Rsync verificaría la exactitud de la suma de comprobación del archivo tar, cuando prefiere tener la comprobación de los archivos individuales. (No ayuda saber que el archivo tar que puede haber sido defectuoso en el lado emisor ya muestra el mismo efecto en el extremo receptor). Si está enviando un archivo, ssh / scp es todo lo que necesita.

La única razón por la que podría tener que seleccionar el envío de un archivo sería si el tar de su elección pudiera conservar más de los especiales del sistema de archivos, como la Lista de control de acceso u otros Metadatos a menudo almacenados en Atributos extendidos (Solaris) o Ressource Forks (MacOS ) Al lidiar con tales cosas, su principal preocupación será qué herramientas son capaces de preservar toda la información asociada con el archivo en el sistema de archivos de origen, siempre que el sistema de archivos de destino tenga la capacidad de realizar un seguimiento de ellas también.

Cuando la velocidad es su principal preocupación, depende mucho del tamaño de sus archivos. En general, una gran cantidad de archivos pequeños se escalarán mal sobre rsync o scp, ya que todos desperdiciarán paquetes de red individuales cada uno, donde un archivo tar incluiría varios de ellos dentro de la carga de datos de un solo paquete de red. Incluso mejor si el archivo tar estuviera comprimido, ya que los archivos pequeños probablemente se comprimirían mejor en conjunto que individualmente. Por lo que sé, tanto rsync como scp no se optimizan al enviar archivos individuales completos como en una transferencia inicial, haciendo que cada archivo ocupe un marco de datos completo con todo el protocolo de gastos generales (y desperdiciando más en la verificación de ida y vuelta). Sin embargo Janecekdeclara que esto es cierto solo para scp, al detallar que rsync optimizaría el tráfico de red pero a costa de construir enormes estructuras de datos en la memoria. Ver artículo Efficient File Transfer, Janecek 2006 . Entonces, según él, sigue siendo cierto que tanto scp como rsync escalan mal en archivos pequeños, pero por razones completamente diferentes. Supongo que tendré que buscar fuentes este fin de semana para averiguarlo.

Por relevancia práctica, si sabe que está enviando archivos en su mayoría más grandes, no habrá mucha diferencia en la velocidad, y el uso de rsync tiene el beneficio adicional de poder continuar donde lo dejó cuando se interrumpió.

Postscriptum: En estos días, rdist parece hundirse en el olvido, pero antes de los días de rsync, era una herramienta muy capaz y ampliamente utilizada (de forma segura cuando se usa sobre ssh, de lo contrario no es seguro). Sin embargo, no funcionaría tan bien como rsync ya que no se optimizó solo para transferir contenido que había cambiado. Su principal diferencia con rsync radica en la forma en que se configura y cómo se explican las reglas para actualizar los archivos.

Para directorios pequeños (pequeños como en el espacio en disco usado), depende de la sobrecarga de verificar la información del archivo para los archivos que se están sincronizando. Por un lado, rsyncahorra el tiempo de transferencia de los archivos no modificados, por otro lado, de hecho, tiene que transferir información sobre cada archivo.

No sé exactamente lo interno de rsync. Si las estadísticas del archivo causan un retraso depende de cómo se rsynctransfieren los datos: si las estadísticas del archivo se transfieren una por una, el RTT puede hacer que tar + rsync + untar sea más rápido.

Pero si tiene, digamos 1 GiB de datos, rsync será mucho más rápido, bueno, ¡a menos que su conexión sea realmente rápida!

Tuve que mover algunos terabytes de datos por todo el país, exactamente una vez. Como experimento, ejecuté dos de las transferencias usando rsyncy ssh/tarpara ver cómo se comparan.

Los resultados:

• rsync transfirió los archivos a una velocidad promedio de 2,76 megabytes por segundo.
• ssh/tar transfirió los archivos a una velocidad promedio de 4,18 megabytes por segundo.

Los detalles: Mis datos consisten en millones de archivos comprimidos .gz, cuyo tamaño promedio es de 10 megabytes, pero algunos tienen más de un gigabyte. Hay una estructura de directorio pero está eclipsada por el tamaño de los datos dentro de los archivos. Si tuviera algo más que hacer, solo lo habría usado, rsyncpero en este caso, ssh/tares una solución funcional.

Mi trabajo rsyncconsiste en:

rsync --compress --stats --no-blocking-io --files-from=fileList.txt -av otherSystem:/the/other/dir/ dest/

donde fileList.txt es una gran lista larga de los nombres de ruta relativos de los archivos en el otro lado. (Me di cuenta de que --compressno es productivo para archivos comprimidos después de comenzar, pero no iba a volver a reiniciar).

Comencé otro con ssh y tar que tiene:

ssh otherSystem "cd /the/other/dir/;  tar cf - ." | tar xvf -

Observará que esto copia todo, lo siento, esta no es una comparación 100% de manzanas con manzanas.

Debo agregar que mientras uso la red interna de la empresa, tengo que pasar por un intermediario para acceder a la computadora de origen de datos. El tiempo de ping de mi computadora de destino al intermediario es de 21 ms y del intermediario a la fuente de datos es de 26 ms. Esto fue lo mismo para ambas transferencias.

La conexión SSL a través del intermediario se realiza a través de la ~/.ssh/configentrada:

Host otherSystem
    Hostname dataSource.otherSide.com
    User myUser
    Port 22
    ProxyCommand ssh -q -W %h:%p intermediary.otherSide.com
    IdentityFile   id_rsa.priv

Mida esto:

tar cf - ~/.cache | ssh admin@nas_box "(cd /destination ; tar xf -)"