Comment copier rapidement un grand nombre de fichiers entre deux serveurs

J'ai besoin de transférer une quantité énorme de mp3 entre deux services (Ubuntu). J'entends par énorme environ un million de fichiers qui sont en moyenne 300K. J'ai essayé avec scpmais 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 tous les transférer.

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

Je recommanderais tar. Lorsque les arborescences de fichiers sont déjà similaires, rsync fonctionne très bien. Cependant, comme rsync effectue plusieurs analyses sur chaque fichier, puis copie les modifications, le processus est beaucoup plus lent que la version initiale. Cette commande fera probablement ce que vous voulez. Il copiera les fichiers entre les ordinateurs et préservera les autorisations et les droits de propriété 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, il s'agit de la commande que vous utiliseriez pour rsync

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

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

J'utiliserais rsync.

Si vous les avez exportées 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 car SCP crypte tout (et donc des goulots d'étranglement sur le processeur). 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 rsync via tunneling sur SSH, mais si vous ne déplacez que des données sur un réseau local 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 relatif non sécurisé (sans dépendance à SSH): http://transamrit.net/docs/rsync/

Sans plus de discussion, utilisez netcat, couteau réseau swissarmy. Pas de surcharge de protocole, vous copiez directement sur le socket réseau. Exemple

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

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

Avec beaucoup de fichiers si vous utilisez rsync, j'essaierais d'obtenir la version 3 ou supérieure aux deux extrémités . La raison en est qu'une version moindre énumérera chaque fichier avant qu'il ne commence le transfert. La nouvelle fonctionnalité s'appelle incremental-récursivité .

Un nouvel algorithme de récursion incrémentielle est maintenant utilisé lorsque rsync parle à 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 connaître certaines restrictions.

rsync, comme d’autres l’ont déjà recommandé. Si le temps système lié au chiffrement constitue un goulot d'étranglement, utilisez un autre algorithme moins gourmand en ressources processeur, tel que blowfish. Quelque chose comme

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

En transférant 80 To de données (des millions de fichiers minuscules) hier, le passage de rsyncà tar s'est avéré beaucoup plus rapide , car nous avons cessé d'essayer

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

et passé à la tarplace ...

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

Étant donné que ces serveurs se trouvent sur le même réseau local, la destination est montée sur NFS sur le système source, ce qui exécute le push. Non, ne le faites pas encore plus vite, nous avons décidé de ne pas conserver le atimefichier:

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

Le graphique ci-dessous illustre la différence entre le passage de rsync à tar. C’était l’ idée de mon supérieur hiérarchique et mon collègue l’a exécutée et a rédigé un superbe article sur son blog . J'aime juste les jolies images . :)

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 de la surcharge liée à l'ouverture et à la 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 ; cela fonctionne plus rapidement en effectuant plusieurs opérations de fichier simultanées.

Voici un exemple d'archiveur rapide par rapport à tar sur une sauvegarde de plus de deux millions de fichiers; l'archivage rapide prend 27 minutes, contre 1 heure 23 pour le goudron.

$ 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 serveurs, vous pouvez utiliser fast-archiver avec ssh, comme ceci:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

J'utilise également l' netcatapproche tar through , sauf que je préfère utiliser socat- beaucoup plus de puissance pour optimiser votre situation - par exemple, en modifiant mss. (Aussi, rigolez si vous voulez, mais je trouve les socatarguments plus faciles à retenir car ils sont cohérents). Donc, pour moi, c'est très courant ces derniers temps, car j'ai transféré 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.

Une autre alternative est Unison . Peut-être un peu plus efficace que Rsync dans ce cas, et il est un peu plus facile de configurer un auditeur.

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

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

• NFS (Network File System) , puis copiez-les 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) , puis copiez les fichiers avec ce que vous voulez, mais je n'ai aucune idée de son efficacité.
• HTTP avec wget --mirrorcomme suggéré par Evan Anderson ou tout autre client http. Veillez à ne pas avoir de liens symboliques ni de fichiers d’index trompeurs. Si tout ce que vous avez est 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 . D'après mon expérience , je peux dire que c'est lent par rapport aux autres solutions.

Grâce à la réponse merveilleuse de Scott Pack (je ne savais pas comment faire cela avec ssh auparavant), je peux offrir cette amélioration (si bashc'est votre shell). Cela ajoutera une compression parallèle, un indicateur de progression et vérifiera l’intégrité sur 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
    '

pvest un bon programme de visualisation de progrès pour votre pipe et pigzest 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 ajuster le niveau de compression afin de mieux adapter le ratio processeur à bande passante réseau et le remplacer avec pxz -9eet pxz -dsi 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 les très grandes quantités de données et les réseaux à latence élevée, mais elle n’est 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 en mode 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 ont la même taille ou la même limite avec count =, skip =, seek =, etc.

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

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

Je recommanderais d'utiliser rsync . Ce ne sera peut-être pas plus rapide, mais au moins si cela échoue (ou si vous le fermez parce que cela prend trop de temps), vous pouvez reprendre votre travail là où vous l'avez laissé la prochaine fois.

Si vous pouvez connecter les 2 machines directement à l’aide d’Ethernet gigabit, ce sera probablement le plus rapide.

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

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

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

À 100 Mo / s, vos processeurs devraient pouvoir gérer le chiffrement / déchiffrement sans impacter sensiblement le débit de données. Et si vous interrompez le flux de données, vous devriez pouvoir reprendre votre travail là où vous l'avez laissé. Attention, avec "des millions" de fichiers, le démarrage prendra un certain temps avant de transférer quoi que ce soit.

J'ai rencontré cela, sauf que je transférais les 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 un grand succès (où le succès est équivalent à environ 700 Mo / s sur un réseau de plusieurs Go). 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? Est-ce un lecteur unique à lecteur unique? RAID vers USB?

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

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 utilisant SSH) est obligatoire, mais un autre outil que vous pourriez utiliser est netcat .

