Moyen le plus rapide de copier un dossier contenant de nombreux fichiers via SSH


13

Quelle est la meilleure façon de dupliquer des fichiers sur le serveur via ssh?

Dans mon cas: je parle de la duplication de magento shop. (15000 fichiers ~ 50 Mo)

cp -a source destination

Prend des heures ... (dans mon cas, le serveur est de 2,4 Xeon, 2 Go de RAM)

Réponses:


18

Un mot: rsync.

Notez que si vous êtes sur une liaison lente, ou si le serveur est sous forte charge, l'outil utilisé pour la copie ne sera pas le goulot d'étranglement, et tout moyen de copie sera lent de toute façon.

Cela devrait vous donner l'utilisation de base pour la copie entre votre ordinateur local et le serveur distant: http://oreilly.com/pub/h/38

Pour copier depuis un ordinateur local vers un serveur distant (vous devez bien sûr remplacer les chemins, le nom d'utilisateur et l'adresse d'hôte):

rsync -avz -e ssh /path/on/local/computer remoteuser@remotehost.somewhere.example.com:/path/on/server
  • -a archiver
  • -v verbeux
  • -z compresse
  • -e ssh "utiliser un tunnel SSH"

Pour copier dans l'autre sens, changez de chemin (le premier est de , le second est de ):

rsync -avz -e ssh remoteuser@remotehost.somewhere.example.com:/path/on/server /path/on/local/computer

Mais rsync est utile même pour copier des choses sur le même serveur:

rsync -av /path-to/copy/from /path_to/copy/to

2
Notez que @Piskvor a omis l' -zoption pour la copie locale car elle ajoute une surcharge inutile. À mon humble avis, vous ne devez utiliser que -zlorsque vous utilisez rsync sur une liaison réseau lente. Si vous copiez de grandes quantités de données sur 100Base-T, vous pouvez très bien vous en passer -z. Avec une connexion réseau rapide, l'utilisation de la compression peut ancrer votre CPU et affaiblir d'autres processus.
tomlogic

@tomlogic: Bon point - en d'autres termes, ne pas utiliser -zpour la copie LAN ou la copie sur une seule machine; tester avec et sans -zpour la copie sur Internet (l'un ou l'autre peut être plus rapide, en fonction de beaucoup de choses).
Piskvor a quitté le bâtiment le

1
Je laisserais également de côté la compression si vous savez que vos fichiers sont déjà compressés, comme la synchronisation d'une arborescence de dossiers remplie de JPEG car il n'y a rien à gagner.
rupture de ligne

Remarque: -e sshest maintenant par défaut pour les hôtes distants, il n'est donc pas nécessaire de passer l'option explicitement.
Piskvor a quitté le bâtiment le

3

Un autre mot: scp

scp /path/on/local/computer remoteuser@remotehost.somewhere.example.com:/path/on/server

Pour les offres uniques, scp est pratique. Si c'est beaucoup de fichiers, rsync est une bonne idée. Si une connexion est interrompue, rsync peut reprendre là où il s'était arrêté.

Je savais que rsync avait compression ( -z), et je viens d'apprendre que scp aussi ( -C).


Eh bien, l'IIRC utilise tous les deux les algorithmes de compression de SSH, au moins pour les opérations réseau.
Piskvor a quitté le bâtiment

0

Dans votre configuration, rsync est probablement suffisant ... mais à titre d'exemple, s'il y a beaucoup de petits fichiers, il peut être plus rapide de tarer les fichiers d'abord que de les transférer ensuite via rsync. En effet, le transfert du propriétaire, des horodatages et des autorisations est parfois plus lourd que le fichier lui-même si le fichier est petit. Tar fusionnera toutes ces informations dans un seul fichier et rsync copiera des blocs plus gros.

Ou encore mieux, si aucune sécurité n'est nécessaire, utilisez tar et nc:

À destination, préparez un démon de réception, décompressez et décompressez:

nc -l -p 12345 | pigz -d | tar xvf - 

Sur la source, tarez tout, compressez en parallèle et envoyez-le à la destination:

tar cvf - ./ | pigz | nc host 12345
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.