Réponses:
Rsync sera évidemment plus rapide que scp si la cible contient déjà certains des fichiers source, car rsync ne copie que les différences. Mais je soupçonne que votre question portait sur la copie directe d’une cible vide.
Vous avez passé l' -zoption à rsync; cela active la compression. Si la bande passante du réseau est le facteur limitant (ce qui est souvent le cas), la compression peut améliorer considérablement la vitesse de transfert.
Vous pouvez également activer la compression avec scpen passant l' -Coption. Cela devrait à propos même des choses avec rsync. La compression n'est pas activée par défaut dans ssh car elle permet d'économiser de la bande passante, mais ajoute de la latence et de la surcharge de temps processeur la latence est mauvaise pour les sessions interactives (cela ne s'applique pas à scp), et la surcharge du processeur est inutile si les fichiers que vous copiez sont déjà compressés.
Les anciennes versions de rsyncrsh utilisant plutôt que ssh en tant que couche de transport par défaut, une comparaison équitable serait donc entre rsyncet rcp. Mais ssh est la valeur par défaut depuis la version 2.6.0 publiée le 2004-01-01.
Avec les paramètres de compression identiques, j'attendre rsyncet scpd'avoir essentiellement la même vitesse. S'il vous plaît partager des points de repère si vous trouvez le contraire.
rsync -zest toujours beaucoup plus rapide qu'avec la scpcompression suggérée dans ces réponses. Il est également plus rapide que la compression et l'archivage dans un fichier manuellement et avec scpce fichier ( scpavec une compression encore plus lente que cela). La question du PO reste donc sans réponse: avec quelle scplenteur comparé à rsync?
essayez scp rapidement
scp -p -C -o 'CompressionLevel 9' -o 'IPQoS throughput' -c arcfour machine:file .
ces options accélèrent scp 5 fois dans ma configuration par rapport à scp machine: file.
Mise à jour 2017
En réalité, scp est lent en raison d'une mauvaise gestion des détails TCP, tels que la MTU et la taille de la mémoire tampon. Heureusement, cela a été corrigé par le projet HPN SSH . À ma connaissance, vous pouvez utiliser HPN SSH comme moyen de transport pour rsync.
scp -p(conserver la date / heure) par défaut et probablement -r(récursif) scp -pr -C .... (Je viens juste de nettoyer et de relancer un travail de 40 Gb scp en utilisant ces derniers car j'ai oublié le -p)
Auparavant, c'était l'inverse, mais je pense que la vitesse de rsync s'est considérablement améliorée au cours des dernières révisions. Cela dépend également du nombre de fichiers que vous copiez. Si c'est beaucoup, rsync sera généralement plus rapide car scp génère un nouveau processus pour chaque fichier que vous copiez. Vous pouvez essayer d’affaiblir le chiffrement utilisé par scp pour voir s’il accélère. Aux dernières nouvelles, le chiffre de l'arc était le plus rapide.
Pour mes tests, rsync est plus rapide que scp , vous pouvez utiliser iotop pour les tester lors du transfert du même fichier:
sudo iotop -o
Vous obtiendrez peut-être un résultat différent, mais vous pourrez les tester vous-même. BTW, lors de l'utilisation de scp , ne pas foget pour choisir son chiffre en:
scp -c arcfour <source> <dest>
Alors que arcfourpeut accélérer le cryptage.
Recopiez-vous des fichiers par-dessus des fichiers existants? Si tel est le cas, la capacité de rsync à bloquer la comparaison et à ne copier que les différences sera pertinente.