Solution 1 :
Options pour accéder rapidement à des millions de fichiers et les sauvegarder
Emprunter à des personnes ayant des problèmes similaires
Cela ressemble beaucoup à un type de problème plus simple auquel sont confrontés les serveurs de news USENET et les proxys Web de mise en cache :des centaines de millions de petits fichiers auxquels on accède de manière aléatoire. Vous voudrez peut-être leur demander conseil (sauf qu'ils n'ont généralement jamais besoin d'effectuer de sauvegardes).
http://devel.squid-cache.org/coss/coss-notes.txt
http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf
De toute évidence, la nature cyclique du système de fichiers de nouvelles cycliques n'est pas pertinente pour vous, mais le concept de niveau inférieur consistant à avoir plusieurs fichiers/périphériques de disque avec des images compressées et un index rapide à partir des informations fournies par l'utilisateur pour rechercher les informations de localisation est tout à fait approprié.
Systèmes de fichiers dédiés
Bien sûr, ce ne sont que des concepts similaires à ceux dont les gens parlaient avec la création d'un système de fichiers dans un fichier et son montage sur le bouclage, sauf que vous pouvez écrire votre propre code de système de fichiers. Bien sûr, puisque vous avez dit que votre système était principalement en lecture, vous pouvez en fait dédier une partition de disque (ou une partition lvm pour plus de flexibilité dans le dimensionnement) à cette seule fin. Lorsque vous souhaitez sauvegarder, montez le système de fichiers en lecture seule, puis faites une copie des bits de la partition.
LVM
J'ai mentionné LVM ci-dessus comme étant utile pour permettre le dimensionnement dynamique d'une partition afin que vous n'ayez pas besoin de sauvegarder beaucoup d'espace vide. Mais, bien sûr, LVM a d'autres fonctionnalités qui pourraient être très applicables. Plus précisément, la fonctionnalité "instantané" qui vous permet de geler un système de fichiers à un moment donné. Tout rm -rf accidentel ou tout ce qui ne perturberait pas l'instantané. Selon exactement ce que vous essayez de faire, cela peut être suffisant pour vos besoins de sauvegarde.
RAID-1
Je suis sûr que vous connaissez déjà le RAID et que vous l'utilisez probablement déjà pour la fiabilité, mais le RAID-1 peut également être utilisé pour les sauvegardes, du moins si vous utilisez le RAID logiciel (vous pouvez l'utiliser avec le RAID matériel, mais cela en fait vous donne une fiabilité moindre car la lecture peut nécessiter le même contrôleur de modèle/révision). Le concept est que vous créez un groupe RAID-1 avec un disque de plus que ce dont vous avez réellement besoin connecté pour vos besoins de fiabilité normaux (par exemple, un troisième disque si vous utilisez un logiciel RAID-1 avec deux disques, ou peut-être un gros disque et un matériel- RAID5 avec des disques plus petits avec un RAID-1 logiciel au-dessus du RAID-5 matériel). Lorsque vient le temps d'effectuer une sauvegarde, installez un disque, demandez à mdadm d'ajouter ce disque au groupe RAID, attendez qu'il indique qu'il est complet, demandez éventuellement un nettoyage de vérification, puis retirez le disque. Bien sûr, selon les caractéristiques de performance, vous pouvez avoir le disque installé la plupart du temps et retiré uniquement pour l'échanger avec un autre disque, ou vous pouvez avoir le disque installé uniquement pendant les sauvegardes).
Solution 2 :
Vous pouvez monter un système de fichiers virtuel à l'aide du gestionnaire de bouclage, mais bien que cela accélère votre processus de sauvegarde, cela peut affecter les opérations normales.
Une autre alternative consiste à sauvegarder l'intégralité de l'appareil à l'aide de dd. Par exemple, dd if=/dev/my_device of=/path/to/backup.dd .
Solution 3 :
Comme vous le savez probablement, votre problème est la localité. Une recherche de disque typique prend environ 10 ms. Ainsi, le simple fait d'appeler "stat" (ou open()) sur 10 millions de fichiers placés au hasard nécessite 10 millions de recherches, soit environ 100 000 secondes, soit 30 heures.
Vous devez donc placer vos fichiers dans des conteneurs plus grands, de sorte que le nombre pertinent soit la bande passante de votre lecteur (50 à 100 Mo/s pour un seul disque, généralement) plutôt que votre temps de recherche. Aussi, vous pouvez lui lancer un RAID, ce qui vous permet d'augmenter la bande passante (mais pas de réduire le temps de recherche).
Je ne vous dis probablement rien que vous ne sachiez déjà, mais ce que je veux dire, c'est que votre idée de "conteneur" résoudra définitivement le problème, et à peu près n'importe quel conteneur fera l'affaire. Les montages en boucle fonctionneront probablement aussi bien que n'importe quoi.
Solution 4 :
Il y a plusieurs options. Le plus simple, et qui devrait fonctionner avec tous les systèmes de fichiers Linux, est de dd copier la partition entière (/dev/sdb3 ou /dev/mapper/Data-ImageVol ) à une seule image et archiver cette image. En cas de restauration de fichiers singuliers, montez l'image en boucle (mount -o loop /usr/path/to/file /mountpoint ) et copiez les fichiers dont vous avez besoin. Pour une restauration complète de la partition, vous pouvez inverser le sens du dd initial commande, mais vous avez vraiment besoin d'une partition de taille identique.
À en juger par votre cas d'utilisation, je suppose que les restaurations de fichiers individuels sont un événement très rare, voire jamais. C'est pourquoi une sauvegarde basée sur une image prend tout son sens ici. Si vous avez besoin d'effectuer des restaurations individuelles plus souvent, l'utilisation d'instantanés LVM par étapes sera beaucoup plus pratique; mais vous devez toujours effectuer la sauvegarde basée sur l'image pour ces catastrophes critiques "nous avons tout perdu". Les restaurations basées sur des images ont tendance à aller beaucoup plus rapide que les restaurations basées sur tar simplement parce qu'il ne s'agit que de restaurer des blocs, il n'implique pas beaucoup d'opérations de métadonnées à chaque fopen/fclose, et peut également être une opération de disque hautement séquentielle pour des augmentations de vitesse supplémentaires.
Alternativement, comme le mentionne la vidéo Google @casey à mi-chemin, XFS est un excellent système de fichiers (si complexe). L'un des meilleurs utilitaires avec XFS est le xfsdump utilitaire, qui videra un système de fichiers entier dans un seul fichier, et le fera généralement plus rapidement que tar boîte. C'est un utilitaire spécifique au système de fichiers, il peut donc tirer parti des éléments internes de fs d'une manière que tar ne peut pas.
Solution 5 :
Je vous suggère d'essayer d'abord de mettre à niveau vers EXT4, si vous ne l'utilisez pas déjà.
Google a fait beaucoup de recherches pour savoir pourquoi EXT4 est une bonne idée.
Après cela, vous devriez envisager de déployer une architecture de système de fichiers distribué. Par exemple :
- http://www.xtreemfs.org/
- http://code.google.com/p/kosmosfs/
- http://hadoop.apache.org/hdfs/