L'option de compression -z avec rsync accélère la sauvegarde
Dans rsync, -z compressera les données du fichier pendant le transfert.
Si je comprends bien, -z compresser les fichiers avant le transfert, puis les décompresser après le transfert. Est-ce que le temps réduit pendant le transfert en raison de la compression dépasse le temps de compression et de décompression?
La réponse à la question dépend-elle de la 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 d'extrémité améliorent-elles la bande passante effective d'une liaison?
La bande passante effective (perçue) d'un lien effectuant la compression et la décompression aux points d'extrémité est fonction de:
- à quelle vitesse vous pouvez compresser (la vitesse de votre CPU)
- la bande passante réelle de votre réseau
La fonction est décrite avec ce graphique 3D, que vous pouvez 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 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 voulez généralement pas compresser vos données, sinon votre processeur ralentira les choses.
Oui, la vitesse de la connexion détermine si cela accélère les choses. Ce ne sera que pour la sauvegarde USB, car ce ne sont pas les disques qui gonflent les données mais le processus qui écrit les données. Donc, la même machine qui la lit et la dégonfle, doit aussi la gonfler et l'écrire. Rsync est toujours deux processus, je pense, mais votre mémoire pour transmettre les 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 remettra plus tard :).
La compression n'aide que lorsque vous avez un expéditeur et un récepteur rsync et un réseau plus lent entre les deux. 1 Gbit peut être déjà assez rapide lorsque vous avez un NAS par exemple, 10 Gbit est déjà une vitesse SATA brute. La compression n'est donc nécessaire que lorsque vous avez une connectivité de 100 Mbit ou moins et cela n'a de sens que lorsque le les données compressées sont compressibles.
Je pense que rsync pourrait remarquer qu'il ne fonctionne pas sur deux machines mais une et ignore la compression mais pas sûr.
Cela 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 complète du disque se compressera à environ 30 à 50% de sa taille d'origine, il pourrait donc être utile de lui donner une chance. Sinon, ne vous embêtez pas avec la compression. Il peut être utile de tester votre taux de compression avec pigz -c <your file> | wc -c et comparez la taille retournée avec votre taille d'origine.
tl; dr Sur les liaisons à transfert lent, 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 quelques informations.
L'utilisation de la compression avec rsync n'accélère les choses que si le lien intermédiaire est "assez lent", c'est-à-dire si la machine à une extrémité 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 auquel je devrais utiliser la compression pour gagner quoi que ce soit?
Ce qui suit est un test très peu scientifique, qui montrera à quelle vitesse gzip peut produire des données, et ce que cela signifie pour savoir si vous devez compresser vos transferts en bloc de réseau en général.
Les données d'entrée changeront le résultat du test grandement. 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 les réseaux. En utilisant /dev/zero (produire des zéros illimités) serait trompeur car un flux de zéros serait très facile à compresser et utiliser /dev/random serait trompeur pour la raison opposée. Au lieu de cela, j'utilise un fichier tar de mon $HOME/local répertoire, qui contient les logiciels que j'ai installés dans mon $HOME. Le fichier n'est pas compressé en soi, mais contient un mélange de fichiers binaires, de petits fichiers compressés et de fichiers source/texte, et le compresserais-je avec le paramètre par défaut pour gzip il diminuerait de 67% de 64 Mio à 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 le fais plusieurs fois pour avoir une idée de ce que pourrait être la moyenne, et cela représente environ 7800000 octets/s.
Ensuite, j'utilise un calculateur de bande passante résea pour voir en quoi cela se transforme. Dans ce cas particulier, il se trouve être juste sous la capacité d'une liaison filaire "100Mb Ethernet", juste plus rapide qu'une liaison montante Internet "Téléchargement VDSL", 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 quoi que ce soit plus vite que cela, la compression va probablement ralentir le transfert du fichier.
rsync n'utilise peut-être pas les mêmes bibliothèques exact que gzip pour effectuer la compression, mais ce qui précède vous donnera au moins un indice.
rsync fait cependant plus que la compression, comme vous le savez, et l'augmentation de la vitesse réel vient uniquement du transfert de [bits de] fichiers qui ont changé.
D'après ma propre expérience, l'utilisation de la compression avec rsync est devenue de moins en moins bénéfique au cours des 10 dernières années, car la bande passante des réseaux a augmenté (où je suis).
Pour effectuer des sauvegardes incrémentielles, je recommanderais certainement d'enquêter sur le --link-dest option (cela n'a rien à voir avec ce qui est transféré, seulement avec la façon dont les choses sont stockées sur la cible). De plus, 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.) qui sont sur des liaisons lentes, pour les mêmes raisons que ci-dessus.