Je me retrouve souvent à envoyer des dossiers contenant entre 10 000 et 100 000 fichiers vers une machine distante (au sein du même réseau sur le campus).

Je me demandais juste s'il y avait des raisons de croire que,

 tar + rsync + untar

Ou simplement

 tar (from src to dest) + untar

pourrait être plus rapide dans la pratique que

rsync 

lors du transfert des fichiers pour la première fois .

Je suis intéressé par une réponse qui aborde ce qui précède dans deux scénarios: utiliser la compression et ne pas l'utiliser.

Mise à jour

Je viens d'exécuter quelques expériences en déplaçant 10 000 petits fichiers (taille totale = 50 Mo), et j'étais tar+rsync+untartoujours plus rapide que de l'exécuter rsyncdirectement (les deux sans compression).

Lorsque vous envoyez le même ensemble de fichiers, rsyncest mieux adapté car il n'enverra que des différences. tarenverra toujours tout et c'est un gaspillage de ressources quand beaucoup de données sont déjà là. Le tar + rsync + untarperd cet avantage dans ce cas, ainsi que l'avantage de garder les dossiers synchronisés avec rsync --delete.

Si vous copiez les fichiers pour la première fois, le premier empaquetage, puis l'envoi, puis le déballage (AFAIK rsyncne prend pas d'entrée canalisée) est lourd et toujours pire que le simple rsyncing, car il rsyncn'aura à effectuer aucune tâche plus que de tartoute façon.

Astuce: rsync version 3 ou ultérieure effectue une récursivité incrémentielle, ce qui signifie qu'il commence à copier presque immédiatement avant de compter tous les fichiers.

Astuce 2: Si vous utilisez rsyncplus ssh, vous pouvez également utiliser soittar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

ou juste scp

scp -Cr srcdir user@server:destdir

Règle générale, restez simple.

MISE À JOUR:

J'ai créé 59 millions de données de démonstration

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

et testé plusieurs fois le transfert de fichiers vers un serveur distant (pas dans le même lan), en utilisant les deux méthodes

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

tout en conservant des journaux distincts des paquets de trafic ssh envoyés

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

Dans ce cas, je ne vois aucun avantage à réduire le trafic réseau en utilisant rsync + tar, ce qui est attendu lorsque le mtu par défaut est de 1500 et que les fichiers ont une taille de 10k. rsync + tar a généré plus de trafic, a été plus lent pendant 2-3 secondes et a laissé deux fichiers d'ordures qui ont dû être nettoyés.

J'ai fait les mêmes tests sur deux machines sur le même lan, et là le rsync + tar a fait des temps bien meilleurs et beaucoup moins de trafic réseau. Je suppose que la cause des trames jumbo.

Peut-être que rsync + tar serait mieux que juste rsync sur un ensemble de données beaucoup plus grand. Mais franchement, je ne pense pas que cela en vaille la peine, vous avez besoin d'un double espace de chaque côté pour l'emballage et le déballage, et il y a quelques autres options comme je l'ai déjà mentionné ci-dessus.

rsyncfait également la compression. Utilisez le -zdrapeau. En cas de dépassement ssh, vous pouvez également utiliser le mode de compression de ssh. Mon sentiment est que des niveaux de compression répétés ne sont pas utiles; il ne fera que graver des cycles sans résultat significatif. Je recommanderais d'expérimenter la rsynccompression. Cela semble assez efficace. Et je suggère de sauter l'utilisation de tarou toute autre compression pré / post.

J'utilise habituellement rsync as rsync -abvz --partial....

J'ai dû sauvegarder mon répertoire personnel sur NAS aujourd'hui et suis tombé sur cette discussion, j'ai pensé ajouter mes résultats. Pour faire court, tarer sur le réseau vers le système de fichiers cible est beaucoup plus rapide dans mon environnement que de rsynchroniser vers la même destination.

