Para archivos grandes comprimir primero y luego transferir o rsync -z? ¿Cuál sería el más rápido?

Tengo una tonelada de archivos de datos pequeños de relatividad, pero ocupan unos 50 GB y necesito transferirlos a una máquina diferente. Estaba tratando de pensar en la forma más eficiente de hacer esto.

Pensé que tenía que hacer gzip todo, luego rsync y descomprimirlo, confiar en rsync -z para la compresión, gzip y luego usar rsync -z. No estoy seguro de cuál sería el más eficiente, ya que no estoy seguro de cómo se implementa exactamente rsync -z. ¿Alguna idea sobre qué opción sería la más rápida?

No puede "gzip todo" ya que gzip solo comprime un archivo, puede crear un archivo tar y gzip para "gzip todo" pero perdería la capacidad de rsync de copiar solo un archivo modificado.

Entonces la pregunta es: ¿es mejor almacenar el archivo que necesito para rsync gziped o confiar en la opción -z de rsync.
¿La respuesta es probablemente que no desea que el archivo se descomprima en su servidor? Supongo que sí, por lo que no veo cómo podría manejar el archivo gzip antes de hacer el rsync.

¿Puede ser que no necesite la capacidad rsync de copiar solo archivos modificados? En este caso, ¿por qué usar rsync en lugar de hacer un scp de un archivo tar.gz que contiene tus cosas?

De todos modos para responder la pregunta, rsync gzip será un poco menos eficiente que gziping file con gzip. Por qué ? debido a que rsync gzipá datos por fragmentos, por lo que se usará un conjunto de datos más pequeño para crear la tabla que gzip usa para hacer la compresión, un conjunto de datos más grande (gzip usaría todo el archivo de una vez) dará una mejor tabla de compresión. Pero la diferencia será muy muy pequeña en la mayoría de los casos, pero en casos muy raros, la diferencia puede ser más importante (si tiene un archivo muy grande con una relación muy larga que se repite muchas veces en el archivo pero lejos el uno del otro) (Esto es un ejemplo muy simplificado)

Si solo está copiando los datos una vez, rsync no será una gran victoria en sí mismo. Si te gusta gzip, (o tar + gzip, ya que tienes muchos archivos), puedes probar algo como:

tar -cz /home/me/source/directory | ssh target tar -xz --directory /home/you/target/directory

Eso obtendría la compresión que está buscando y simplemente copiará directamente sin involucrar a rsync.

@radius, un detalle menor para elegir cómo gzipfunciona: gzipes un algoritmo de compresión basado en bloques, y bastante simple. El archivo completo no se considera para la tabla de compresión, solo cada bloque. Otros algoritmos pueden usar todo el contenido del archivo y hay algunos que usan el contenido de múltiples bloques o incluso bloques de tamaño variable. Un ejemplo fascinante es lrzip, por el mismo autor que rsync!

El gzipalgoritmo del flaco .

Entonces, en resumen, el uso rsync -zprobablemente producirá la misma compresión que el gzipprimero, y si está haciendo una transferencia diferencial, mejor debido rsyncal algoritmo diferente.

Dicho esto, creo que uno encontrará scplatidos prácticos regulares rsyncpara las transferencias no diferenciales, porque tendrá mucho menos sobrecarga que rsyncel algoritmo (¡que de scptodos modos usaría bajo el capó!)

Si su red se convierte en un cuello de botella, entonces querrá usar compresión en el cable.

Si sus discos son el cuello de botella, entonces es mejor transmitir en un archivo comprimido. (por ejemplo, netcatde una máquina a la siguiente, transmitiendo a gzip -c)

Por lo general, si la velocidad es clave, comprimir un archivo existente de antemano es un desperdicio.

TIMTOWTDI, YMMV, IANAL, etc.

Según este tipo , puede ser más rápido de usar rsync -z, aunque supongo que sería tan eficiente como comprimir cada archivo antes de transferirlo. Debería ser más rápido que comprimir el flujo de alquitrán, como lo sugieren otros.

Desde la página del manual:

          Note  that  this  option  typically  achieves better compression
          ratios than can be achieved by using a compressing remote  shell
          or  a  compressing  transport  because it takes advantage of the
          implicit information in the matching data blocks  that  are  not
          explicitly sent over the connection.

Dado que tanto scp de archivo comprimido como rsync tomarán tiempos de transferencia muy similares, la "forma más eficiente de hacer esto" sería la compresión sobre la marcha en lugar de comprimir, transferir.

Además de la "solidez", otras consideraciones incluyen:

rsync se puede reiniciar fácilmente si no se transfieren todos los archivos.

rsync se puede usar para mantener los archivos en la máquina remota.

alquitrán local o gzip requiere espacio local.

Consideraciones sobre el uso del puerto tanto para la máquina de destino como para los firewalls: 1) scp usa el puerto 22 (por defecto) que puede no ser aceptable. 2) rsync users port 873 (por defecto)

No estoy seguro de por qué radius espera que el póster original NO quiera almacenar archivos descomprimidos.