tar + rsync + untar. ¿Cualquier beneficio de velocidad sobre solo rsync?

A menudo me encuentro enviando carpetas con 10K – 100K de files a una máquina remota (dentro de la misma networking 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 

cuando transfiere los files por primera vez .

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

Actualizar

Acabo de ejecutar algunos experimentos moviendo 10.000 files pequeños (tamaño total = 50 MB), y tar+rsync+untar fue consistentemente más rápido que ejecutar rsync directamente (ambos sin compression).

Cuando envía el mismo set de files, rsync es más apropiado porque solo enviará diferencias. tar siempre enviará todo y esto es un desperdicio de resources cuando muchos de los datos ya están allí. El tar + rsync + untar pierde esta ventaja en este caso, así como la ventaja de mantener las carpetas sincronizadas con rsync --delete .

Si copy los files por primera vez, primero empaqueta, luego envía y luego descomprime (AFAIK rsync no toma input por tubería) es engorroso y siempre peor que simplemente rsyncing, porque rsync no tendrá que hacer ninguna tarea más que tar de todas forms.

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

Consejo 2: si usa rsync en ssh , también puede usar tar+ssh

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

o simplemente scp

 scp -Cr srcdir user@server:destdir 

Regla general, que sea simple.

ACTUALIZAR:

Creé 59M 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 probado varias veces la transferencia de files a un server remoto (no en la misma LAN), usando ambos methods

 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 

manteniendo loggings separados de los packages 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 less tráfico de networking usando rsync + tar, que se espera cuando el mtu pnetworkingeterminado es 1500 y mientras los files tienen un tamaño de 10k. rsync + tar generó más tráfico, fue más lento durante 2-3 segundos y dejó dos files de basura que tuvieron que limpiarse.

Hice las mismas testings en dos máquinas en la misma LAN, y allí el rsync + tar hizo mucho mejores times y mucho less tráfico de networking. Supongo que es causa de jumbo frames.

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

rsync también hace compression. Use la bandera -z . Si se ejecuta en ssh , también puede usar el modo de compression de ssh. Mi sensación es que los niveles repetidos de compression no son útiles; solo quemará ciclos sin resultados significativos. Recomiendo experimentar con la compression rsync . Parece bastante efectivo. Y sugiero omitir el uso de tar o cualquier otra compression pre / post.

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

Tuve que hacer una copy de security de mi directory personal en NAS hoy y me encontré con esta discusión, pensé que agregaría mis resultados. Para resumir, tarizar la networking en el sistema de files de destino es mucho más rápido en mi entorno que sincronizar con el mismo destino.

Entorno: computadora de origen i7 escritorio con disco duro SSD. Máquina de destino Synology NAS DS413j en una connection lan de gigabit a la máquina de origen.

La especificación exacta del kit implicado afectará el performance, naturalmente, y no sé los detalles de mi configuration exacta con respecto a la calidad del hardware de networking en cada extremo.

Los files fuente son mi carpeta ~ / .cache que contiene 1.2Gb de files 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 a través de ssh a un process de retardo en el receptor.

Tiempos:

 1a - 33 seconds 1b - 1 minutes 48 seconds 2 - 22 minutes 

Está muy claro que rsync tuvo un performance increíblemente bajo en comparación con una operación tar, que presumiblemente se puede atribuir al performance de la networking mencionado anteriormente.

Recomendaría a cualquiera que quiera hacer una copy de security de grandes cantidades de files en su mayoría pequeños, como una copy de security del directory de inicio, usar el enfoque tar. rsync parece una opción muy pobre. Regresaré a esta publicación si parece que he sido inexacto en cualquiera de mis procedimientos.

Mella

Para directorys pequeños (pequeños como en el espacio en disco usado), depende de la sobrecarga de verificar la información del file para los files que se sincronizan. Por un lado, rsync ahorra el time de transferencia de los files no modificados, por otro lado, de hecho tiene que transferir información sobre cada file.

No sé exactamente las rsync internas de rsync . Si las statistics del file causan retraso depende de cómo rsync transfiere datos: si las statistics de file se transfieren una por una, entonces el RTT puede hacer que tar + rsync + untar sea más rápido.

Pero si lo tiene, digamos 1 GiB de datos, rsync será mucho más rápido, bueno, ¡a less que su connection sea realmente rápida!

Usar rsync para enviar un file tar como se solicitó realmente sería un desperdicio o resources, ya que agregaría una capa de verificación al process. Rsync verificaría la corrección del file tar, cuando prefiera controlar los files individuales. (No ayuda saber que el file tar que puede haber estado defectuoso en el lado de envío ya muestra el mismo efecto en el extremo receptor). Si está enviando un file, ssh / scp es todo lo que necesita.

La única razón por la que debería seleccionar enviar un file sería si el file que eligió pudiese conservar más de las ofertas especiales del sistema de files, como la Lista de control de acceso u otros Metadatos almacenados a menudo en Atributos extendidos (Solaris) o Fuentes de resources (MacOS) ) Cuando se trata de tales cosas, su principal preocupación será qué herramientas pueden conservar toda la información asociada con el file en el sistema de files de origen, siempre que el sistema de files de destino tenga la capacidad de hacer un seguimiento de ellas también.

Cuando la velocidad es su principal preocupación, depende mucho del tamaño de sus files. En general, una multitud de files diminutos se escalarán mal con rsync o scp, ya que todos desperdiciarán packages de networking individuales cada uno, donde un file tar includeía varios de ellos dentro de la carga de datos de un único package de networking. Incluso mejor si el file tar estuviera comprimido, ya que los files pequeños probablemente se comprimirían mejor como un todo que individualmente. Hasta donde yo sé, tanto rsync como scp no se pueden optimizar al enviar files individuales integers como en una transferencia inicial, teniendo cada file ocupando un cuadro de datos completo con toda su sobrecarga de protocolo (y desperdiciando más en verificar y retroceder). Sin embargo, Janecek afirma que esto es cierto solo para scp, ya que detalló que rsync optimizaría el tráfico de la networking pero a costa de build enormes estructuras de datos en la memory. Vea el artículo Efficient File Transfer, Janecek 2006 . Entonces, según él, sigue siendo cierto que tanto scp como rsync escalan mal en files pequeños, pero por razones completamente diferentes. Supongo que tendré que investigar fonts este fin de semana para averiguarlo.

Para una relevancia práctica, si sabe que está enviando files mayoritariamente grandes, no habrá mucha diferencia de velocidad, y el uso de rsync tiene la ventaja adicional de poder continuar donde lo dejó cuando se interrumpe.

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 manera segura cuando se usaba en ssh, de lo contrario era insegura). Sin embargo, no funcionaría tan bien como rsync ya que no se optimizó para solo transferir contenido que había cambiado. Su principal diferencia con rsync radica en la forma en que está configurado y cómo se explican las reglas para actualizar los files.

Tiempo esto:

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