# Evolution de la solution de sauvegarde mutualisée {{INLINETOC}} L'évolution de la solution de backup mutualisée permet: * d'étendre les capacités de stockage. * d'archiver plusieurs sauvegardes sans consommer trop d'espace disque grâce à la déduplication. ## Configuration de l'espace de stockage auxiliaire Les deux serveurs sont configurés afin de partager leur espace de stockage sur une réseau filaire avec une capacité étendue (aggrégation des liens des cartes filles). ### Configuration Réseau Les ports des cartes filles des deux serveurs sont configurés afin d'établir un lien grande capacité. ^ Server ^ logical name ^ product ^ vendor ^ physical id ^ bus info ^ serial ^ capacity ^ | mutual1 | eth2 | I350 Gigabit Network Connection | Intel Corporation | 0 | pci@0000:07:00.0 | 40:f2:e9:1d:66:80 | 1Gbit/s | | ::: | eth3 | I350 Gigabit Network Connection | Intel Corporation | 0.2 | pci@0000:07:00.2 | 40:f2:e9:1d:66:80 | 1Gbit/s | | ::: | eth4 | I350 Gigabit Network Connection | Intel Corporation | 0.3 | pci@0000:07:00.3 | 40:f2:e9:1d:66:80 | 1Gbit/s | | mutual2 | enp7s0f0 | I350 Gigabit Network Connection | Intel Corporation | 0 | pci@0000:07:00.0 | 40:f2:e9:69:11:c0 | 1Gbit/s | | ::: | enp7s0f1 | I350 Gigabit Network Connection | Intel Corporation | 0.1 | pci@0000:07:00.1 | 40:f2:e9:69:11:c1 | 1Gbit/s | | ::: | enp7s0f2 | I350 Gigabit Network Connection | Intel Corporation | 0.2 | pci@0000:07:00.2 | 40:f2:e9:69:11:c2 | 1Gbit/s | | ::: | enp7s0f3 | I350 Gigabit Network Connection | Intel Corporation | 0.3 | pci@0000:07:00.3 | 40:f2:e9:69:11:c3 | 1Gbit/s | '-------------------------------' |[PK] sf033 | | | '-------------------------------' ^ ^ ^ ^ eth0 | | eth1 | | xx.xxx.xxx.14| | xx.xxx.xxx.61 | | .---------------------------------------------------+------+-----. | | | | | | | Mutual 192.168.1.14 | | | | | | | .----------------------------------------------------------------. | | eth2 ^ eth3 ^ eth4 ^ ^ | | | | | | '---------------------------' | | | | | | | | | | | | '---------------' | | | | | | | | | | | enp27s0f0 | enp27s0f1 enp7s0f0 v enp7s0f0 v enp7s0f0 v enp7s0f0 v | | xx.xxx.xxx.xxx2.15 .----------------------------------------------+---------------+-. | | | Mutual2 192.168.1.15 | | | .----------------------------------------------------------------. [PK]: {"fill":"#FFAAAA","a2s:delref":true} ### Installation et configuration des partage NFS Installation des outils NFS et leurs dépendances. ``` yum install nfs-utils ``` Les partages NFS sont configurés chacun des serveurs dans le fichier /etc/exports: Sur le serveur mutual (xx.xxx.xxx.xxx2.14): ``` /data 192.168.1.15(rw,async,no_root_squash,no_all_squash) ``` Sur le serveur mutual2 (xx.xxx.xxx.xxx2.15): ``` /data 192.168.1.14(rw,async,no_root_squash,no_all_squash) ``` L’option rw monte le répertoire distant en lecture/écriture.\\ L’option async permet des écriture synchrones, c’est-à-dire que le serveur n’attend pas l’écriture d’une requête précédente avant de répondre. Activer et démarrer les services RPC((les implémentations NFSv3 nécessitent le service rpcbind pour une compatibilité ascendante)) et NFS. ``` systemctl enable rpcbind nfs-server --now ``` ### Configuration du montage NFS Le partage nfsshare est monté sur chacun des seveurs. Sur le serveur mutual (xx.xxx.xxx.xxx2.14): ``` mkdir /nfsshare mount -t nfs 192.168.1.15:/data /nfsshare df -h /nfsshare Filesystem Size Used Avail Use% Mounted on 192.168.1.15:/data 1.4T 90G 1.3T 7% /nfsshare ``` Sur le serveur mutual2 (xx.xxx.xxx.xxx2.15): ``` mkdir /nfsshare mount -t nfs 192.168.1.14:/data /nfsshare df -h /nfsshare Filesystem Size Used Avail Use% Mounted on 192.168.1.14:/data 2.0T 1.5T 399G 80% /nfsshare ``` Dans le fichier `/etc/fstab` du serveur mutual (xx.xxx.xxx.xxx2.14) ajouter ceci pour le montage au boot: ``` 192.168.1.15:/data /nfsshare nfs defaults 0 0 ``` Et dans le fichier `/etc/fstab` du serveur mutual2 (xx.xxx.xxx.xxx2.15) ajouter ceci pour le montage au boot ``` 192.168.1.14:/data /nfsshare nfs defaults 0 0 ``` ## Test de la déduplication La déduplication est un moyen de supprimer les données redondantes des systèmes de fichiers. En termes simples, si on stocke beaucoup de fichiers sur le système de fichiers et que certains de ces fichiers sont identiques, une seule copie de ces fichiers sera conservée sur le système de fichiers. Le reste d'entre eux sera une référence à cette copie du fichier. Cela permettra d'économiser beaucoup d'espace disque sur le système de fichiers ZFS. On distingue généralement: * **La déduplication hors bande/batch**: est une déduplication effectuée en dehors de l'écriture. On l'appelle parfois déduplication hors ligne, mais la déduplication btrfs implique le noyau et se produit toujours sur les systèmes de fichiers montés. Pour utiliser la déduplication hors bande, on exécute un outil qui recherche dans le système de fichiers des blocs identiques, puis les déduplique. * **La déduplication intrabande/synchrone/en ligne**: est une déduplication effectuée lors de l''écriture, elle se produit donc lorsque les données sont écrites dans le système de fichiers. Techniquement, lorsqu'on copie/déplace/crée de nouveaux fichiers la déduplication les divisera en morceaux et comparera ces morceaux avec les morceaux existants (des fichiers) stockés sur l système de fichiers pour voir s'il a trouvé des correspondances . Ainsi, même si des parties du fichier correspondent, la fonction de déduplication peut économiser de l'espace disque de votre système de fichiers. Cela nécessite généralement de grandes quantités de RAM pour stocker la table de recherche des hachages de blocs connus et ajoute une surcharge d'E/S pour stocker les hachages Linux prend en charge un périphérique de bloc spécial appelé périphérique de boucle (loop device), qui mappe un fichier normal sur un périphérique de bloc virtuel. Cela permet au fichier d'être utilisé comme un "système de fichiers virtuel". ### Contexte de test La déduplication est une fonctionnalité très intéressante car elle permet d'économiser de l'espace disque d'un système de fichiers. Lorsqu'on envisage d'utiliser la déduplication, il faut analyser les données et découvrir dans quelle mesure la déduplication fonctionnera avec ces données et si la déduplication peut faire économiser de l'espace disque: * si les données stockées sur le système de fichiers sont redondantes (un fichier similaire est stocké plusieurs fois) par nature la déduplication peut faire économiser de l'espace disque. * si les données stockées sur le système de fichiers n'ont pas beaucoup de redondance (presque unique), alors la déduplication ne sera d'aucune utilité. Au lieu de cela, on finirait par gaspiller de la mémoire que l'on pourrait autrement utiliser pour d'autres tâches importantes. Les sauvegardes txxa ne sont certainement pas de bonnes candidates car la majorité des fichiers sauvegardés sont des fichiers envoyés par divers clients donc à peu près uniques. En revanche les sauvegardes ops concernent des tâches du planicateur qui ont plus de chance de se répéter périodiquement. On réalisera les tests sur l'espace de stockage des sauvegardes OPS. ``` du -sh /data/ops/* 4.0K /data/ops/errata.repo 124K /data/ops/log-rsync-ops-sav-o77e 4.0K /data/ops/o13b 46G /data/ops/o13e 17G /data/ops/o44a 4.0K /data/ops/o44b 4.0K /data/ops/o44c 41G /data/ops/o44d 37G /data/ops/o44e 8.9G /data/ops/o44f 4.0K /data/ops/o51b 47G /data/ops/o51e 4.0K /data/ops/o63b 52G /data/ops/o63e 6.8G /data/ops/o77e 4.0K /data/ops/security.repo 4.0K /data/ops/w75b 25G /data/ops/w75e ``` Afin de réaliser les tests des copies des répertoires `/data/ops/o13e` et `/data/ops-save/o13e` du serveur mmutual (xx.xxx.xxx.xxx2.14) ont été placées dans `/data/test/o13e/` et `/data/test/o13e-sav` du serveur mutual2 (xx.xxx.xxx.xxx2.15) ### Déduplication XFS avec borgbackup Les systèmes de fichiers Copy-on-Write ont la propriété intéressante qu'il est possible de "cloner" des fichiers instantanément, en faisant référencer le nouveau fichier aux anciens blocs, et en copiant (éventuellement) les blocs modifiés. Cela permet à la fois d'économiser du temps et de l'espace et peut être très bénéfique dans de nombreuses situations (par exemple lorsqu'on travaille avec de gros fichiers). Sous Linux, ce type de copie est appelé "reflink". Mais le système de fichiers XFS de Centos7 n'intègre pas cette fonctionnalité, on va donc utiliser le logiciel **Borgbackup** dans cette section. Avec la nouvelle fonctionnalité **reflink** des versions de **xfs** qui le supporte ont peut uiliser **duperemove**. Créer un zvol, `mkfs.xfs -m reflink=1 zvol` et le monter. Installer **duperemove**, copier certaines données dans le système de fichiers **xfs** et effectuer un `duperemove -hdr --hashfile=/somefile /dirtodedup`. Il faut également un noyau assez récent. **Borgbackup** est un outil de sauvegarde incrémentielle en ligne de commande écrit en Python. Une des particularités de Borg est qu’il supporte la déduplication. Pour installer **borgbackup** il faut activer le dépôt **epel**: ``` yum install epel-release yum install borgbackup ``` Créer un fichier img: ``` fallocate -l 100G disk-xfs.img du -hs disk-xfs.img 100G disk-xfs.img ``` Créer maintenant un périphérique de boucle avec ce fichier : ``` losetup -f disk-xfs.img losetup -a /dev/loop0: [0046]:659412 (/data/test/disk-xfs.img) ``` L'option -f trouve un périphérique de boucle inutilisé et losetup -a affiche le nom du périphérique de boucle qui a été créé. Créer un système de fichiers XFS: ``` mkfs.xfs disk-xfs.img meta-data=disk-xfs.img isize=512 agcount=4, agsize=6553600 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0, sparse=0 data = bsize=4096 blocks=26214400, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=12800, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 ``` On peut maintenant monter `/dev/loop0` sur un répertoire : ``` mount /dev/loop0 /mnt df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/loop0 100G 33M 100G 1% /mnt ``` Initialiser le dossier de sauvegarde ``` borg init -e none /mnt/backup ``` On va réaliser la sauvegarde du répertoire `/data/test/o13e`: ``` borg create --stats /mnt/backup::o13e /data/test/o13e/ ------------------------------------------------------------------------------ Archive name: o13e Archive fingerprint: d45a8d0c525058c285b102305717bed407a460e7eb1793b46a85c7978e4e28f2 Time (start): Fri, 2022-01-14 14:07:30 Time (end): Fri, 2022-01-14 14:24:58 Duration: 17 minutes 28.09 seconds Number of files: 299574 Utilization of max. archive size: 0% ------------------------------------------------------------------------------ Original size Compressed size Deduplicated size This archive: 47.91 GB 25.77 GB 24.53 GB All archives: 47.91 GB 25.77 GB 24.53 GB Unique chunks Total chunks Chunk index: 151413 308308 ------------------------------------------------------------------------------ -(Fri Jan 14 14:25:02)--(master2016:/data/test)- ``` On constate que la première sauvegarde est longue (17 minutes 28.09 seconds) et que l'archive après compression et déduplication occupe 23G sur le disque. ``` df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/loop0 100G 23G 78G 23% /mnt ``` Maintenant on va réaliser la sauvegarde du répertoire `/data/test/o13e-sav`: ``` borg create --stats /mnt/backup::o13e-sav /data/test/o13e-sav/ ------------------------------------------------------------------------------ Archive name: o13e-sav Archive fingerprint: 34f4aabde5e17ec7994aa9e6b83e7da106c39d39dcfce954a65327ba645865e2 Time (start): Fri, 2022-01-14 14:29:39 Time (end): Fri, 2022-01-14 14:43:03 Duration: 13 minutes 24.47 seconds Number of files: 299614 Utilization of max. archive size: 0% ------------------------------------------------------------------------------ Original size Compressed size Deduplicated size This archive: 47.09 GB 25.50 GB 491.34 MB All archives: 95.01 GB 51.27 GB 25.02 GB Unique chunks Total chunks Chunk index: 161488 615580 ------------------------------------------------------------------------------ ``` On constate que la seconde sauvegarde est moins longue (13 minutes 24.47 seconds) et que l'archive après compression et déduplication n'occupe que 24G sur le disque (491.34 MB supplémentaires après déduplication). ``` df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/loop0 100G 24G 77G 24% /mnt ``` On peut maintenant démonter l'image disque afin de la supprimer: ``` umount /mnt losetup -d /dev/loop0 rm /data/test/disk-xfs.img ``` ### Déduplication BTRFS avec duperemove La déduplication intrabande/synchrone/en ligne n'est pas activement développée, mais il existe plusieurs outils qui adoptent différentes approches de la déduplication, offrant des fonctionnalités supplémentaires ou font des compromis. Le tableau suivant répertorie les outils connus pour être à jour, maintenus et largement utilisés. ^ Nom ^ Basé sur des fichiers ^ Basé sur des blocs ^ systèmes de fichiers ^ sauvegardes incrémentielles ^ Notes ^ | duperemove | Oui | Non | btrfs, xfs | Oui | Base de données Sqlite pour csum. Fonctionne par limite d'étendue par défaut, mais a une option pour comparer plus attentivement. | | bees | Non | Oui | btrfs | Oui | Fonctionne comme un démon. Base de données très légère, utile pour les grands stockages comme les serveurs de sauvegarde. Utilise SEARCH_V2 et LOGICAL_INO. | | dduper | Oui | Oui | btrfs| Oui | Utilise l'arbre csum BTRFS intégré, il est donc extrêmement rapide et léger (13,8 secondes pour des fichiers identiques de 10 Go). Nécessite le correctif BTRFS-PROGS pour l'accès csum. | Légende: * **Basé sur un fichier** : l'outil prend une liste de fichiers et déduplique les blocs uniquement à partir de celui-ci * **Basé sur les blocs**: l'outil énumère les blocs et recherche les doublons Les deux fournisseurs les plus accessibles de noyaux btrfs compatibles CentOS sont El Repo Mainline et Oracle Unbreakable Enterprise Kernel (UEK).\\ \\ CentOS 7 prend en charge les btrfs natifs en tant qu'option personnalisée dans le programme d'installation du système d'exploitation (en tant que "prévisualisation technologique"), mais cela a été supprimé du programme d'installation de CentOS 8. Les utilisateurs de CentOS 8 doivent installer l'UEK, mais il y a deux problèmes majeurs avec l'UEK, à la fois en général et du point de vue de CentOS:\\ - Premièrement, Oracle UEKR6 est (actuellement) trop ancien pour utiliser les dernières fonctionnalités de somme de contrôle de btrfs (expliquées dans la section suivante).\\ - Deuxièmement, un support payant est disponible pour l'UEK sur CentOS, mais uniquement après une conversion de l'ensemble du système vers Oracle Linux. Le chargement de l'UEK ne déclenche pas cette conversion. De plus, le processus de conversion semble interrompu pour Centos 8. On peut se demander si Oracle prend en charge la plate-forme CentOS 8. Pour tester la déduplication sur BTRFS on va installer duperemove (le dépôt epel doit être activé): ``` yum install -y epel-release yum install duperemove ``` Créer un fichier img: ``` fallocate -l 100G disk-btrfs.img du -hs disk-btrfs.img 100G disk-btrfs.img ``` Créer maintenant un périphérique de boucle avec ce fichier : ``` losetup -f disk-btrfs.img losetup -a /dev/loop0: [0046]:258 (/data/test/disk-btrfs.img) ``` Créer un système de fichiers BTRFS: ``` mkfs.btrfs disk-btrfs.img btrfs-progs v4.9.1 See http://btrfs.wiki.kernel.org for more information. Label: (null) UUID: 3263d05e-802b-4be5-853d-244d43592158 Node size: 16384 Sector size: 4096 Filesystem size: 100.00GiB Block group profiles: Data: single 8.00MiB Metadata: DUP 1.00GiB System: DUP 8.00MiB SSD detected: no Incompat features: extref, skinny-metadata Number of devices: 1 Devices: ID SIZE PATH 1 100.00GiB disk-btrfs.img ``` On peut maintenant monter `/dev/loop0` sur un répertoire : ``` mount /dev/loop0 /mnt df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/loop0 100G 17M 98G 1% /mnt ``` On peut maintenant dédupliquer des fichiers de ce système de fichiers avec un outil comme duperemove. On va créer un fichier de test ayant un contenu aléatoire: ``` dd if=/dev/urandom of=/mnt/test bs=1M count=100 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 0.836049 s, 125 MB/s ``` Puis on créer une copie de ce fichier: ``` cp /mnt/test /mnt/test2 ``` Maintenant 218M sont utilisés: ``` df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/loop0 100G 218M 98G 1% /mnt ``` On exécute duperemove: ``` duperemove -dr /mnt df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/loop0 100G 117M 98G 1% /mnt ``` Maintenant le système de fichiers n'utilise plus que 117 M Afin de pouruiver les test, on copie les deux dossiers o13e dupliqués dans `\data\tests`: ``` cp -a /data/test/o13* /mnt ``` Les deux dossiers occupent 98G soit 92% du système de fichiers: ``` df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/loop0 100G 90G 8.6G 92% /mnt ``` **duperemove** affiche la progression des fichiers traités et celle des fichiers à dédupliquer: ``` [0x25cdc00] (2341/2341) Try to dedupe extents with id 0bdd7d24 [0x25cdc00] Dedupe 1 extents (id: 0bdd7d24) with target: (0, 804015190), "/mnt/o13e-sav/dgi/sauvegarde/OP_Schedule.old.tar.gz" ``` Maintenant les deux dossiers n'utilisent plus que 62G soit 63% du système de fichiers: ``` df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/loop0 100G 62G 37G 63% /mnt ``` Mais les système de fichiers a conservé la même quantité de données dans chacun d'eux ``` du -sh * 46G o13e 45G o13e-sav 100M test 100M test2 ``` Lorsqu'on supprime le dossier le plus ancien, la quantité de données dans le second dossier reste la même: ``` rm o13e -rf du -sh * 45G o13e-sav 100M test 100M test2 ``` Les fichiers dédupliqués demeurent utilisables ``` tar xf o13e-sav/dgi/sauvegarde/OP_Schedule.old.tar.gz 6.8G OP_Schedule ``` On peut maintenant démonter l'image disque afin de la supprimer: ``` umount /mnt losetup -d /dev/loop0 rm /data/test/disk-btrfs.img ``` ### Déduplication ZFS Pour des motifs de licence, ZFS n'est pas activé par défaut dans les kernels linux, mais pour les distributions à basées sur RHEL et CentOS, des packages de style kmod de suivi DKMS ou kABI sont fournis à partir du référentiel OpenZFS. Ces packages sont mis à jour au fur et à mesure que de nouvelles versions sont publiées. Seul le référentiel actuel de chaque version majeure est mis à jour avec les nouveaux packages. Pour simplifier l'installation, un package zfs-release est fourni, qui comprend un fichier de configuration zfs.repo et une clé de signature publique. Tous les packages OpenZFS officiels sont signés à l'aide de cette clé et, par défaut, yum ou dnf vérifiera la signature d'un package avant de permettre son installation. Pour les versions 6 et 7 de RHEL/CentOS, exécuter : ``` yum install -y epel-release yum install https://zfsonlinux.org/epel/zfs-release$(rpm -E %distro).noarch.rpm rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-zfsonlinux ``` Après avoir installé le package zfs-release, on peut choisir d'installer les packages de style kmod DKMS ou kABI-tracking. Par défaut, le package zfs-release est configuré pour installer des packages de style DKMS afin qu'ils fonctionnent avec une large gamme de noyaux. Pour installer les packages de style DKMS, exécuter les commandes suivantes. Ajouter d'abord le référentiel EPEL qui fournit DKMS en installant le package epel-release, puis les packages kernel-devel et zfs (il est important de s'assurer que le package kernel-devel correspondant est installé pour le noyau en cours d'exécution car DKMS l'exige pour construire OpenZFS). ``` yum install -y kernel-devel yum install -y zfs ``` Les packages kmod de suivi de kABI permettent d'éviter d'avoir à reconstruire OpenZFS pour chaque mise à jour du noyau, mais ils sont uniquement vérifiés pour fonctionner avec le noyau fourni par la distribution.Afin d'installer les kmods de suivi kABI, le référentiel par défaut doit être basculé de zfs à zfs-kmod.\\ \\ `yum-config-manager --disable zfs`\\ `yum-config-manager --enable zfs-kmod`\\ `yum install -y zfs` Activer le module zfs: ``` /sbin/modprobe zfs ``` Créer un fichier img: ``` fallocate -l 100G disk-zfs.img du -hs disk-zfs.img 100G disk-zfs.img ``` Créer maintenant un périphérique de boucle avec ce fichier : ``` losetup -f disk-zfs.img losetup -a /dev/loop0: [0046]:659411 (/data/test/disk-zfs.img) ``` Créer un nouveau pool ZFS pool1 à l'aide des périphériques de stockage /dev/loop0, exécuter la commande suivante : ``` zpool create -f pool1 /dev/loop0 zpool status pool: pool1 state: ONLINE config: NAME STATE READ WRITE CKSUM pool1 ONLINE 0 0 0 loop0 ONLINE 0 0 0 errors: No known data errors ``` La déduplication n'est pas activée par défaut, il faut activer la déduplication sur les pools ZFS avec la commande suivante : ``` zfs set dedup=on pool1 ``` Vérifier si la déduplication est activée sur le pool ZFS **pool1** avec la commande suivante : ``` zfs get dedup pool1 NAME PROPERTY VALUE SOURCE pool1 dedup on local ``` Créer un système de fichiers ZFS **fs1** sur le pool ZFS **pool1** comme suit : ``` zfs create pool1/fs1 ``` Vérifier que le nouveau système de fichiers ZFS **fs1** est bien créé. ``` zfs list NAME USED AVAIL REFER MOUNTPOINT pool1 180K 96.4G 25.5K /pool1 pool1/fs1 24K 96.4G 24K /pool1/fs1 ``` Comme on a activé la déduplication sur le pool **pool1**, la déduplication est également activée sur le système de fichiers ZFS **fs1** (le système de fichiers ZFS l'hérite du pool). ``` zfs get dedup pool1/fs1 NAME PROPERTY VALUE SOURCE pool1/fs1 dedup on inherited from pool1 ``` Comme le système de fichiers ZFS fs1 hérite de la propriété de déduplication (**dedup**) du pool ZFS1, si on désactive la déduplication sur le pool ZFS, la déduplication doit également être désactivée pour le système de fichiers ZFS fs1. Si on ne le souhaite pas, il faut activer la déduplication sur le système de fichiers ZFS fs1.\\ \\ On peut activer la déduplication sur un système de fichiers ZFS comme suit :\\ \\ `sudo zfs set dedup=on pool1/fs1` Monter les système de pool ZFS **pool1**: ``` zfs set mountpoint=/mnt pool1 ``` Maintenant on peut tester la déduplication en copiant le répertoire de sauvegarde à J `/data/test/o13e` dans le système de fichier: ``` cp -a /data/test/o13e /mnt/fs1/ df -h /mnt/fs1/ Filesystem Size Used Avail Use% Mounted on pool1/fs1 103G 46G 57G 45% /mnt/fs1 ``` Comme on peut le voir, la première fois que l'on copie le dossier de sauvegarde, on utilise 46G d'espace disque (45%). On notera également que le taux de déduplication (DEDUP) est de 1,15x. ``` zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT pool1 99.5G 39.4G 60.1G - - 1% 39% 1.15x ONLINE - -(Fri Jan 14 12:53:24)--(master2016:/mnt)- ``` Maintenat on copie le dossier de sauvgarde à J-1 `/test/o13e-sav` dans le système de fichier: ``` cp -a /data/test/o13e-sav /mnt/fs1/ df -h /mnt/fs1 Filesystem Size Used Avail Use% Mounted on pool1/fs1 146G 90G 56G 62% /mnt/fs1 ``` Comme on peut le voir, seuls 56G d'espace disque (62%) sont utilisés même si on stocke deux fois plus de données. Le taux de déduplication (DEDUP) a également augmenté à 2,23x. Cela signifie que la déduplication économise plus de la moitié de l'espace disque. ``` zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT pool1 99.5G 40.4G 59.1G - - 2% 40% 2.23x ONLINE - ``` Plus on stocke de données redondantes sur pool/système de fichiers ZFS, plus le taux de déduplication (DEDUP) des données que l'on stocke sera élevé et plus on économise de l'espace disque avec la déduplication. Pour que la déduplication fonctionne, ZFS doit garder une trace des blocs de données stockés sur le pool/système de fichiers ZFS. Pour ce faire, ZFS crée une table de déduplication (DDT) dans la mémoire (RAM) de l'ordinateur et y stocke les blocs de données hachés du pool/système de fichiers ZFS. Ainsi, lorsqu'on essaye de copier/déplacer/créer un nouveau fichier sur le pool/système de fichiers ZFS, ZFS peut vérifier les blocs de données correspondants et économiser de l'espace disque à l'aide de la déduplication.\\ \\ Si on ne stocke pas de données redondantes sur le pool/système de fichiers ZFS, alors presque aucune déduplication n'aura lieu et une quantité négligeable d'espaces disque sera enregistrée. Que la déduplication économise ou non de l'espace disque, ZFS devra toujours garder une trace de tous les blocs de données du pool/système de fichiers ZFS dans la table de déduplication (DDT).\\ \\ Ainsi, si on a un grand pool/système de fichiers ZFS, ZFS devra utiliser beaucoup de mémoire pour stocker la table de déduplication (DDT). Si la déduplication ZFS ne permet pas d'économiser beaucoup d'espace disque, toute cette mémoire est gaspillée. C'est un gros problème de déduplication.\\ \\ Un autre problème est l'utilisation élevée du processeur. Si la table de déduplication (DDT) est trop grande, ZFS peut également avoir à effectuer de nombreuses opérations de comparaison et cela peut augmenter l'utilisation du processeur de votre ordinateur. Pour connaître la quantité de mémoire utilisée par la table de déduplication (DDT) du pool ZFS pool1 utiliser la commande suivante : ``` sudo zpool status -D pool1 pool: pool1 state: ONLINE config: NAME STATE READ WRITE CKSUM pool1 ONLINE 0 0 0 loop0 ONLINE 0 0 0 errors: No known data errors dedup: DDT entries 467962, size 405B on disk, 285B in core bucket allocated referenced ______ ______________________________ ______________________________ refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE ------ ------ ----- ----- ----- ------ ----- ----- ----- 1 32.2K 1.83G 1.83G 1.83G 32.2K 1.83G 1.83G 1.83G 2 397K 36.3G 36.3G 36.3G 794K 72.7G 72.7G 72.7G 4 19.3K 1.20G 1.20G 1.20G 85.8K 5.55G 5.55G 5.55G 8 6.59K 441M 441M 441M 69.1K 4.57G 4.57G 4.57G 16 1.88K 30.7M 30.7M 30.7M 46.1K 554M 554M 554M 32 162 4.04M 4.04M 4.04M 6.71K 168M 168M 168M 64 99 4.32M 4.32M 4.32M 8.29K 305M 305M 305M 128 24 15K 15K 15K 3.61K 2.23M 2.23M 2.23M 256 7 5K 5K 5K 2.58K 1.92M 1.92M 1.92M 512 13 21K 21K 21K 9.53K 16.7M 16.7M 16.7M 1K 8 38.5K 38.5K 38.5K 11.6K 64.7M 64.7M 64.7M 2K 7 4.50K 4.50K 4.50K 21.0K 12.8M 12.8M 12.8M 4K 13 81.5K 81.5K 81.5K 61.1K 360M 360M 360M 8K 1 512B 512B 512B 8.12K 4.06M 4.06M 4.06M 16K 1 128K 128K 128K 21.7K 2.71G 2.71G 2.71G 64K 1 512B 512B 512B 81.4K 40.7M 40.7M 40.7M 512K 1 512B 512B 512B 644K 322M 322M 322M Total 457K 39.8G 39.8G 39.8G 1.86M 89.1G 89.1G 89.1G ``` Comme on peut le voir, la table de déduplication (DDT) du pool ZFS pool1 stocke 467 962 entrées et chaque entrée utilise 405 octets de mémoire. ``` Mémoire utilisée pour le DDT (pool1) = 467 962 x 405 bytes = 189.52461 megabytes ``` **Désactivation de la déduplication sur les pools/systèmes de fichiers ZFS**: Une fois que l'on a activé la déduplication sur un pool/système de fichiers ZFS, les données dédupliquées restent dédupliquées. On ne peut pas se débarrasser des données dédupliquées même si on veut désactiver la déduplication sur votre pool/système de fichiers ZFS.\\ \\ Pour supprimer la déduplication d'un pool/système de fichiers ZFS :\\ - Copier toutes les données du pool/système de fichiers ZFS vers un autre emplacement.\\ - Supprimer toutes les données du pool/système de fichiers ZFS.\\ - Désactiver la déduplication sur le pool/système de fichiers ZFS avec la commande suivante : `zfs set dedup=off pool1`.\\ - Remettre les données dans le pool/système de fichiers ZFS;\\ \\ Une fois tous les fichiers dédupliqués supprimés et la déduplication désactivée, la table de déduplication (DDT) doit être vide. On peut mainteant démonter le zpool afin de nettoyer l'image disque: ``` zfs umount pool1 zfs destroy pool1/fs1 zpool destroy pool1 losetup -d /dev/loop0 rm /data/test/disk-zfs.img ``` ### Synthèse des tests * Le test avec **BTRFS** et **duperemove** nécessite l'utilisation d'un logiciel afin de réaliser la déduplication, il nécessite la copie des fichiers puis l'exécution de deduperemove. Les deux opérations nécessitent un temps assez long. * Le test avec **ZFS** permet une déduplication efficace et ne nécessite pas d'opération longue puisque la déduplication est réalisée à la volée sans utilisation de logiciel tiers. * Le test avec **XFS** et **borgbackup** présente une meilleure optimisation de l'espace disque mais nécessite également de réaliser des opérations assez longues.