Comment copier rapidement un grand nombre de fichiers entre deux serveurs

Question

J'ai besoin de transférer une énorme quantité de mp3 entre deux serveurs (Ubuntu). Par énorme, je veux dire environ un million de fichiers qui sont en moyenne 300K. J'ai essayé avec scp mais cela aurait pris environ une semaine. (environ 500 Ko/s) Si je transfère un seul fichier par HTTP, j'obtiens 9 à 10 Mo/s, mais je ne sais pas comment les transférer tous.

Existe-t-il un moyen de les transférer tous rapidement?

Answer 1

Je recommanderais le goudron. Lorsque les arborescences de fichiers sont déjà similaires, rsync fonctionne très bien . Cependant, puisque rsync effectuera plusieurs passes d'analyse sur chaque fichier, puis copiera les modifications, il est beaucoup plus lent que tar pour la copie initiale. Cette commande fera probablement ce que vous voulez. Il copiera les fichiers entre les machines et préservera à la fois les autorisations et les propriétés des utilisateurs/groupes.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Selon le commentaire de Mackintosh ci-dessous, c'est la commande que vous utiliseriez pour rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Answer 2

Disque dur externe et livraison par messagerie le jour même.

Answer 3

J'utiliserais rsync.

Si vous les avez exportés via HTTP avec des listes de répertoires disponibles, vous pouvez également utiliser wget et l'argument --mirror.

