Comment copier rapidement un grand nombre de fichiers entre deux serveurs


91

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?


1
Quel type de réseau avez-vous entre les serveurs? J'ai utilisé un croisement Ethernet GB entre 1 carte réseau dans chaque machine. J'ai très bien maîtrisé cette configuration avec SCP
Jim Blizard, le

Vous voudrez peut-être rechercher pourquoi SCP est si lent. C’est peut-être plus lent que des choses comme ftp à cause du cryptage, mais cela ne devrait pas être beaucoup plus lent.
Zoredache

J'ai 100 mbps entre eux. scp est plus lent sur les petits fichiers (la plupart d'entre eux sont petits)
nicudotro

Réponses:


116

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

2
+1 L'option tar est beaucoup plus efficace pour un grand nombre de petits fichiers car scp et rsync auront beaucoup plus d'allers et retours par fichier sur le réseau.
Sekenre

3
rsync a fonctionné mieux pour moi que tar
nicudotro

4
De même, si vous disposez de beaucoup de CPU (aux deux extrémités), mais (au moins) d'un lien lent entre les hôtes, il peut être intéressant d'activer la compression (gzip ou bzip) dans la commande tar.
Vatine

1
@Jamie: Si vous utilisez ssh-agent, alors il devrait être utilisé. Sinon, utilisez simplement l'option '-i' pour spécifier où trouver la clé privée. Voir la page de manuel pour plus de détails.
Scott Pack

3
@niXar Le ~caractère d'échappement n'est activé que si SSH utilise un terminal. Ce n'est pas le cas lorsque vous spécifiez une commande à distance (sauf si vous passez l' -toption). Donc, votre préoccupation est invalide.
Gilles

36

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


10
Heh heh ... aucune technologie de réseau ne bat la bande passante d'un break chargé de bandes de 90 MPH, hein? (Snicker) J'ai supposé qu'il était sur un réseau local parce qu'il disait qu'il obtenait 9-10 Mo / sec avec HTTP.
Evan Anderson

2
J'ai ce genre de vitesse sur Internet, mais j'ai de la chance là où je vis! Si c'est sur un réseau local, alors moins cher encore!
Adam

2
Ahh-- n'a pas regardé votre emplacement. Ouais, j'ai entendu dire que la connectivité Internet en Corée est assez spectaculaire. Bloqué ici aux États-Unis, je suis heureux d'avoir 900 Ko / s sur le net ...
Evan Anderson

1
Oui, mais vous pouvez obtenir de délicieux burritos en attendant le téléchargement. Il n'y a qu'environ trois restaurants mexicains à moitié décents même à Séoul ...
Adam, le

17

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/


Bien que SCP utilise en effet du processeur pour chiffrer les données, je ne pense pas qu'il utilise le processeur à 100%, ce dernier ne constitue donc pas un goulot d'étranglement. J'ai trop souvent remarqué que SCP était inefficace en matière de transferts rapides.
Cristian Ciupitu

Étant donné qu'il voyait 300 Ko pour SCP et 9 Mo pour HTTP, j'ai supposé qu'un goulet d'étranglement lié à SCP (normalement le processeur) entrait en jeu. Cela pourrait certainement être autre chose, cependant. Il est difficile de dire si nous ne connaissons pas les spécifications matérielles des machines en question.
Evan Anderson

1
rsync utilisera presque certainement ssh pour le transport, étant donné qu'il s'agit d'un comportement par défaut, toute surcharge générée par le cryptage dans scp sera également présente dans rsync
Daniel Lawson, le

3
"Vous constatez déjà que HTTP est plus rapide que SCP car SCP crypte tout" "WRONG. À moins qu'il n'ait des serveurs âgés de 10 ans, il n'est pas lié au processeur pour cette tâche.
NiXar

1
@RamazanPOLAT - Vous avez une ligne de commande trop longue. Spécifiez la sélection de fichier différemment et cela fonctionnera bien pour vous. En règle générale, vous pouvez simplement spécifier le répertoire source avec un caractère générique à la fin. Vous pouvez également utiliser les arguments --includeet --excludepour être plus nuancé.
Evan Anderson

15

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 -

2
Malheureusement, netcat est très inefficace, même si cela ne devrait pas être le cas.
Cristian Ciupitu

Je vous vote contre parce que c'est vraiment un très mauvais conseil. Il y a une bonne réponse: rsync. Je pourrais énumérer toutes les raisons pour lesquelles c'est mieux mais cela ne tient pas sur cette page, sans parler de cette petite boîte de commentaires.
NiXar

2
@niXar: Si tout ce que vous voulez faire est un seul transfert de fichier (aucune synchronisation supplémentaire n'est nécessaire), alors tarpipe est tout ce dont vous avez besoin.
Witiko

2
@niXar netcat convient si vous le faites dans un environnement sécurisé comme vlan privé et / ou sur un réseau privé virtuel.
Lester Cheung

netcat est idéal pour un environnement sécurisé jusqu'à ce que vous obteniez un renversement et que tout le flux de 1 To soit mauvais. J'ai un script élaboré comme celui-ci avec compression parallèle, sortie en progression (via pv) et contrôle d'intégrité via sha512sum, mais une fois qu'un bit est retourné, le flux entier est défectueux, car il est impossible de le récupérer. Ce dont nous avons vraiment besoin, c’est d’un protocole léger, comme un flux de streaming pour ces environnements sécurisés, lorsque nous avons besoin d’une surcharge de temps, ce qui vérifiera l’intégrité au niveau du bloc (par exemple, 4 Mo) et pourra renvoyer un bloc s’il échoue. TCP crc n'est pas assez puissant.
Daniel Santos

8

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.


7

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


+1 pour le point sur le changement de chiffrement
Daniel Lawson

Le processeur ne sera pas un goulot d'étranglement, à moins que vous n'ayez un Ethernet 10G et un processeur vieux de 10 ans.
NiXar

1
juste commenter: cipher "-c arcfour" est plus rapide.
Arman

@niXar: Mais si vous avez déjà une tâche consommant beaucoup de temps sur votre ordinateur, c'est une préoccupation.
Isaac

6

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 . :)

rsync_vs_tar


Un hacker de confiance me dit que "tar over tc au lieu de nfs pourrait même être plus rapide". à tar cf - directory | ttcp -t dest_machinepartir de ftp.arl.mil/mike/ttcp.html
Philip Durbin

Question sans rapport, mais d'où vient ce graphique?
CyberJacob

4

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

3

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.


2

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.


2

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'

J'ai constaté que la commande a échoué lorsque j'ai utilisé l'option -f.
user11749

@ user11749: Cette commande comporte deux options -f, qui sont toutes deux obligatoires. Parlez-vous de passer -f à ssh pour qu’il passe à l’arrière-plan?
retracile

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


2

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.


1

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.


J'ai un lien inutilisé 100mbps directement entre eux
nicudotro

1
Ne va pas faire mieux que SCP? SCP envoie toutes ces données par une étape de chiffrement. SCP va être l’un des moyens les plus lents de le copier!
Evan Anderson

Certes, SCP encrypte les données, mais la vitesse de cryptage est beaucoup plus rapide que la connexion réseau, et donc négligeable.
Brent

1

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.


1

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é.


1

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.)

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)


mais pas pour un million de petits fichiers. Avez-vous essayé votre solution vous-même?
Sajuuk le

1

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

1

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.


1

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).


1

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

entrez la description de l'image ici


1

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 -

0

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.


0

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.)


0

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


donnez-vous un aperçu de la raison pour laquelle http est le plus rapide?
Sajuuk le

0

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.

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.