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

J'ai une tonne de petits fichiers de données de relativité mais ils prennent environ 50 Go et j'ai besoin qu'ils soient transférés sur une autre machine. J'essayais de penser à la façon la plus efficace de le faire.

Les pensées que j'avais étaient de gziper le tout, puis de le resynchroniser et de le décompresser, de s'appuyer sur rsync -z pour la compression, de gzip puis d'utiliser rsync -z. Je ne sais pas lequel serait le plus efficace car je ne sais pas exactement comment rsync -z est implémenté. Des idées sur quelle option serait la plus rapide?

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

La question est donc: est-il préférable de stocker le fichier dont j'ai besoin pour rsync gziped ou 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 gérer le fichier gzip avant de faire le rsync.

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

Quoi qu'il en soit, pour répondre à la question, rsync gzip sera un peu moins efficace que gziping 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 utilisera pour faire la compression, un plus grand ensemble de données (gzip utiliserait le fichier entier à la fois) donnera une meilleure table de compression. Mais la différence sera très très petite 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 gros fichier avec un très long partern répétant plusieurs fois sur le fichier mais loin les uns des autres) (c'est un exemple très simplifié)

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, car vous avez de nombreux fichiers), vous pouvez essayer quelque chose comme:

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

Cela obtiendrait la compression que vous recherchez et copierait directement sans impliquer rsync.

@radius, un petit truc à comprendre sur le gzipfonctionnement - gzipest un algorithme de compression basé sur des blocs, et assez simple à cela. Le fichier entier n'est pas pris en compte pour la table de compression - seulement chaque bloc. D'autres algorithmes peuvent utiliser l'intégralité du contenu du fichier et certains utilisent le contenu de plusieurs blocs ou même de blocs de taille variable. Un exemple fascinant est lrzip, du même auteur que rsync!

L' gzipalgorithme de skinny on .

Donc, en résumé, l'utilisation rsync -zproduira probablement la même compression que gziping en premier - et si vous effectuez un transfert différentiel, mieux à cause de rsyncl'algorithme différent de.

Cela dit, je pense que l'on trouvera que les scpbattements réguliers et pratiques rsyncpour les transferts non différentiels - car il aura beaucoup moins de frais généraux que rsyncl'algorithme de (qui utiliserait de toute façon scpsous le capot!)

Si votre réseau ne devienne un goulot d' étranglement, alors vous voulez utiliser la compression sur le fil.

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

Habituellement, si la vitesse est essentielle, la compression préalable d'un fichier existant est un gaspillage.

TIMTOWTDI, YMMV, IANAL, etc.

Selon ce type, il pourrait être plus rapide à utiliser rsync -z, même si je suppose que ce serait presque aussi efficace que de compresser chaque fichier avant de le transférer. Cela devrait être plus rapide que la compression du flux de goudron, comme suggéré par d'autres.

Depuis 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 scp du fichier compressé et rsync prendront des temps de transfert très similaires, la «façon la plus efficace de le faire» serait la compression à la volée plutôt que la compression, le transfert.

En plus de la «solidité», d'autres considérations incluent:

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

rsync peut être utilisé pour gérer 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) qui peut ne pas être acceptable. 2) Port 873 des utilisateurs rsync (par défaut)

Je ne sais pas pourquoi radius s'attend à ce que l'affiche originale ne veuille PAS stocker les fichiers décompressés.