Vous voyez déjà que HTTP est plus rapide que SCP parce que SCP crypte tout (et donc goulot d'étranglement sur le CPU). HTTP et rsync vont se déplacer plus rapidement car ils ne chiffrent pas.

Voici quelques documents sur la configuration de rsync sur Ubuntu: https://help.ubuntu.com/community/rsync

Ces documents parlent de tunneling rsync sur SSH, mais si vous déplacez simplement des données sur un LAN privé, vous n'avez pas besoin de SSH. (Je suppose que vous êtes sur un réseau local privé. Si vous obtenez 9-10 Mo/s sur Internet, je veux savoir quel type de connexion vous avez!)

Voici quelques autres documents très basiques qui vous permettront de configurer un serveur rsync relativement non sécurisé (sans dépendance vis-à-vis de SSH): http://transamrit.net/docs/rsync/

Answer 4

Sans trop de discussion, utilisez netcat, couteau suisse de réseau. Pas de surcharge de protocole, vous copiez directement sur la prise réseau. Exemple

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

Answer 5

Avec beaucoup de fichiers si vous optez pour rsync, j'essaierais d'obtenir la version 3 ou supérieure aux deux extrémités. La raison étant qu'une version inférieure énumérera chaque fichier avant de commencer le transfert. La nouvelle fonctionnalité est appelée récursion incrémentielle .

Un nouvel algorithme de récursivité incrémentielle est désormais utilisé lorsque rsync parle avec une autre version 3.x. Cela démarre le transfert plus rapidement (avant que tous les fichiers aient été trouvés) et nécessite beaucoup moins de mémoire. Voir l'option --recursive dans la page de manuel pour certaines restrictions.

Answer 6

rsync, comme d'autres l'ont déjà recommandé. Si la surcharge CPU du cryptage est un goulot d'étranglement, utilisez un autre algorithme moins gourmand en CPU, comme Blowfish. Par exemple. quelque chose comme

rsync -ax -e 'ssh -c blowfish' /local/path user@Host:/remote/path

Answer 7

En déplaçant 80 TB de données (millions de petits fichiers) hier, le passage de rsync à tars'est avéré beaucoup plus rapide , comme nous avons cessé d'essayer

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

et je suis passé à tar à la place ...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

Étant donné que ces serveurs sont sur le même réseau local, la destination est montée sur NFS sur le système source, qui effectue le Push. Non, faites encore plus vite, nous avons décidé de ne pas conserver le atime des fichiers:

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

Le graphique ci-dessous illustre la différence entre le changement de rsync et tar. C'était mon idée de patron et mon collègue l'ont exécutée et ont fait le grand écrit sur son blog . J'aime juste jolies images . :)

Answer 8

Lors de la copie d'un grand nombre de fichiers, j'ai constaté que des outils tels que tar et rsync sont plus inefficaces qu'ils ne devraient l'être en raison des frais généraux d'ouverture et de fermeture de nombreux fichiers. J'ai écrit un outil open source appelé fast-archiver qui est plus rapide que tar pour ces scénarios: https://github.com/replicon/fast-archiver ; il fonctionne plus rapidement en effectuant plusieurs opérations de fichiers simultanées.

Voici un exemple d'archiveur rapide vs tar sur une sauvegarde de plus de deux millions de fichiers; l'archivage rapide prend 27 minutes pour archiver, tandis que tar prend 1 heure 23 minutes.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Pour transférer des fichiers entre des serveurs, vous pouvez utiliser l'archiveur rapide avec ssh, comme ceci:

ssh [email protected] "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

Answer 9

J'utilise également l'approche tar through netcat, sauf que je préfère utiliser socat - beaucoup plus de puissance pour optimiser votre situation - par exemple, en modifiant mss. (Riez aussi si vous voulez, mais je trouve que les arguments socat sont plus faciles à retenir car ils sont cohérents). Donc pour moi, c'est très courant ces derniers temps car j'ai déplacé des choses vers de nouveaux serveurs:

Host1$ tar cvf - filespec | socat stdin tcp4:Host2:portnum

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

Les alias sont facultatifs.

Answer 10

• Système de fichiers réseau (NFS) puis copiez-les avec ce que vous voulez, par ex. Midnight Commander (mc), Nautilus (de gnome). J'ai utilisé NFS v3 avec de bons résultats.
• Samba (CIFS) puis copiez les fichiers avec ce que vous voulez, mais je n'ai aucune idée de son efficacité.
• [~ # ~] http [~ # ~] avec wget --mirror as Evan Anderson a suggéré ou tout autre client http. Faites attention à 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 de très bons résultats et l'une de ses fonctionnalités 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. Basé sur mon expérience avec lui, je peux dire que c'est lent par rapport aux autres solutions.

Answer 11

On dirait qu'il peut y avoir quelques fautes de frappe dans la réponse du haut. Cela peut mieux fonctionner:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'

Answer 12

Grâce à la merveilleuse réponse de Scott Pack (je ne savais pas comment faire 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é de la liaison 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 programme Nice Viewer de progression pour votre pipe et pigz est un programme gzip parallèle qui utilise autant de threads que votre CPU en a par défaut (je crois jusqu'à 8 max). Vous pouvez régler le niveau de compression pour mieux adapter le rapport CPU/bande passante réseau et le remplacer par pxz -9e et pxz -d si vous avez beaucoup plus de CPU que de bande passante. Il vous suffit de vérifier que les deux sommes correspondent à la fin.

Cette option est utile pour de très grandes quantités de données ainsi que pour les réseaux à latence élevée, 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 périphériques 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 limite avec count =, skip =, Seek =, etc.

Lorsque je copie des systèmes de fichiers de cette façon, je vais souvent d'abord dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs pour mettre à zéro la majeure partie de l'espace inutilisé, ce qui accélère le xfer.

Answer 13

Une autre alternative est nison . Peut être légèrement plus efficace que Rsync dans ce cas, et il est un peu plus facile de configurer un écouteur.

Answer 14

Vous n'avez pas mentionné si les deux machines sont sur le même réseau local ou si un canal sécurisé (c'est-à-dire en utilisant SSH) est obligatoire, mais un autre outil que vous pourriez utiliser est netcat .

J'utiliserais ce qui suit sur la machine réceptrice:

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

Puis côté envoi:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

Il présente les avantages suivants:

• Pas de surcharge CPU pour le chiffrement que possède ssh.
• Le gzip -1 fournit une compression légère sans saturer un processeur, ce qui fait un bon compromis, donnant un peu de compression tout en maintenant un débit maximal. (Probablement pas avantageux pour les données MP3, mais ça ne fait pas de mal.)
• Si vous pouvez partitionner les fichiers en groupes, vous pouvez exécuter deux canaux ou plus en parallèle et vraiment vous assurer de saturer votre bande passante réseau.

par exemple.,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

Remarques:

• Quelle que soit la façon dont vous transférez, je ferais probablement un rsync ou nisson après pour vous assurer que vous avez tout.
• Vous pouvez utiliser tar au lieu de cpio si vous préférez.
• Même si vous finissez par utiliser ssh, je m'assurerais qu'il n'utilise pas lui-même de compression et que je passe par gzip -1 vous-même à la place pour éviter la saturation du processeur. (Ou au moins définissez CompressionLevel sur 1.)

Answer 15

Si vous avez un serveur ftp côté src, vous pouvez utiliser ncftpget depuis site ncftp . Il fonctionne parfaitement avec de petits fichiers car il utilise tar en interne.

Une comparaison le montre: déplacement de petits fichiers de 1,9 Go (33926 fichiers)

1. L'utilisation de scp prend 11 min 59 s
2. L'utilisation de rsync prend 7 min 10 s
3. L'utilisation de ncftpget prend 1m20s

Answer 16

Vous pouvez également essayer d'utiliser la commande BBCP pour effectuer votre transfert. C'est un ssh parallèle tamponné qui crie vraiment. Nous pouvons généralement obtenir un débit de ligne de 90% + à condition de pouvoir alimenter le tuyau.

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

Normalement, nous essayons vraiment de ne pas avoir à bouger suffisamment. Nous utilisons des pools ZFS auxquels nous pouvons toujours simplement "ajouter" plus d'espace disque. Mais parfois ... il suffit de déplacer des trucs. Si nous avons un système de fichiers "en direct" qui peut prendre des heures (ou des jours) à copier, même lorsque nous allons à fond. Nous faisons la routine d'envoi zfs en deux étapes:

1. Créez un instantané ZFS et transférez-le dans le nouveau pool sur la nouvelle machine. Laissez-le prendre aussi longtemps qu'il le faut.
2. Créez un deuxième instantané et envoyez-le en incrémentiel. L'instantané incrémentiel ne comprend que le jeu de modifications (beaucoup plus petit) depuis le premier, il passe donc relativement rapidement.
3. Une fois l'instantané incrémentiel terminé, vous pouvez désactiver l'original et passer à la nouvelle copie et votre "temps d'arrêt hors ligne" est réduit au minimum.

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

Le BBCP est disponible gratuitement, vous pouvez le rechercher sur Google, et c'est une compilation simple. Copiez-le simplement dans votre/usr/local/bin sur les machines src et de destination et cela fonctionnera à peu près.

Answer 17

Je suppose que ma réponse est un peu tardive ici, mais j'ai fait de bonnes expériences avec l'utilisation de mc (Midnight Commander) sur un serveur pour se connecter via SFTP à l'autre serveur.

L'option de connexion via FTP se trouve dans les menus "Gauche" et "Droite", en entrant l'adresse comme ceci:

/#ftp:[email protected]/

ou

/#ftp:[email protected]/

Vous pouvez naviguer et effectuer des opérations sur les fichiers presque comme sur un système de fichiers local.

Il a une option intégrée pour faire la copie en arrière-plan, mais je préfère utiliser la commande screen et se détacher de l'écran pendant que mc copie (je pense que ça tourne plus vite aussi).

Answer 18

À @scottpack réponse de l'option rSync

Pour afficher la progression du téléchargement, utilisez '--progess' comme option après -avW dans la commande comme indiqué ci-dessous.

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Answer 19

Un scp simple avec les options appropriées atteindra facilement 9-10 Mo/s sur LAN:

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

Avec ces options, il est probable que le débit est devenu 4x ou 5x plus rapide qu'aucune option (par défaut)

Answer 20

Je ne pense pas que vous ferez mieux que scp, sauf si vous installez des cartes réseau plus rapides. Si vous faites cela sur Internet, cela ne vous aidera pas.

Je recommanderais d'utiliser rsync. Ce n'est peut-être pas plus rapide, mais au moins s'il échoue (ou si vous l'arrêtez parce que cela prend trop de temps), vous pouvez reprendre là où vous vous étiez arrêté la prochaine fois.

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

Answer 21

Pour 100 Mo/s, le débit théorique est de 12,5 Mo/s, donc à 10 Mo/s, vous vous débrouillez plutôt bien.

Je voudrais également faire écho à la suggestion de faire rsync, probablement via ssh. Quelque chose comme:

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

À 100 Mo/s, vos processeurs devraient être capables de gérer le chiffrement/déchiffrement sans affecter sensiblement le débit de données. Et si vous interrompez le flux de données, vous devriez pouvoir reprendre là où vous vous étiez arrêté. Attention, avec des "millions" de fichiers, le démarrage prendra un certain temps avant de transférer quoi que ce soit.

Answer 22

Je l'ai rencontré, sauf que je transférais des journaux Oracle.

Voici la ventilation

• scp

  inefficient and encrypted (encrypted = slower than unencrypted 
  depending on the link and your processor) 
  

• rsync

  efficient but typically encrypted (though not necessarily)
  

• FTP/HTTP

  both seem to be efficient, and both are plaintext. 
  

J'ai utilisé FTP avec beaucoup de succès (où un grand succès équivaut à ~ 700Mb/s sur un réseau Gb). Si vous obtenez 10 Mo (ce qui équivaut à 80 Mo/s), quelque chose ne va probablement pas.

Que pouvez-vous nous dire sur la source et la destination des données? S'agit-il d'un seul lecteur à un seul lecteur? RAID vers USB?

Je sais que cette question a déjà une réponse, mais si votre réseau va si lentement sur un câble croisé Gb/s, quelque chose doit absolument être corrigé.

Answer 23

Voici une référence rapide pour comparer certaines techniques,

• La source est un processeur Intel (R) Xeon (R) à 4 cœurs E5-1620 à 3,60 GHz avec 250 Mbps et un lecteur SATA
• La destination est un processeur Intel (R) Xeon (R) à 6 cœurs E-2136 à 3,30 GHz avec une bande passante de 1 Gbit/s et un disque SSD

Nombre de fichiers: 9632, Taille totale: 814 Mio, Taille moyenne: 84 Kio

• RSYNC: 1m40.570s
• RSYNC + COMPRESSION: 0m26.519s
• TAR + NETCAT: 1m58.763s
• TAR + COMPRESSION + NETCAT: 0m28.009s

La commande pour tar/netcat était:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -

Answer 24

Si vous envoyez des fichiers MP3 et autres fichiers compressés, vous ne tirerez pas grand-chose d'une solution qui tente de compresser davantage ces fichiers. La solution serait quelque chose qui peut créer plusieurs connexions entre les deux serveurs et ainsi mettre davantage l'accent sur la bande passante entre les deux systèmes. Une fois que cela est au maximum, il n'y a pas grand-chose à gagner sans améliorer votre matériel. (Des cartes réseau plus rapides entre ces serveurs, par exemple.)

Answer 25

J'ai dû copier le disque BackupPC sur une autre machine.

J'ai utilisé rsync.

La machine avait 256 Mo de mémoire.

La procédure que j'ai suivie était celle-ci:

• exécutée rsync sans -H (a pris 9 heures)
• une fois rsync terminé, j'ai synchronisé le répertoire cpool et j'ai commencé avec le répertoire pc; J'ai coupé le transfert.
• puis redémarré rsync avec -H, et tous les fichiers liés en dur dans le répertoire pc ont été correctement transférés (la procédure a trouvé tous les fichiers réels dans cpool et ensuite liés au répertoire pc) ( a pris 3 heures).

Au final, j'ai pu vérifier avec df -m qu'aucun espace supplémentaire n'a été dépensé.

De cette façon, j'élude le problème avec la mémoire et rsync. Tout le temps, je peux vérifier les performances en utilisant le haut et le haut et finalement j'ai transféré 165 Go de données.

Answer 26

J'ai essayé quelques outils pour copier un fichier de 1 Go Le résultat est ci-dessous: HTTP le plus rapide, avec wget -c nc seconde en ligne scp le plus lent, et a échoué quelques fois. Pas moyen de reprendre rsync utilise ssh comme backend, donc le même résultat. En conclusion, j'irais pour http avec wget -bqc et lui donnerais un peu de temps. J'espère que cela aide

Answer 27

rsync ou vous souhaiterez peut-être le tar afin qu'il soit tout dans un seul fichier, puis scp. Si vous manquez d'espace disque, vous pouvez diriger le goudron directement sur ssh pendant sa création.