Le meilleur moyen de copier des millions de fichiers entre 2 serveurs

J'ai environ 5 millions de petits fichiers (5-30k) dans un seul répertoire que je voudrais copier sur une autre machine sur le même réseau gigabit. J'ai essayé d'utiliser rsync, mais cela ralentirait après quelques heures, je suppose en raison du fait que rsync doit vérifier le fichier source et le fichier de destination à chaque fois.

Ma deuxième pensée serait d’utiliser scp, mais je voulais obtenir un avis extérieur pour voir s’il existait un meilleur moyen. Merci!

Quelque chose comme ça devrait bien fonctionner:

tar c some/dir | gzip - |  ssh host2 tar xz

Peut-être aussi omettre gzip et l'indicateur "z" pour l'extraction, car vous êtes sur un réseau gigabit.

Je suis sûr que le fait que vous ayez tous les CINQ MILLIONS de fichiers dans un seul répertoire va jeter de nombreux outils dans tous leurs états. Je ne suis pas surpris que rsync n'ait pas géré cela avec grâce - c'est une situation assez "unique". Si vous pouviez trouver un moyen de structurer les fichiers en une sorte de structure de répertoire, je suis sûr que les outils de synchronisation standard tels que rsync seraient beaucoup plus réactifs.

Toutefois, pour vous donner un conseil concret, une solution consisterait peut-être à déplacer temporairement le lecteur physiquement dans la machine de destination afin de pouvoir effectuer une copie des fichiers sur le serveur réel (et non sur le réseau). Ensuite, déplacez le lecteur vers l'arrière et utilisez rsync pour maintenir les éléments à jour.

Pour copier des millions de fichiers sur un commutateur gigabit (dans un environnement sécurisé), vous pouvez également utiliser une combinaison de netcat (or nc)et tar, comme déjà suggéré par user55286. Cela va diffuser tous les fichiers en un seul fichier volumineux (voir Copie rapide de fichiers - Linux! (39 Go) ).

# requires netcat on both servers
nc -l -p 2342 | tar -C /target/dir -xzf -   # destination box
tar -cz /source/dir | nc Target_Box 2342    # source box

Nous avions environ 1 million de fichiers dans un répertoire (environ 4 ans).

Et nous avons utilisé robocopy pour déplacer les fichiers dans le répertoire AAAA / MM (environ 35 à 45 000 fichiers par mois). Nous avons mis le script robocopy dans un fichier .bat comme celui-ci:

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081201 /MINAGE:20090101 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\12
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090101 /MINAGE:20090201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\01
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090201 /MINAGE:20090301 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\02

notes brèves .. /ns /nc /nfl /npest d'éviter d'écouler le fichier journal avec des informations supplémentaires, /log+...c'est d'écrire des informations récapitulatives dans le fichier journal.

/minage and /maxage is to copy files modified with in that date range. 

Ainsi, par exemple, les fichiers modifiés> = 01 / Nov / 2008 (inclus) en fichiers modifiés <01 / Dec / 2008 (non inclus)

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11

/mov déplacer les fichiers

puis vient le répertoire source

vient ensuite le répertoire de destination (les répertoires seront créés à la volée au besoin).

Cela a pris environ 40 à 60 minutes pour un mois de transfert (environ 35 à 45 000 fichiers). Nous estimons que cela prend environ 12 heures ou moins pour un transfert d’une année.

Utilisation de Windows Server 2003.

Tous les éléments sont enregistrés dans le fichier journal ... Heure de début, Heure de fin et Nombre de fichiers copiés.

Robocopy a sauvé la journée.

Vous savez, j'ai plus-1 la solution tar, mais - en fonction de l'environnement - une autre idée se présente. Vous pourriez penser à utiliser dd (1) . Le problème de vitesse avec quelque chose comme ceci est qu'il faut beaucoup de mouvements de tête pour ouvrir et fermer un fichier, ce que vous ferez cinq millions de fois. Pour vous assurer que ceux-ci sont assignés de manière contiguë, vous pouvez les dd les remplacer, ce qui réduirait le nombre de mouvements de la tête par un facteur de 5 ou plus.

Je préfère utiliser lz4 comme outil de compression le plus rapide pour le moment. L'option -c arcfour128 de SSH utilise un algorithme de chiffrement plus rapide que celui par défaut. [1]

Donc, le transfert de répertoire ressemble à quelque chose comme:

tar -c folder | lz4 -c | ssh -carcfour128 somehost 'lz4 -d | tar -x > folder'

Veuillez noter que sur Debian, la commande lz4 est lz4c et sur CentOS, elle est lz4.

Robocopy est idéal pour des choses comme ça. Il essaiera de nouveau après les délais d'attente du réseau et vous permettra également de définir un délai d'intervalle entre paquets pour saturer le canal.

[Modifier]

Notez qu'il s'agit d'une application uniquement Windows.

Je sais que c'est peut-être stupide - mais avez-vous déjà pensé à les copier sur un disque externe et à les transférer sur l'autre serveur? C'est peut-être la solution la plus efficace et la plus simple.

Nous étudions actuellement ce problème. Nous devons transférer environ 18 millions de petits fichiers - environ 200 Go au total. Nous avons obtenu les meilleures performances avec XCopy, mais cela a quand même pris beaucoup de temps. Environ 3 jours d'un serveur à l'autre, environ 2 semaines sur un lecteur externe!

