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.