Environnement: ordinateur source i7 de bureau utilisant un disque dur SSD. Synology NAS DS413j de la machine de destination sur une connexion LAN gigabit à la machine source.

La spécification exacte du kit impliqué aura un impact sur les performances, naturellement, et je ne connais pas les détails de ma configuration exacte en ce qui concerne la qualité du matériel réseau à chaque extrémité.

Les fichiers source sont mon dossier ~ / .cache qui contient 1,2 Go de fichiers pour la plupart très petits.

1a/ tar files from source machine over the network to a .tar file on remote machine

$ tar cf /mnt/backup/cache.tar ~/.cache

1b/ untar that tar file on the remote machine itself

$ ssh admin@nas_box
[admin@nas_box] $ tar xf cache.tar

2/ rsync files from source machine over the network to remote machine

$ mkdir /mnt/backup/cachetest
$ rsync -ah .cache /mnt/backup/cachetest

J'ai gardé 1a et 1b comme des étapes complètement séparées juste pour illustrer la tâche. Pour des applications pratiques, je recommanderais ce que Gilles a publié ci-dessus concernant la sortie de goudron de tuyauterie via ssh à un processus de non-tarage sur le récepteur.

Calendrier:

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

Il est très clair que rsync a fonctionné de manière étonnamment médiocre par rapport à une opération tar, ce qui peut probablement être attribué aux performances du réseau mentionnées ci-dessus.

Je recommande à quiconque souhaite sauvegarder de grandes quantités de fichiers pour la plupart de petite taille, comme une sauvegarde du répertoire personnel, d'utiliser l'approche tar. rsync semble un très mauvais choix. Je reviendrai sur ce post s'il semble que j'ai été inexact dans l'une de mes procédures.

Entaille

Utiliser rsync pour envoyer une archive tar comme demandé serait en fait un gaspillage ou des ressources, car vous ajouteriez une couche de vérification au processus. Rsync serait la somme de contrôle du fichier tar pour l'exactitude, lorsque vous préférez avoir la vérification sur les fichiers individuels. (Cela n'aide pas de savoir que le fichier tar qui peut avoir été défectueux du côté de l'envoi montre déjà le même effet sur le côté de réception). Si vous envoyez une archive, ssh / scp est tout ce dont vous avez besoin.

La seule raison pour laquelle vous pourriez avoir à sélectionner l'envoi d'une archive serait si le goudron de votre choix était en mesure de conserver davantage de spécificités du système de fichiers, telles que la liste de contrôle d'accès ou d'autres métadonnées souvent stockées dans des attributs étendus (Solaris) ou Ressource Forks (MacOS). ). Lorsque vous traitez de telles choses, votre principale préoccupation sera de savoir quels outils sont capables de conserver toutes les informations associées au fichier sur le système de fichiers source, à condition que le système de fichiers cible ait également la possibilité de les suivre.

Lorsque la vitesse est votre principale préoccupation, cela dépend beaucoup de la taille de vos fichiers. En général, une multitude de minuscules fichiers évolueront mal sur rsync ou scp, car ils gaspilleront tous les paquets réseau individuels chacun, où un fichier tar inclurait plusieurs d'entre eux dans la charge de données d'un seul paquet réseau. Encore mieux si le fichier tar était compressé, car les petits fichiers seraient probablement mieux compressés dans leur ensemble qu'individuellement. Pour autant que je sache, rsync et scp ne parviennent pas à optimiser lors de l'envoi de fichiers uniques entiers comme lors d'un transfert initial, chaque fichier occupant une trame de données entière avec toute sa surcharge de protocole (et gaspillant plus à vérifier avant et arrière). Cependant Janecekindique que cela n'est vrai que pour scp, précisant que rsync optimiserait le trafic réseau, mais au prix de la construction d'énormes structures de données en mémoire. Voir l'article Efficient File Transfer, Janecek 2006 . Donc, selon lui, il est toujours vrai que scp et rsync évoluent mal sur de petits fichiers, mais pour des raisons entièrement différentes. Je suppose que je vais devoir fouiller dans les sources ce week-end pour le savoir.