Par un autre processus, nous devions dupliquer le serveur. Cela a été fait avec Acronis. Cela a pris environ 3 heures !!!

Nous étudierons cela un peu plus. La suggestion dd ci-dessus donnerait probablement des résultats similaires.

Déjà des tonnes de bonnes suggestions, mais je voulais jeter au- delà de comparer . J'ai récemment transféré environ 750 000 fichiers entre 5 Ko et 20 Mo d'un serveur à un autre via un commutateur gigabit. Il n'a même pas eu le moindre hoquet. Certes, cela a pris du temps, mais je m'y attendais avec autant de données.

Je verrais comment un zip-> copier-> décompresser fonctionne

ou quel que soit votre système de compression / archive préféré.

Rangez-les dans un seul fichier avant de le copier, puis décompressez-les une fois copiés.

Dans une situation similaire, j'ai essayé d'utiliser tar pour regrouper les fichiers. J'ai écrit un petit script pour diriger la sortie de la commande tar vers la machine cible directement vers un processus tar récepteur qui décompose les fichiers.

L’approche tar a presque doublé le taux de transfert par rapport à scp ou rsync (YMMV).

Voici les commandes tar. Notez que vous devez activer les commandes r en créant des fichiers .rhosts dans les répertoires de base de chaque ordinateur (supprimez-les une fois leur copie terminée. Ce sont des problèmes de sécurité notoires). Notez également que, comme d'habitude, HP-UX est délicat - alors que le reste du monde utilise «rsh» pour la commande remote-shell, HP-UX utilise «remsh». 'rsh' est une sorte de shell restreint dans le langage de HP.

box1> cd source_directory; tar cf - . | remsh box2 "cd target_directory; tar xf - "

La première commande tar crée un fichier appelé "-", qui est un jeton spécial signifiant "sortie standard" dans ce cas. L'archive créée contient tous les fichiers du répertoire en cours (.) Ainsi que tous les sous-répertoires (tar est récursif par défaut). Ce fichier d'archive est dirigé vers la commande remsh qui l'envoie à la machine box2. Sur la case 2, je passe d'abord dans le bon répertoire de réception, puis j'extrais de «-» ou «entrée standard» les fichiers entrants.

J'avais 6 commandes tar en cours d'exécution simultanément pour m'assurer que le lien réseau était saturé de données, bien que je suspecte que l'accès au disque ait pu être le facteur limitant.

Contourner le système de fichiers.

Pouvez-vous démonter cette partition sur laquelle les fichiers sont stockés ou la monter en lecture seule? Faites cela, alors quelque chose comme:

dd if=/dev/PARTITION | ssh username@host "dd of=diskimage.bin"

Vous pouvez ensuite monter en diskimage.bintant que périphérique de bouclage du côté destination et en copier des fichiers dans votre système de fichiers de destination réel, ou bien utiliser les outils appropriés pour les réassembler dans une partition vide du côté destination (dangereux, mais probablement possible). , même si je ne l’ai jamais fait.)

Si vous êtes vraiment courageux, vous pouvez dddirectement le retourner dans une partition du côté destination. Je ne recommande pas ça.

vous pouvez essayer ce qui suit (il peut s'agir de lots de fichiers)

• tar le lot de fichiers
• Gzip les
• copier en utilisant scp si possible
• gunzip
• décompresser les fichiers

Comme suggéré par qc, vous pouvez essayer tar over ssh.

Si vous n'avez pas besoin de cryptage (à l'origine, vous utilisiez rsync, mais vous n'avez pas mentionné qu'il s'agissait de rsync + ssh), vous pouvez utiliser tar over netcat pour éviter la surcharge ssh.

Bien sûr, vous pouvez également réduire le temps nécessaire en utilisant gzip ou une autre méthode de compression.

Il y a autre chose à considérer. Essaye ça:

• Créer un disque dur virtuel, dimensionné dynamiquement
• Montez-le, éventuellement comme un répertoire
• Définir l'attribut 'compresser tout le disque'

En faisant cela, il n'y a AUCUN surcoût pour l'itération ou la compression du répertoire, car cela a été fait au moment de l'écriture des fichiers. Il n'y a qu'un seul fichier à déplacer: le disque dur virtuel.

Sous Windows, la taille de paquet TCP par défaut est plus grande, comme 16348. Cela signifie moins de temps système pour les en-têtes IP.

Une chose que j’ai rencontrée, cependant, est qu’il est préférable de garder une taille de fichier inférieure à 100 Mo pour un transfert réseau ou USB. J'utilise Rar.exe pour cela - pour diviser les fichiers.

Fonctionne comme un champion. C'est l'équivalent de 'dd' sous Linux. Le concept de montage d'un système de fichiers compressé dans un répertoire est également normal pour Linux. La même logique s'applique donc. Vous devez vous assurer que tous les fichiers sont fermés avant le début de l'opération, comme dans les autres méthodes.

Cela présente l’avantage supplémentaire de permettre de définir un quota de taille dans un dossier. Si le disque dur virtuel a une taille fixe, le dépassement de cette limite ne fera pas baisser le serveur, cela entraînera simplement une erreur lors de la création ou de l'écriture du fichier.

Un disque dur virtuel formaté en NTFS peut également gérer des millions de fichiers dans un dossier.