Les systèmes de fichiers récents des années 2005-2010 comme ZFS et Btrfs, ainsi que les gestionnaires de volumes, apportent de profonds changements dans la manière de penser et de concevoir le système de stockage. Les deux fonctionnalités phare qui font une apparition récente sont la déduplication et le snapshot, elles n’ont rien à voir et pourtant je considère que le snapshot permet de se passer de déduplication dans plusieurs cas de figures.
Un point sur les systèmes de fichiers récents
Avant 2000
Les termes « système de fichiers » et « récent » semblent presque incompatibles, tellement le paysage du système du fichier a une tendance générale à stagner à travers les évolutions technologiques logicielles et matérielles que l’on constate par ailleurs. Depuis Windows XP les utilisateurs de la firme de Redmond ont le choix d’utiliser NTFS comme amélioration logique à FAT32, mais le remplaçant est apparu plus tôt que le remplacé (1993 contre 1996) ! Sous MacOS on utilise HFS. Et sous Linux, on utilise depuis toujours ext2/3/4 (1993-2008) et XFS (pré-2000). Rien de nouveau au soleil.
Parmi ces dinosaures du filesystem, la fonctionnalité la plus novatrice est probablement la journalisation de ext3/4 et XFS, et qui permet de vérifier un lecteur plus rapidement après une coupure brutale, en somme rien que nous n’avions déjà en l’an 2000.
Après 2000 et les années 2010
Pendant cinq ans plus rien, puis en 2006 un projet qui apporte enfin du nouveau, le gestionnaire de volumes qu’est LVM. Ce composant intermédiaire se positionne entre le ou les disques durs et le système de fichiers, afin d’assouplir les cas d’utilisation. On peut enfin créer une partition (volume logique) qui s’étend sur plusieurs disques durs (à la JBOD), la redimensionner facilement, et même faire persister cette partition malgré le remplacement programmé de certains disques durs. Une fonctionnalité remarquable de LVM est le snapshot, qui permet de retrouver un volume logique tout entier tel qu’il était à une date donnée, et quelque soit le système de fichiers utilisé par dessus. LVM est encore en développement actif à ce jour, et présente de nombreux avantages dans des environnements modernes comme les systèmes de stockage ou les serveurs de virtualisation.
LVM a été écrit dans la plus pure tradition Linuxienne qui veut que chaque composant doit faire un minimum de choses, mais le faire bien en coopération avec d’autres composants complémentaires. La conjonction de Linux, mdadm et LVM et ext4 tient la route et procure de nombreux avantages. Oui mais voilà, cela devient un peu compliqué, et une philosophie alternative propose un paradigme différent : le regroupement dans le système de fichiers de tout ce qui touche à l’agrégation de disques durs (RAID), la gestion des volumes (LVM) et du système de fichiers tel qu’on le connaissait. Le système de fichiers ainsi obtenu aura une vision globale de tout le système de stockage depuis l’adressage matériel jusqu’aux fonctionnalités les plus avancées comme le cryptage ou la compression. Cela est particulièrement pratique pour gérer l’auto-guérision (auto-healing) du système de fichiers en cas de bloc illisible, ou encore la copy-on-write (CoW) utilisée par le principe du snapshot. Pour les SSD, c’est encore plus facile de remonter la commande TRIM entre le filesystem et le contrôleur disque.
L’avenir du système de fichiers sera dans le tout-en-un, en dépit de ce que la philosophie Linux nous a appris. Ou quand le whole system design remplace le small is beautiful.
La déduplication, une fonctionnalité très alléchante
La déduplication est une fonctionnalité incroyable, qui permet de comparer tous les fichiers du système de fichier afin d’identifier les blocs communs qu’il sera possible de ne stocker qu’une seule fois sur le périphérique. C’est en fait un dédoublonnage en mode blocs. Si vous stockez plusieurs fois un même fichier de 1 Mo, l’espace consommé sera de 1 Mo. Si vous stocker un fichier texte de 1 Mo, et que vous en créez une copie dans laquelle vous rajoutez 500 Ko de données, l’espace consommé sera de 1,5 Mo et non pas 1 Mo + 1,5 Mo.
Imaginez un peu le pouvoir de la déduplication chez Dropbox, où tous les utilisateurs stockent des fichiers parfois téléchargés sur le web (pdf, jpg, mp3, …) et donc identiques entre plusieurs comptes, les gains de place peuvent être absolument énormes. Et les économies aussi. Sur une grosse infrastructure de sauvegarde d’entreprise, vous pouvez vous permettre de sauvegarder tous les C:\Windows de vos postes de travail, ces répertoires seront tellement proches entre eux que le surcoût de stockage sera infime.
Oui mais voilà, la déduplication a un coût énorme, il faut très généreusement lotir ses serveurs en mémoire si on veut des performances correctes. La raison est simple : le système doit stocker en mémoire l’ensemble des hash des blocs du système de fichier, afin de les comparer entre eux. Ma compréhension de la déduplication se limite à ZFS puisque c’est la seule option que j’ai pu tester, mais je ne conçois pas un système de déduplication qui mette ce principe en défaut. Espérons que le temps me fasse mentir.
La page de référence ZFS sur Ubuntu.com indique tristement « la déduplication ne vaut presque jamais le coup, eu égard à la faible performance ». Je voudrais tout de même modérer ces propos, car il existe des solutions propriétaires type EMC, et même des produits commerciaux ZFS basés sur Solaris ou FreeBSD, qui tiennent la route.
Plus encore, la déduplication supprime toute redondance naturelle qui consiste à stocker un même fichier à plusieurs endroits du plateau magnétique. Donc le moindre secteur défectueux pourra impacter plusieurs fichiers à la foi. On n’a rien sans rien.
Ce qu’il ne faut jamais dédupliquer
En généralisant l’usage de la déduplication, on pourrait être amené à pratiquer le scénario suivant : je stocke les sauvegardes de mes serveurs (en mode fichiers) dans le répertoire /data/20170112.serveur, puis le lendemain je recommence dans /data/20170113.serveur , et ainsi de suite, en comptant sur la déduplication pour ne pas consommer d’espace supplémentaire dans /data , ou très peu.
Que suis-je en train de faire ? Je demande au serveur de comparer les moindres blocs de mes sauvegardes datées entre elles pour les dédoublonner. C’est une opération extrêmement coûteuse, un vrai gâchis de ressources.
En réalité je dédoublonne les répertoires par date, ce qui revient à demander au serveur de snapshoter mon arborescence a posteriori ! Nous arrivons à l’idée principale de cette article : préférer le snapshot plutôt que le dédoublonnage par date.
Le snapshot, ce que j’appelle la déduplication « par construction »
Ce que j’appelle la déduplication par construction, c’est le stockage du même répertoire à des dates différentes, en mutualisant les blocs des fichiers entre eux afin de consommer un minimum d’espace disque. Le terme « par construction » fait référence au coté instantané et atomique du snapshot, la logique de déduplication se trouve dans l’ordre des snapshots et non plus dans une déduplication gérée par le système de fichiers. C’est le rêve de tout administrateur système : pouvoir remonter le temps sans faire exploser la consommation en stockage.
Avec la déduplication, comme on l’a vu plus haut, cela fonctionnera au prix d’une consommation énorme en ressources.
Mais le snapshot est déjà fait pour stocker un répertoire à différentes dates, on à tout à y gagner ! L’opération de snapshot est très rapide car c’est très facile à réaliser pour un système de fichiers récent. Il lui suffit de dupliquer ses meta-data de fichiers et non pas ses fichiers.
Scénario n°1 : entre un système de fichiers ext4 et Btrfs
Imaginons le cas de figure suivant : mon serveur web héberge un site dans /var/www/site1 sur un disque ext4. Pour bénéficier des bienfaits du snapshot sur mon disque de sauvegardes /data équipé de Btrfs, je synchronise mes sites dans /data/backup/site1/synchro . Le dossier /data/backup/site1/synchro n’est pas comme les autres, c’est un subvolume (Btrfs) ou un filesystem (ZFS). Maintenant je n’ai plus qu’à le snapshoter tous les jours dans /data/backup/site1/snapshots/20170112.
Récapitulatif :
- Sur le disque de production, dans /var/www/site1 , je stocke mon site internet sur une partition ext4 pour des raisons de performances et de fiabilité.
- Sur le disque de sauvegarde, dans /data/backup/site1/synchro , il y a la synchro exacte de /var/www/site1 .
- Sur le disque de sauvegarde, dans /data/backup/site1/snapshot/20170112 , il y a l’état de /data/backup/site1/synchro à une date précise.
Dans le scénario ci-dessus, les snapshots prendront moins d’une seconde, une simple formalité pour le système de fichiers. J’aurai conservé énormément de fichiers identiques sans jamais souffrir de surconsommation sur mon petit disque de 1 To, et sans jamais faire tourner mon CPU à 100%.
La limite de ce système, c’est que la copie des fichiers entre la source ext4 et la cible Btrfs n’est pas une copy-on-write. Par conséquent, dès que je synchronise un fichier modifié entre la source et la cible avec rsync par exemple, un nouveau fichier temporaire est créé avec un nouvel inode, puis rempli et renommé avec le nom original. La conséquence de cela est que le coût d’un fichier snapshoté est le volume dudit fichier en entier. C’est encore jouable avec de tous petits fichiers, pour sauvegarder par exemple /etc ou /var/www . Mais pour sauvegarder des images disques ou des grosses bases de données, cela consommera trop d’espace disque.
Scénario n°2 : snapshot sur le même système de fichiers
Pour parfaire l’exemple d’utilisation du snapshot Btrfs, il faut que les snapshots se situent sur le même système de fichiers que les données originales. Aucun répertoire n’a donc besoin d’être synchronisé et il suffit de snapshoter un subvolume Btrfs dans un autre subvolume. Éventuellement, la commande cp --reflink est capable de pratiquer des copy-on-write également.
Pour externaliser le stockage des snapshots, il existe des solutions avec ZFS, mais je n’en connais pas à ce jour avec Btrfs.
Ce que ne me permettra jamais le snapshot, c’est de mutualiser les blocs de mes fichiers entre deux arborescences de sauvegardes qui proviennent de sources différentes (exemple : site1 et site2). Pour ce faire, la déduplication reste la seule solution.
Conclusion
J’espère que mon titre provocateur ne fera pas bondir les aficionados de la dédup qui ne jurent que par elle, et passent des nuits à tuner leur pool ZFS pour en tirer les meilleures performances possibles. Bien-entendu on ne peut pas remplacer la déduplication par le snapshot tout le temps, mais uniquement dans certains cas de figure comme par exemple les snapshots datés.
Ce sont en réalité deux fonctionnalités différentes, dont le point commun est de dédoublonner les blocs entre plusieurs fichiers. La déduplication le fait a priori tandis que le snapshot le fait a posteriori.
Néanmoins je suis sincère dans mon constat : le snapshot va prendre un essor bien plus important que la déduplication dans les années à venir. C’est une technologie mature qui reste encore sous-utilisée eu égard aux services qu’elle rend.
Bonjour,
Question bête : si les disques hébergeant /var/www tombent, que faites-vous ?
Car un snapshot n’a absolument pas vocation à être un backup et ne peut être considéré comme tel.
Donc dans le cas où vos disques tombent, vos snapshots ne servent strictement à rien.
En revanche lorsque vous lancez une dédup sur votre backup, ok votre CPU tourne, mais vous travaillez à dédupliquer de vrais blocs, existants sur un autre disque & filesystem, et là vous pouvez vous targuer d’avoir fait « un vrai backup ».
Ou bien ai-je loupé quelque chose ?
Merci
Jérémy
Bonjour,
Vous avez raison de souligner que le snapshot seul n’est pas une sauvegarde.
Lorsque je copie /var/www/site1 (disque ext4) dans /data/backup/site1/synchro/ (disque btrfs), là c’est bien une sauvegarde. Et ce n’est pas la seule.
Les multiples snapshots que je pratique dans /data/backup/site1/snapshots/date n’apportent aucune redondance de données, mais juste le confort de remonter le temps.
La déduplication d’un disque de sauvegarde ne me dit trop rien, à la place je snapshote les sauvegardes serveur par serveur ou site par site. Certes je ne dédoublonne pas les blocs des différentes sources entre elles, mais uniquement au sein d’un serveur ou d’un site, là où il y a vraiment des blocs communs.
Je vais tâcher de clarifier la rédaction, et merci pour votre commentaire.
Pour les vrais backup on peut utiliser rsnasphot qui va faire une synchro entre vos machines de prod et votre backup.
ça utilise rsync et ça ce base sur les liens en dur de ext4, c’est la même chose que vous décrivez sans devoir travailler avec zfs (pas besoins de mémoire ecc et moins de ressource processeur).
C’est un vieux outils mais qui est terriblement efficace.
Par contre la première sychro peut être longue (il copie tous la première fois).
Salutations
L’outil perl rsnapshot est très intelligent car il associe le hardlink avec la particularité de rsync de créer un nouvel inode pour chaque fichier mis à jour (et non pas –inplace qui casserait toute la chaîne de hardlinks).
En 2004, c’était la possibilité de faire des snapshot datés avec ext4, en mode fichiers uniquement.
De nos jours, rsnapshot peut encore rendre de fiers services, mais je trouve qu’il usurpe un peu son nom car il n’utilise pas la copy-on-write (CoW) et souffre des inconvénients suivants :
Pour moderniser rsnapshot sur btrfs il faudrait implémenter la copie reflink au lieu de hardlink comme cela est demandé ici. Alternativement, on peut utiliser ce hack pour que rsnapshot utilise les possibilités de btrfs. Sur ZFS, il existe déjà un outil similaire, sanoid.
Cela dit, je suis heureux de votre intervention qui vient enrichir la discussion,
Cordialement
PS : Matthew Ahrens, cofondateur de ZFS, a écrit « ZFS n’a aucune spécificité qui requiert ou encourage l’utilisation de la mémoire ECC plus que n’importe quel autre système de fichiers ». Source.
Salute,
Article fort intéressant, merci. Pour information ton article a été remonté sur le Journal du hacker : https://www.journalduhacker.net/s/s69dcq/la_d_duplication_est_une_chim_re_vive_le_snapshot
Je trouve que tes arguments se tiennent et c’est très intéressant. Je te reproche par contre de trop « appuyer » les choses :
– Les sauvegardes c’est important mais personne (ou sinon je n’en vois pas l’intérêt) ne conserve des sauvegardes de chaque jour sur la dernière année. On met en place un système de rotation des sauvegardes et on ne mange pas tout l’espace disque
– » sans faire exploser la consommation en stockage », « la déduplication a un coût énorme, il faut très généreusement lotir ses serveurs en mémoire si on veut des performances correctes » POUR ZFS
– » la déduplication ne vaut presque jamais le coup, eu égard à la faible performance » POUR ZFS pas pour d’autres systèmes de fichiers
Je pense que la majorité des installations se font encore avec ext4. ZFS est un système de fichiers très particulier et à mon avis se fera snober par Btrfs.
Déduplication et snapshot sont complémentaires, ça dépendra surtout du besoin/contexte. Il faut également préciser que le coût en terme d’espace disque n’est pas nul pour les snapshots.
En ce qui me concerne actuellement je tourne avec Borg : https://www.blog-libre.org/2016/08/21/borgbackup-borg-pour-les-intimes/
Tcho !
Bonjour,
Merci pour la publication dans le Journal du Hacker. J’ai pris connaissance de ce site il y a quelques temps en regardant mes backlinks, et depuis je suis un lecteur assidu du fil RSS.
En optant pour un titre provocant et un style tranché, je me suis rendu coupable de simplifications abusives, c’est certain.
Figure-toi que j’expérimente le snapshot quotidien sur des périodes jusqu’à l’année. Dans une volonté de tester les limites d’une part, et aussi parce qu’on ne se rend pas toujours compte à temps lorsqu’un fichier a été modifié par erreur ou par un pirate, notamment sur les sites web. Je n’ai pas encore décidé de ma durée de rétention idéale, mais un jour ou l’autre je vais détruire les snapshots par la fin, en conservant probablement 1 version mensuelle, plus les x derniers jours.
J’ai mis tous les FS de déduplication dans le même panier en pointant du doigt leur consommation énorme RAM et CPU, et tu m’en tiens rigueur à juste titre. Je serais très intéressé si tu avais des contre-exemples à me soumettre !
Je te rejoins à 100% sur ton analyse de Btrfs qui va snober ZFS. Avec sa licence avantageuse et ses snapshots RW, c’est un winner. Il ne propose pas la dédupe, mais chacun aura compris que je m’en moque 🙂
Au sujet de Borg, j’avais personnellement conclus qu’il était inapproprié d’utiliser un programme userspace écrit dans un language de haut niveau comme Python pour manipuler des chunks, et donc pallier aux manques du système de fichiers, avec des risques de corruption de données et d’incompatibilité entre les versions. Mais vu que tu en dis du bien je vais lui donner une seconde chance et le tester plus à fond.
A te lire ailleurs sur le web,
J’espère que tu feras un retour sous forme d’article sur Borg, la littérature n’est pas abondante sur le sujet.
Personnellement je lui cherche « vraiment » des défauts. Aucun outil n’est parfait mais là j’avoue que je suis très, très satisfait. J’espère que tu en trouveras, on ne peut tester/juger qu’en rapport avec nos besoins. Plus l’outil sera testé, plus on y décéléra ses limites.
A titre d’info voici ma rétention : borg prune -v –keep-within=10d –keep-weekly=4 –keep-monthly=-1 /home/babar/borg_backup (10 jours, 4 semaines, tous les mois indéfiniment mais je supprime manuellement ensuite)
Tcho !
merci pour cet article très bien écrit. Il manque peut-être d’éléments justificatifs mais on comprend aisément l’évolution lente des files-system Linux, la fin du KISS pour les FS pour ce qui concerne BTRFS.
Hello,
Pour le cas 1, on peut ajouter
--inplaceet--no-whole-fileaux options de rsync.De ce fait, le rsync envoi les données du jour sur ZFS sans surconsomation !
La rotation/préservation de l’historique se gère via les snapshots ZFS et la modification de quelques octets sur un fichier de xTo ne voit un delta que de quelques octets entre les 2 snapshots.
Bonjour, oui tout à fait le
--inplacedemande à rsync de mettre à jour le fichier cible en conservant l’inode. Ainsi, après snapshot, la copy-on-write de ZFS (ou Btrfs) ne consomme pas 2x le volume du fichiers mais seulement les blocs modifiés (parrsync --inplace). J’en parle brièvement dans cet article. A noter qu’en cas de coupure de connexion, le fichier cible se trouvera corrompu. Cette option empêche également tout mécanisme de versioning à la rsnapshot.Je crois que l’option –no-whole-file n’est pas nécessaire car rsync fonctionne par défaut en delta-blocs sur le réseau, à moins que le –whole-file (ou -W) ait été activé par erreur ou que le transfert soit entre deux disques durs locaux.
Bonjour,
Comment ça se passe avec BTRFS si par exemple je renomme et/ou déplace le répertoire source de mes 100000 images et que je créé un nouveau snapshot ? Les 100000 images vont-elles être dupliquées ?
Même question si je décide de renommer mes images suivant une nouvelle convention ?
Avec une dé-duplication pas de souci.
Bonjour, à confirmer mais je pense que si vous supprimez un fichier snapshoté en différent exemplaires, les blocs inutilisés sont détruits tandis que les blocs mutualisés entre snapshots demeurent. Le renommage de dossiers ou de subvolumes est possible avec un simple
mv.Faites l’expérience sur une partition ext4:
Copiez-collez 10Gio de données d’un répertoire à un autre. Sur un disque mécanique, ça va prendre des plombes.
Maintenant, déplacez-les ailleurs et renommez-les: c’est instantané.
Conclusions: ces opérations n’entraîne pas de déplacement physique des données sur le disque. Seul leurs entrées dans l’arborescence et quelques i-nodes seront modifiés.
Il en ira de même sur btrfs /zfs.
Les différentes snapshots contiendront une seule version de données, mais plusieurs versions d’i-nodes.
Donc inutile de lancer une dé-duplication derrière.
« La fourchette est une chimère, vive le couteau (pour découper une viande) ». C’est finalement ce que je retiens de cet article.
La déduplication et les snapshots sont deux applications du copy-on-write, mais n’ont pas la même finalité. Il ne me viendrait pas à l’idée d’utiliser l’un pour faire l’autre.
La dedup peut être utile aux adeptes intensif du copier-coller sur leur partition, ou de l’excellent exemple Dropbox que vous avez donnée.
Mais pour des sauvegarde incrémental, c’est évidement les snapshot qu’il faut utiliser. D’autant plus avec les fonctions send -p| receive de btrfs, qui permettent de n’envoyer que la différence entre deux snapshots vers sa sauvegarde externe, et pas toute la partition.
La dedup peut éventuellement sauver le coup lorsqu’on migre ses sauvegardes incrémentales d’une partition ext4 vers btrf / zfs, mais au-delà de ça, je n’utiliserai pas ma fourchette pour découper ma viande. Pour autant, mon couteau n’a pas vocation à remplacer ma fourchette.
J’ai néanmoins beaucoup apprécier les deux premières parties de l’article.