Je voudrais utiliser les éléments suivants sur la machine de réception:

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

Puis du côté de l'envoi:

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

Il présente les avantages suivants:

• Pas de surcharge du processeur pour le cryptage que SSH a.
• Il gzip -1fournit une compression légère sans saturer le processeur, ce qui en fait un bon compromis, en offrant 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 vous assurer de saturer la bande passante de votre 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 manière dont vous transférez, je lancerais probablement un rsync ou unisson ensuite pour vous assurer de tout avoir.
• Vous pouvez utiliser tarau lieu de cpiosi vous préférez.
• Même si vous finissiez par utiliser ssh, je voudrais m'assurer qu'il n'utilise pas de compression elle-même et que gzip -1vous fuyiez à travers vous-même pour éviter la saturation du processeur. (Ou au moins, réglez CompressionLevel sur 1.)

Un simple scp avec les options appropriées atteindra facilement 9-10 Mo / s en réseau local:

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

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

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

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

1. Utiliser scp prend 11m59s
2. Utiliser rsync prend 7m10s
3. Utiliser ncftpget prend 1m20s

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 taux de transfert supérieur à 90% à condition de pouvoir alimenter les tuyaux.

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

Normalement, nous essayons vraiment de ne pas avoir à nous déplacer. Nous utilisons des pools ZFS pour lesquels nous pouvons toujours simplement "ajouter" plus d'espace disque. Mais parfois ... il suffit de déplacer des choses. Si nous avons un système de fichiers "live" qui peut prendre des heures (ou des jours) à copier même lorsque vous jouez à fond, nous effectuons la routine d'envoi en deux étapes:

1. Créez un instantané ZFS et transférez-le dans le nouveau pool de la nouvelle machine. Laissez-le prendre aussi longtemps que cela prend.
2. Créez un deuxième instantané et envoyez-le sous forme incrémentielle. L'instantané incrémentiel n'inclut que l'ensemble de modifications (beaucoup plus petit) depuis le premier, il est donc relativement rapide.
3. Une fois que l’instantané incrémentiel est terminé, vous pouvez tourner l’original et passer à la nouvelle copie tout en minimisant votre "temps mort hors ligne".

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

Le BBCP est disponible gratuitement, vous pouvez le rechercher sur Google, et c'est une compilation directe. Copiez-le simplement dans votre répertoire / usr / local / bin sur les machines src et de destination et tout fonctionnera.

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

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

/#ftp:name@server.xy/

ou

/#ftp:name@ip.ad.dr.ess/

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 me détacher de l'écran pendant que mc copie (je pense que ça tourne plus vite alors aussi).

Pour @scottpack réponse de l'option rSync

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

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

Voici un repère rapide pour comparer certaines techniques,

• La source est un processeur E5-1620 à 3,60 GHz avec un processeur SATA et Intel Core (X) Xeon (MD) à 250 Mbps.
• La destination est un processeur E-2136 à 3,30 GHz à 6 cœurs Intel (R) Xeon (R) avec une bande passante de 1 Gbps et un lecteur SSD

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

• 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 -

rsync ou vous voudrez peut-être l’archiver de manière à ce que tout se trouve dans un fichier, puis scp. Si vous manquez d'espace disque, vous pouvez diriger le fichier tar directement sur ssh pendant sa création.

Si vous envoyez des fichiers MP3 et autres fichiers compressés, vous ne tirerez aucun profit de toute solution essayant de compresser davantage ces fichiers. La solution permettrait de créer plusieurs connexions entre les deux serveurs et donc de surcharger la bande passante entre les deux systèmes. Une fois ce nombre atteint, il ne sera plus possible de gagner beaucoup sans améliorer votre matériel. (Cartes réseau plus rapides entre ces serveurs, par exemple.)

J'ai essayé quelques outils pour copier un fichier de 1 Go. Le résultat est le suivant: HTTP le plus rapide, avec wget -c nc deuxième en ligne scp le plus lent et plusieurs fois échoué. Aucun moyen de reprendre rsync utilise ssh en tant que backend, donc le même résultat. En conclusion, je choisirais http avec wget -bqc et lui donnerais du temps. Espérons que cela aide

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é rsyncsans -H(a pris 9 heures)
• quand rsync a fini, j'ai synchronisé le cpoolrépertoire et démarré avec le pcrépertoire; Je coupe le transfert.
• puis redémarré rsyncavec -Hflag et tous les fichiers liés durement dans le pcrépertoire ont été correctement transférés (la procédure a trouvé tous les fichiers réels dans cpoolet ensuite liés au pcrépertoire) (a pris 3 heures).

En fin de compte, je pouvais vérifier avec df -mcela qu'aucun espace supplémentaire n'était utilisé.

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