L'option de compression -z avec rsync accélère-t-elle la sauvegarde?

Dans rsync, -zcompressera les données du fichier pendant le transfert.

Si je comprends bien, -zcompressez les fichiers avant le transfert, puis décompressez-les après le transfert. Le temps réduit pendant le transfert en raison de la compression est-il supérieur au temps nécessaire pour la compression et la décompression?

La réponse à la question dépend-elle du fait que je sauvegarde sur un disque dur externe via USB (2.0 ou 3.0) ou sur un serveur via SSH sur Internet?

C'est une question générale. La compression et la décompression aux points finaux améliorent-elles la bande passante effective d'un lien?

La bande passante effective (perçue) d’un lien effectuant des compressions et des décompressions aux extrémités est une fonction de:

1. à quelle vitesse vous pouvez compresser (la vitesse de votre processeur)
2. la bande passante réelle de votre réseau

La fonction est décrite avec ce graphe 3D, que vous voudrez peut-être consulter pour votre situation particulière:

Le graphique provient de l'article Compression Tools Compared 2005 de http://www.linuxjournal.com/ .

Si vous avez une connexion très lente (pensez au GPRS), vous voulez certainement compresser vos données autant que possible, sinon votre connexion ralentira les choses.

Si vous avez un processeur très lent et une connexion rapide (comme un périphérique réseau intégré), vous ne souhaitez généralement pas compresser vos données, sinon votre processeur ralentira les choses.

Dépend de la compressibilité de vos données et de la puissance de traitement de votre source et de votre destination. D'après mon expérience, une sauvegarde de disque complète compresse environ 30 à 50% de sa taille d'origine. Il peut donc être intéressant de l'essayer. Sinon, ne vous embêtez pas avec la compression. Il peut être intéressant de tester votre taux de compression pigz -c <your file> | wc -cet de comparer la taille renvoyée à votre taille d'origine.

Oui, la vitesse de la connexion détermine si la vitesse augmente. Cela ne sera que pour la sauvegarde USB car ce ne sont pas les disques qui gonflent les données, mais le processus qui les écrit. Donc, la même machine qui le lit et le dégonfle doit le gonfler et l'écrire aussi. Rsync est toujours deux processus, je pense, mais votre mémoire pour transmettre des données d’un processus à l’autre est assez rapide et le processeur a besoin de plus de temps pour le compresser (tout en le lisant dans la même mémoire qui le transmettra plus tard :).

La compression n’aide que lorsque vous avez un émetteur et un récepteur, rsync et un réseau plus lent entre les deux. 1 Gbit est peut-être déjà assez rapide lorsque vous utilisez un NAS local, par exemple, 10 Gbit correspond déjà à la vitesse SATA brute. La compression n’est donc nécessaire que lorsque la connectivité est inférieure ou égale à 100 Mbits et elle n’a de sens que lorsque les données compressées sont compressibles.

Je pense que rsync pourrait remarquer qu’il ne fonctionne pas sur deux machines mais sur une seule et ignore la compression, mais pas avec certitude.

tl; dr Sur les liaisons de transfert lentes, compressez, sinon ne le faites pas. Vous trouverez ci-dessous un test de vitesse de compression, un lien vers un outil de conversion de bande passante et des informations.

Utilisation de la compression avec rsync n'accélérera les choses que si le lien intermédiaire est "suffisamment lent", c'est-à-dire si la machine d'un côté est capable de produire un flux de données compressé assez rapidement pour saturer le lien de communication.

Alors, quel est le lien le plus lent sur lequel je devrais utiliser la compression pour gagner quelque chose?

Ce qui suit est un test très peu scientifique, qui montrera à quelle vitesse gzippeut produire des données, et ce que cela signifie pour savoir si vous devez compresser vos transferts en masse sur le réseau en général.

Les données d'entrée changeront le résultat du test beaucoup . J'utilise un fichier normal non compressé (!) Sur mon ordinateur, qui peut être représentatif du type de données que je transfère habituellement sur des réseaux. Utiliser /dev/zero(produire des zéros illimités) serait trompeur dans la mesure où un flot de zéros serait très facile à compresser, et utiliser /dev/randomserait trompeur pour la raison opposée. J'utilise donc à la place un fichier tar de mon $HOME/localrépertoire, qui contient les logiciels que j'ai installés dans mon $HOME. Le fichier est non compressé en lui-même, mais contient un mélange de fichiers binaires, de petits fichiers compressés et de fichiers source / texte. Si je le compressais, le réglage par défaut gzipréduirait de 67%, passant de 64 à 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)

Je fais cela plusieurs fois pour avoir une idée de ce que pourrait être la moyenne, ce qui représente environ 7800000 octets / s.

Ensuite, j'utilise un calculateur de bande passante réseau pour voir en quoi cela se transforme. Dans ce cas particulier, il se trouve qu’elle est juste inférieure à la capacité d’une liaison filaire "100Mb Ethernet", juste plus rapide qu’une liaison montante Internet "VDSL Download", légèrement plus rapide qu’une liaison sans fil "802.11 [a / g]", et quelque part entre "Bluetooth v3.0" (plus lent) et "USB 2.0" (plus rapide).

Cela signifie que si j'utilise la compression sur quelque chose de plus rapide , la compression ralentira probablement le transfert du fichier.

rsyncn'utilise peut-être pas exactement les mêmes bibliothèques que gzippour la compression, mais ce qui précède vous donnerait au moins un indice.

rsyncComme vous le savez, la compression ne se limite pas à la compression et l’ augmentation de la vitesse réelle provient uniquement du transfert de [fichiers de] fichiers qui ont été modifiés.

Selon ma propre expérience, l’utilisation de la compression avec rsyncest devenue de moins en moins utile au cours des 10 dernières années, à mesure que la bande passante des réseaux a augmenté (là où je suis).

Pour les sauvegardes incrémentielles, je recommanderais certainement d’examiner cette --link-destoption (cela n’a rien à voir avec ce qui est transféré, mais seulement avec la façon dont les choses sont stockées sur la cible). De même, si vous le faites sur SSH, n'utilisez pas la compression si votre connexion SSH est déjà compressée et ne compressez que les connexions SSH (tunnels, etc.) via des liaisons lentes, pour les mêmes raisons que ci-dessus.