Comment copier rapidement un grand nombre de fichiers entre deux serveurs ?

J'utilise le goudron à travers netcat également, sauf que je préfère utiliser socat -- beaucoup plus de pouvoir pour optimiser votre situation -- par exemple, en modifiant les textes. socat arguments plus faciles à retenir parce qu'ils sont cohérents). Donc, pour moi, c'est très très fréquent ces derniers temps car je déplace des choses sur de nouveaux serveurs :

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Les alias sont facultatifs.

• Système de fichiers réseau (NFS) et ensuite les copier avec ce que vous voulez, par exemple Midnight Commander (mc), Nautilus (de gnome). J'ai utilisé NFS v3 avec de bons résultats.
• Samba (CIFS) et ensuite copier les fichiers avec ce que vous voulez, mais je n'ai aucune idée de l'efficacité de cette méthode.
• HTTP avec wget --mirror como Evan Anderson a suggéré ou tout autre client http. Veillez à ne pas avoir de liens symboliques désagréables ou de fichiers d'index trompeurs. Si vous n'avez que des MP3, vous devriez être en sécurité.
• rsync . Je l'ai utilisé avec d'assez bons résultats et l'une de ses caractéristiques intéressantes est que vous pouvez interrompre et reprendre le transfert plus tard.

J'ai remarqué que d'autres personnes ont recommandé d'utiliser netcat . Sur la base de mon expérience avec elle, je peux dire qu'elle est lente par rapport aux autres solutions.

Vous pouvez également essayer d'utiliser la commande BBCP pour effectuer votre transfert. Il s'agit d'un ssh parallèle tamponné qui crie vraiment. Nous pouvons généralement obtenir un taux de transfert de plus de 90 %, à condition de pouvoir alimenter le tube.

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

Normalement, nous essayons vraiment d'éviter d'avoir à déplacer de la souffrance. Nous utilisons des pools ZFS auxquels nous pouvons toujours "ajouter" de l'espace disque. Mais parfois... il faut simplement déplacer des choses. Si nous avons un système de fichiers "vivant" qui peut prendre des heures (ou des jours) pour être copié, même à pleine puissance, nous faisons la bonne vieille routine d'envoi ZFS en deux étapes :

1. Faites un snapshot ZFS, et transférez-le vers le nouveau pool sur la nouvelle machine. Laissez-le prendre le temps qu'il faut.
2. Faites un deuxième cliché, et envoyez-le en tant qu'incrémentiel. L'instantané incrémentiel n'inclut que l'ensemble des changements (beaucoup plus petits) survenus depuis le premier instantané, ce qui permet un traitement relativement rapide.
3. Une fois que l'instantané incrémentiel est terminé, vous pouvez éteindre l'original et passer à la nouvelle copie, ce qui réduit au minimum votre "temps d'arrêt hors ligne".

Nous envoyons également nos dumps zfs sur BBCP... cela maximise l'utilisation de notre réseau et minimise les temps de transfert.

BBCP est disponible gratuitement, vous pouvez le googler, et c'est une compilation directe. Il suffit de le copier dans votre /usr/local/bin sur les machines d'origine et de destination pour que tout fonctionne.

Grâce à la merveilleuse réponse de Scott Pack (je ne savais pas comment faire cela avec ssh auparavant), je peux offrir cette amélioration (si bash est votre Shell). Cela ajoutera une compression parallèle, un indicateur de progression et vérifiera l'intégrité à travers le lien réseau :

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pv est un joli programme de visualisation de la progression de votre pipe et de votre ordinateur. pigz est un programme gzip parallèle qui utilise par défaut autant de threads que votre CPU en possède (jusqu'à 8 maximum, je crois). Vous pouvez régler le niveau de compression pour qu'il corresponde mieux au ratio CPU/bande passante réseau et le remplacer par pxz -9e y pxz -d si vous avez beaucoup plus de CPU que de bande passante. Il suffit de vérifier que les deux sommes correspondent à l'issue du calcul.

Cette option est utile pour les très grandes quantités de données ainsi que pour les réseaux à forte latence, mais pas très utile si le lien est instable et tombe. Dans ces cas, rsync est probablement le meilleur choix car il peut reprendre.

Exemple de sortie :

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

Pour les dispositifs en bloc :

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

Évidemment, assurez-vous qu'ils sont de la même taille ou limitez-les avec count=, skip=, seek=, etc.

Lorsque je copie des systèmes de fichiers de cette façon, je commence souvent par dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs pour remettre à zéro la plupart de l'espace inutilisé, ce qui accélère le transfert.

Je ne pense pas que vous ferez mieux que scp à moins d'installer des cartes réseau plus rapides. Si vous faites cela sur Internet, cela ne vous aidera pas.

Je recommande d'utiliser rsync . Ce n'est peut-être pas plus rapide, mais au moins, en cas d'échec (ou si vous l'arrêtez parce qu'il prend trop de temps), vous pourrez reprendre là où vous en étiez la prochaine fois.

Si vous pouvez connecter les 2 machines directement en utilisant l'Ethernet gigabit, ce sera probablement le plus rapide.