Pour des raisons pratiques, si vous savez que vous envoyez principalement des fichiers plus volumineux, il n'y aura pas beaucoup de différence de vitesse, et l'utilisation de rsync a l'avantage supplémentaire de pouvoir reprendre là où il s'est arrêté en cas d'interruption.

Post-scriptum: De nos jours, rdist semble sombrer dans l'oubli, mais avant les jours de rsync, c'était un outil très performant et largement utilisé (en toute sécurité lorsqu'il est utilisé sur ssh, dangereux autrement). Je ne ferais pas aussi bien que rsync car il ne s'optimisait pas pour transférer uniquement le contenu qui avait changé. Sa principale différence avec rsync réside dans la façon dont il est configuré et comment les règles de mise à jour des fichiers sont énoncées.

Pour les petits répertoires (petits comme dans l'espace disque utilisé), cela dépend de la surcharge de vérification des informations sur les fichiers à synchroniser. D'une part, rsyncéconomise le temps de transfert des fichiers non modifiés, d'autre part, il doit en effet transférer des informations sur chaque fichier.

Je ne connais pas exactement les internes de rsync. Que les statistiques des fichiers entraînent un retard dépend de la façon dont les rsyncdonnées sont transférées - si les statistiques des fichiers sont transférées une par une, le RTT peut accélérer tar + rsync + untar.

Mais si vous avez, disons 1 Gio de données, rsync sera bien plus rapide, à moins que votre connexion ne soit vraiment rapide!

J'ai dû déplacer quelques téraoctets de données à travers le pays, exactement une fois. À titre d'expérience, j'ai exécuté deux des transferts à l'aide de rsyncet ssh/tarpour voir comment ils se comparent.

Les resultats:

• rsync transféré les fichiers à un taux moyen de 2,76 mégaoctets par seconde.
• ssh/tar transféré les fichiers à un taux moyen de 4,18 mégaoctets par seconde.

Les détails: Mes données se composent de millions de fichiers compressés .gz, dont la taille moyenne est de 10 mégaoctets, mais certains dépassent un gigaoctet. Il existe une structure de répertoires mais elle est éclipsée par la taille des données à l'intérieur des fichiers. Si j'avais eu autre chose à faire, je n'aurais utilisé rsyncque dans ce cas, ssh/tarc'est une solution fonctionnelle.

Mon travail avec rsyncconsiste en:

rsync --compress --stats --no-blocking-io --files-from=fileList.txt -av otherSystem:/the/other/dir/ dest/

où fileList.txt est une grande longue liste des chemins relatifs des fichiers de l'autre côté. (J'ai remarqué que le --compressn'est pas productif pour les fichiers compressés après avoir commencé mais je n'allais pas revenir en arrière.)

J'en ai commencé une autre avec ssh et tar qui a:

ssh otherSystem "cd /the/other/dir/;  tar cf - ." | tar xvf -

Vous observerez que cela copie tout, désolé ce n'est pas une comparaison 100% pommes à pommes.

Je dois ajouter que lorsque j'utilise le réseau interne de l'entreprise, je dois passer par un intermédiaire pour accéder à l'ordinateur source de données. Le temps de ping de mon ordinateur cible à l'intermédiaire est de 21 ms et de l'intermédiaire à la source de données est de 26 ms. C'était la même chose pour les deux transferts.

La connexion SSL par l'intermédiaire se fait via l' ~/.ssh/configentrée:

Host otherSystem
    Hostname dataSource.otherSide.com
    User myUser
    Port 22
    ProxyCommand ssh -q -W %h:%p intermediary.otherSide.com
    IdentityFile   id_rsa.priv

Temps ceci:

tar cf - ~/.cache | ssh admin@nas_box "(cd /destination ; tar xf -)"