¿La opción de compresión -z con rsync acelera la copia de seguridad?

En rsync, -zcomprimirá los datos del archivo durante la transferencia.

Si entiendo correctamente, -zcomprima los archivos antes de la transferencia y luego descomprímalos después de la transferencia. ¿El tiempo reducido durante la transferencia debido a la compresión supera el tiempo de compresión y descompresión?

¿La respuesta a la pregunta depende de si realizo una copia de seguridad en un disco duro externo a través de USB (2.0 o 3.0), o en un servidor mediante ssh a través de Internet?

Es una pregunta general. ¿La compresión y la descompresión en los puntos finales mejoran el ancho de banda efectivo de un enlace?

El ancho de banda efectivo (percibido) de un enlace que realiza compresión y descompresión en los puntos finales es una función de:

1. qué tan rápido puedes comprimir (la velocidad de tu CPU)
2. el ancho de banda real de su red

La función se describe con este gráfico 3D, que puede consultar para su situación particular:

El gráfico se origina con el artículo Compression Tools Compared 2005 de http://www.linuxjournal.com/ .

Si tiene una conexión muy lenta (piense en GPRS), definitivamente desea comprimir sus datos tanto como sea posible; de ​​lo contrario, su conexión ralentizará las cosas.

Si tiene una CPU muy lenta y una conexión rápida (como un dispositivo de red integrado), generalmente no desea comprimir sus datos, de lo contrario, su CPU ralentizará las cosas.

Depende de cuán comprimibles sean sus datos y la potencia de procesamiento de su origen y destino. Una copia de seguridad de disco completa en mi experiencia se comprimirá a aproximadamente el 30-50% de su tamaño original, por lo que podría valer la pena intentarlo. De lo contrario, no te molestes con la compresión. Puede valer la pena probar su tasa de compresión pigz -c <your file> | wc -cy comparar el tamaño devuelto con su tamaño original.

Sí, la velocidad de la conexión determina si la velocidad se acelera. Estará sobrecargado solo para la copia de seguridad USB, porque no los discos infla los datos sino el proceso que los escribe. Entonces, la misma máquina que lo lee y desinfla, también tiene que inflarlo y escribirlo. Rsync sigue siendo dos procesos, creo, pero su memoria para transferir datos de un proceso a otro es lo suficientemente rápido y la CPU necesita más tiempo para comprimirlo (mientras lo lee en la misma memoria que luego lo entrega :).

La compresión solo ayuda cuando tiene un remitente y un receptor rsync y alguna red más lenta en el medio. 1Gbit puede ser lo suficientemente rápido cuando tiene un NAS local, por ejemplo, 10Gbit ya es velocidad SATA sin procesar. Por lo tanto, la compresión solo es necesaria cuando tiene una conectividad de 100Mbit o menos y solo tiene sentido cuando los datos comprimidos son compresibles.

Creo que rsync podría notar que no se ejecuta en dos máquinas, sino en una, y omite la compresión, pero no estoy seguro.

tl; dr Sobre enlaces de transferencia lenta, comprimir, de lo contrario no. A continuación se muestra una prueba de velocidad de compresión, un enlace a una herramienta de conversión de ancho de banda y algo de información.

El uso de la compresión rsyncsolo acelerará las cosas si el enlace intermedio es "lo suficientemente lento", es decir, si la máquina en un extremo es capaz de producir un flujo de datos comprimido lo suficientemente rápido como para saturar el enlace de comunicación.

Entonces, ¿cuál es el enlace más lento en el que debería usar la compresión para ganar algo?

La siguiente es una prueba muy poco científica, que mostrará qué tan rápido gzippuede producir datos y lo que eso significa si debe comprimir las transferencias masivas de su red en general.

Los datos de entrada cambiarán en gran medida el resultado de la prueba . Estoy usando un archivo normal sin comprimir (!) En mi computadora que puede ser representativo del tipo de datos que generalmente transfiero a través de redes. Usar /dev/zero(producir ceros ilimitados) sería engañoso ya que una corriente de ceros sería muy fácil de comprimir, y usar /dev/randomsería engañoso por la razón opuesta. Entonces, en cambio, uso un archivo tar de mi $HOME/localdirectorio, que contiene el software que instalé en mi $HOME. El archivo está descomprimido en sí mismo, pero contiene una mezcla de archivos binarios, pequeños archivos comprimidos y archivos de fuente / texto, y lo comprimiría con la configuración predeterminada para gzipque se redujera en un 67% de 64 MiB a 22 MiB.

$ gzip -c local.tar | dd of=/dev/null
43092+4 records in
43093+1 records out
22063854 bytes transferred in 2.819 secs (7825741 bytes/sec)

Hago esto varias veces para tener una idea de cuál podría ser el promedio, y se trata de aproximadamente 7800000 bytes / s.

Luego uso una calculadora de ancho de banda de red para ver en qué se convierte esto. En este caso particular, resulta estar justo por debajo de la capacidad de un enlace cableado "Ethernet de 100 Mb", más rápido que un enlace ascendente de Internet "Descarga VDSL", un poco más rápido que un enlace inalámbrico "802.11 [a / g]", y en algún lugar entre "Bluetooth v3.0" (más lento) y "USB 2.0" (más rápido).

Esto significa que si estoy usando compresión sobre algo más rápido que eso, la compresión probablemente ralentizará la transferencia del archivo.

rsyncEs posible que no esté utilizando exactamente las mismas bibliotecas que gzippara hacer la compresión, pero lo anterior le daría una pista al menos.

rsyncsin embargo, hace más que la compresión, y el aumento de la velocidad real proviene de la transferencia de [bits de] archivos que han cambiado.

En mi propia experiencia, el uso de la compresión con se rsyncha vuelto cada vez menos beneficioso en los últimos 10 años más o menos, a medida que el ancho de banda de las redes ha aumentado (donde estoy).

Para hacer copias de seguridad incrementales, definitivamente recomendaría investigar la --link-destopción (esto no tiene nada que ver con lo que se transfiere, solo con cómo se almacenan las cosas en el destino). Además, si lo está haciendo a través de SSH, no use la compresión si su conexión SSH ya está comprimida, y solo comprima las conexiones SSH (túneles, etc.) que están sobre enlaces lentos, por las mismas razones que arriba.