Transférer 15 To de petits fichiers

@TessellatingHeckler : donc vous suggérez que le PO migre de Redhat vers Windows avant d'archiver ?

Ils ont demandé "y a-t-il une meilleure façon de faire ?", et il y en a une. Je ne recommande pas qu'ils utilisent cette meilleure méthode. Ils sont libres d'utiliser des commandes dans un tuyau qui ne peut pas se remettre d'une interruption, ne vérifie pas le contenu du fichier, ne peut pas signaler l'état de la copie, ne peut pas utiliser les blocs précédemment copiés pour éviter de copier des parties de fichiers, n'a pas de support implicite de la copie à faible priorité, ne peut pas être mis en pause, n'a aucune mention de la copie des ACL, et nécessite que quelqu'un reste connecté pour l'exécuter. Cependant, toute autre personne qui suit le projet pourrait être intéressée - ou incitée à dire "x fait cela sous Linux".

@TessellatingHeckler : Cela ressemble un peu à l'envoi/réception de BTRFS. fr.wikipedia.org/wiki/Btrfs#Envoi.2Réception . Je pense que cela peut fonctionner comme un dump/restauration mais avec une capacité incrémentale. Certains autres systèmes de fichiers Linux ont également des outils de vidage/restauration qui lisent les données dans l'ordre du disque, et non dans l'ordre des répertoires logiques (par ex. xfsdump ). Le problème ici est que le PO passe de ext4 à XFS, donc ce n'est pas une option. (BTW, OP, je suggère d'évaluer BTRFS pour une utilisation sur votre serveur. XFS peut gérer le fait d'être utilisé comme un magasin d'objets pour des zillions de petits fichiers, mais BTRFS peut être meilleur à cela).

C'est un peu hors sujet, mais : @PeterCordes Je serais très prudent en recommandant btrfs pour une utilisation en production, encore. Dernièrement, j'ai eu quelques problèmes de corruption de données liés à btrfs et bcache sur Ubuntu 14.04.

@TessellatingHeckler Il est vrai que ce sont des commandes libres et qu'elles n'ont pas de statut de rapport en cas de corruption. Maintenant que vous le dites, je pense que je vais revenir à rsync. Parce que je sais qu'il pourrait y avoir une corruption dans notre ancien système lorsque le seuil de température a été franchi.

@lbanz : le cryptage ssh, ou la compression gzip de rsync, peuvent vous gêner. Discussion dans les commentaires sur unix.stackexchange.com/a/228048/79808 a quelques chiffres pour la compression.

@Fox : D'après ce que j'ai lu, si vous utilisez BTRFS, c'est une bonne idée d'utiliser le dernier noyau. Ils corrigent généralement plus de bogues qu'ils n'en introduisent, et c'est toujours nouveau et en amélioration, donc une version de BTRFS vieille de plusieurs années dans le noyau stable-distro n'est pas idéale.

@PeterCordes c'est pourquoi je recommande d'être prudent. Je suis moi-même plutôt fan de l'avant-garde, mais je comprends très bien pourquoi certaines personnes aiment les distros avec un support à long terme, qui ont tendance à s'en tenir à un noyau plus ancien. Alors bien sûr, btrfs évolue à un bon rythme, mais ce n'est pas une réponse universelle. Bien sûr, pas sans but.

@Fox : Je n'ai pas utilisé BTRFS moi-même, puisque XFS est bon pour ce que je fais principalement. Un commentaire sur la question de savoir s'il est bon pour une charge de travail comme celle de l'OP, où il est nécessaire d'avoir un système de gestion des données. tous des dossiers de petite ou moyenne taille ? Je sais que les développeurs de XFS disent parfois sur la liste de diffusion que XFS n'est pas conçu pour être un magasin d'objets, et mon impression est que BTRFS a été conçu avec cette charge de travail comme un cas d'utilisation potentiel. () Reiserfs est un mauvais choix pour un nouveau FS de nos jours, mais il a été explicitement conçu pour utiliser le système de fichiers comme une base de données.

En parlant de FS-as-object-store, j'ai fait quelques recherches lorsque ce sujet a été abordé récemment, car j'étais curieux. unix.stackexchange.com/a/222640/79808 a la plupart de ce que j'ai trouvé. Un système de fichiers traditionnel sur RAID5 est un mauvais choix. Un système de stockage d'objets que j'ai regardé faisait de la redondance au niveau des objets, et voulait un système de fichiers XFS séparé sur chaque disque. La différence est subtile mais énorme. Les opérations de métadonnées s'améliorent, car chaque CPU peut rechercher une petite carte de nœuds libres séparée, au lieu d'une carte géante, par exemple. L'élimination de RAID5 pour les écritures de petits objets est également très importante.

Ça me semble être un bon petit cas d'utilisation de BitTorrent Sync. getsync.com

Si vous n'avez pas l'intention d'y accéder à nouveau*, que diriez-vous de retirer simplement le disque lui-même et de le stocker dans un récipient hermétique (Lock&Lock) avec un paquet de déshydratant et peut-être un peu de papier bulle ? [ ] [ ] [ ]

Je suis si heureux que cela soit étiqueté linux et non Windows . Je mourrais probablement.

Vous pouvez également placer des packs de glace sur les disques pendant le transfert, afin d'éviter la dégradation par la chaleur.

@TessellatingHeckler L'exemple (et le lien) que vous avez rapporté indique clairement que la phase de pré-amorçage (lire : téléchargement du fichier vers le nouveau serveur) est effectuée par le DFSR via robocopy. Alors que robocopy es très utile, rsync est une meilleure alternative de presque tous les points de vue.

@lbanz alors combien de temps cela a pris ?

@RahulPatil les petits fichiers sont autour de 6mb/s et les gros fichiers sont à 150mb/s. Je compte 1-2 mois pour transférer 15TB de petits fichiers.