Pour les gros fichiers, compressez d'abord puis transférez ou rsync -z ? lequel serait le plus rapide ?

Vous ne pouvez pas "gziper le tout" car gzip ne compresse qu'un seul fichier, vous pourriez créer un fichier tar et le gziper pour "gziper le tout" mais vous perdriez la capacité de rsync de copier uniquement le fichier modifié.

La question est donc la suivante : est-il préférable de stocker le fichier dont j'ai besoin pour rsync de manière gzipée ou de compter sur l'option -z de rsync.
La réponse est probablement que vous ne voulez pas que le fichier soit décompressé sur votre serveur ? Je suppose que oui, donc je ne vois pas comment vous pourriez réussir à gzipper le fichier avant de faire le rsync.

Peut-être n'avez-vous pas besoin de la capacité de rsync à copier uniquement les fichiers modifiés ? Dans ce cas, pourquoi utiliser rsync au lieu de faire un scp d'un fichier tar.gz contenant vos données ?

Quoi qu'il en soit, pour répondre à la question, rsync gzip sera un peu moins efficace que la compression de fichiers avec gzip. Pourquoi ? parce que rsync gzipera les données morceau par morceau, donc un plus petit ensemble de données sera utilisé pour créer la table que gzip utilise pour faire la compression, un plus grand ensemble de données (gzip utiliserait le fichier entier en une fois) donne une meilleure table de compression. Mais la différence sera très très faible dans la plupart des cas, mais dans de très rares cas, la différence peut être plus importante (si vous avez un très grand fichier avec de très longs motifs qui se répètent plusieurs fois dans le fichier mais très loin les uns des autres) (Ceci est un exemple très simplifié).

@radius, une petite remarque à faire sur la manière dont gzip travaille - gzip est un algorithme de compression basé sur les blocs, et un algorithme assez simple. Le fichier entier n'est pas pris en compte dans la table de compression - seulement chaque bloc. D'autres algorithmes peuvent utiliser l'intégralité du contenu du fichier et il en existe quelques-uns qui utilisent le contenu de plusieurs blocs ou même de blocs de taille variable. Un exemple fascinant est lrzip par le même auteur que rsync !

Le point sur gzip L'algorithme de l'UE .

Donc, en résumé, en utilisant rsync -z donnera probablement le même compression comme gzip d'abord - et si vous faites un transfert différentiel, c'est mieux à cause de rsync L'algorithme de différenciation de l'UE.

Cela dit, je pense que l'on trouvera que les réguliers scp bat facilement rsync pour les transferts non différentiels - parce qu'il aura beaucoup moins de frais généraux que les rsync (qui utiliserait l'algorithme de scp sous le capot en tout cas !)

Si votre réseau hace devient un goulot d'étranglement, il faut alors utiliser la compression sur le fil.

Si votre disques sont le goulot d'étranglement, c'est là que le streaming dans un fichier compressé serait le mieux. (par exemple, netcat d'une machine à l'autre, en passant par gzip -c )

En général, si la vitesse est essentielle, la compression préalable d'un fichier existant est un gaspillage.

TIMTOWTDI, YMMV, IANAL, etc.

Si vous ne copiez les données qu'une seule fois, rsync ne sera pas une grande victoire en soi. Si vous aimez gzip, (ou tar+gzip, puisque vous avez beaucoup de fichiers), vous pouvez essayer quelque chose comme :

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

Cela permettrait d'obtenir la compression que vous recherchez et de copier directement sans impliquer rsync.

Según ce type il est peut-être plus rapide d'utiliser rsync -z Mais je pense que ce serait presque aussi efficace que de compresser chaque fichier avant de le transférer. Cela devrait être plus rapide que de compresser le flux tar, comme suggéré par d'autres.

De la page de manuel :

          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.

Étant donné que le scp du fichier compressé et le rsync prendront des temps de transfert très similaires, la "façon la plus efficace de faire cela" serait la compression à la volée plutôt que la compression, le transfert.

En plus de la "solidité", d'autres considérations sont à prendre en compte :

rsync peut être facilement redémarré si tous les fichiers ne sont pas transférés.

rsync peut être utilisé pour maintenir les fichiers sur la machine distante.

tar ou gzip local nécessite un espace local.

Considérations sur l'utilisation des ports pour la machine cible et les pare-feu : 1) scp utilise le port 22 (par défaut), ce qui peut ne pas être acceptable. 2) rsync utilise le port 873 (par défaut).

Je ne sais pas pourquoi le rayon s'attend à ce que l'affiche originale ne veuille PAS que les fichiers décompressés soient stockés.