Transférez 15 To de fichiers minuscules

J'archive les données d'un serveur à un autre. Au départ, j'ai commencé un rsynctravail. Il a fallu deux semaines pour que la liste de fichiers ne soit constituée que pour 5 To de données et une autre semaine pour transférer 1 To de données.

Ensuite, je devais tuer le travail car nous avions besoin de temps d’arrêt sur le nouveau serveur.

Il a été convenu que nous allons le garder, car nous n’aurons probablement pas besoin d’y accéder à nouveau. Je pensais le diviser en morceaux de 500 Go. Après tarcela, j'allais le copier ssh. J'utilisais taret pigzc'est encore trop lent.

Y a-t-il une meilleure façon de le faire? Je pense que les deux serveurs sont sur Redhat. Ancien serveur est Ext4 et le nouveau est XFS.

La taille des fichiers varie de quelques kb à quelques mb et il y a 24 millions de jpeg dans 5 To. Donc, je suppose environ 60-80 millions pour 15 To.

edit: Après avoir joué avec rsync, nc, tar, mbuffer et pigz pendant quelques jours. Le goulot d'étranglement va être le disque IO. Les données étant réparties sur 500 disques SAS et environ 250 millions de fichiers jpeg. Cependant, maintenant, j'ai découvert tous ces outils utiles que je pourrai utiliser à l'avenir.

J'ai eu de très bons résultats en utilisant tar, pigz(gzip parallèle) et nc.

Machine source:

tar -cf - -C /path/of/small/files . | pigz | nc -l 9876

Machine de destination:

Extraire:

nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here

Pour conserver les archives:

nc source_machine_ip 9876 > smallstuff.tar.gz

Si vous voulez voir le taux de transfert, dirigez-le pvensuite pigz -d!

Je m'en tenais à la solution rsync. Moderne (3.0.0+) rsync utilise une liste de fichiers incrémentielle, il n’a donc pas besoin de créer une liste complète avant le transfert. Donc, le redémarrer ne vous obligera pas à refaire tout le transfert en cas de problème. Le fractionnement du transfert par répertoire de premier ou deuxième niveau optimisera encore cette opération. (J'utiliserais rsync -a -Pet ajouterais --compresssi votre réseau est plus lent que vos lecteurs.)

Configurez un VPN (s'il s'agit d'Internet), créez un lecteur virtuel d'un format quelconque sur le serveur distant (rendez-le ext4), montez-le sur le serveur distant, puis montez-le sur le serveur local (à l'aide d'un protocole de niveau bloc, tel que iSCSI). ) et utilisez dd ou un autre outil au niveau du bloc pour effectuer le transfert. Vous pouvez ensuite copier les fichiers du lecteur virtuel sur le lecteur réel (XFS) à votre convenance.

Deux raisons:

1. Pas de surcharge du système de fichiers, qui est le principal responsable des performances
2. Aucune recherche, vous regardez en lecture / écriture séquentielle des deux côtés

Si l'ancien serveur est en cours de déclassement et que les fichiers peuvent être hors ligne pendant quelques minutes, il est souvent plus rapide de simplement extraire les disques de l'ancien boîtier, de les connecter au nouveau serveur, de les monter (en ligne maintenant) et de copier les fichiers. aux nouveaux disques natifs des serveurs.

Utilisez mbuffer et s’il est sur un réseau sécurisé, vous pouvez éviter l’étape de chiffrement.

(Plusieurs réponses différentes peuvent fonctionner. En voici une autre.)

Générez la liste de fichiers avec find -type f(cela devrait prendre quelques heures), divisez-la en petits morceaux et transférez chaque morceau avec rsync --files-from=....

Avez-vous envisagé de sneakernet? Par cela, je veux dire tout transférer sur le même lecteur, puis le déplacer physiquement.

Il y a environ un mois, Samsung a dévoilé un disque dur de 16 To (techniquement, il s'agit de 15,36 To), qui est aussi un disque SSD: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard -drive-16tb

Je pense que ce lecteur ferait presque pour cela. Vous devez toujours copier tous les fichiers, mais comme vous n’avez pas de latence sur le réseau et que vous pouvez probablement utiliser SATA ou une technique similaire, cela devrait être beaucoup plus rapide.

S'il y a une chance d'obtenir un taux de réussite élevé lors de la déduplication, j'utiliserais quelque chose comme borgbackup ou attique.

Sinon, vérifiez la solution netcat + tar + pbzip2 , adaptez les options de compression en fonction de votre matériel - vérifiez quel est le goulot d'étranglement (CPU? Réseau? IO?). Le pbzip2 s'étendrait sur tous les processeurs, offrant de meilleures performances.

Vous utilisez RedHat Linux, cela ne s'appliquerait donc pas, mais comme une autre option:

J'ai eu beaucoup de succès à utiliser ZFS pour contenir des millions de fichiers car les inodes ne sont pas un problème.

Si c'était une option pour vous, vous pourriez alors prendre des instantanés et utiliser zfs pour envoyer des mises à jour incrémentielles. J'ai eu beaucoup de succès en utilisant cette méthode pour transférer ainsi que des données d'archives.

ZFS est principalement un système de fichiers Solaris, mais peut être trouvé dans illumos (fork open source de Sun OpenSolaris). Je sais que l’utilisation de ZFS sous BSD et Linux (avec FUSE?) A également eu de la chance - mais je n’ai aucune expérience en la matière.

Démarrez un rsyncdémon sur la machine cible. Cela accélérera beaucoup le processus de transfert.

Vous pouvez faire cela avec juste tar et ssh, comme ceci:

tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz"

Ou, si vous souhaitez conserver des fichiers individuels:

tar zcf - <your files> | ssh <destination host> "tar zxf -"