Impact du chiffrement sur la déduplication🔗

La déduplication est une opération destinée à factoriser les données communes d'un ensemble de données. On retrouve cette notion dans les logiciels de sauvegardes ainsi que dans certains systèmes de fichiers. L'idée est de ne pas répéter des blocs de données identiques, présents au sein d'un groupe de fichiers ou de tout un système de fichiers. L'intérêt de cette technique est de minimiser l'espace de stockage occupé par les fichiers (ou les données) tout en restant moins complexe à gérer qu'une vraie compression. Pour résumer, on peut dire que la déduplication est une méthode de compression de premier niveau, dont l'algorithme est limité à une factorisation de données répétées plusieurs fois à l'identique dans l'espace de stockage.

En ce qui concerne la sauvegarde, la déduplication montre de vrais avantages. Bien souvent, on sauvegarde des contenus proches, ne serait-ce que les mêmes fichiers qu'on sauvegarde tous les jours. Dans un environnement de machines virtuelles, on comprend également qu'il y a de fortes redondances, ne serait-ce que dans les fichiers systèmes communs (fichiers de configuration et binaires systèmes). Disposer d'une option de déduplication dans un système permet donc, à moindres frais, de gagner de l'espace de stockage.

La déduplication peut prendre plusieurs formes. La plus simple des méthodes de déduplication consiste à remplacer les fichiers identiques par des liens vers une seule et même source. Ce principe permet d'utiliser au mieux les capacités de systèmes de fichiers de type Unix qui permettent de créer facilement ces liens. La deuxième forme de déduplication consiste à découper les fichiers (ou les données) en blocs de taille identique et de supprimer les blocs identiques en les remplaçant par des index situés dans une base de référence.

Voilà pour les principes des méthodes de déduplication. En matière d'implémentation, il existe des logiciels dédiés qui gèrent la déduplication des données dans un ensemble fermé. Les logiciels de sauvegarde en font partie: ils ne stockent pas de fichiers exploitables directement mais des ensembles de données dans un format qui leur est propre. Cela peut être dans une base de données SQL ou dans des fichiers. Au niveau des logiciels libres qui gèrent cette déduplication à part entière, on peut citer Obnam et Bup.

Il existe une autre implémentation de la déduplication: celle qui est directement intégrée aux systèmes de fichiers. Cette fonctionnalité existe par exemple depuis quelques années dans le système de fichiers ZFS développé par Sun Microsystems (puis par Oracle). BTRFS, le remplaçant d'ext4 dans le noyau Linux est actuellement développé pour offrir, entre autres, cette fonctionnalité de déduplication. L'intérêt d'une telle option se comprend aisément: plus besoin de logiciel à part pour organiser la déduplication, tout est fait lors des opérations d'écritures des fichiers, de manière transparente. De plus, on peut alors travailler sur une base large de fichiers, c'est-à-dire, tout ce qui sera contenu par le système de fichier au lieu de réserver un espace pour cela.

Hormis les questions de performances des différents algorithmes de déduplication mis en œuvres dans les différentes solutions, se pose la question de l'impact du chiffrement. En effet, il est n'est pas rare de vouloir chiffrer le contenu d'un système de fichiers et bien souvent, ces derniers offrent directement des fonctionnalités sur ce sujet. On peut penser, de prime abord, que le chiffrement des données contenues dans un ensemble de données va nécessairement les transformer. Cette transformation peut remettre en question les blocs de données communs entre plusieurs données

L'objectif de cet article est donc d'essayer de déterminer si le chiffrement des données a un réel impact sur la performance de la déduplication et si oui, dans quelle mesure. Pour ce faire, nous allons déterminer un protocole de tests destiné à prendre en compte des cas concrets de stockage de fichiers dé-dupliqués. Nous aurons également soin de diversifier les outils, les protocoles, les algorithmes de chiffrement.

En ce qui concerne les données à dé-dupliquer, nous allons créer deux jeux:

• un jeu de petits fichiers dont la taille est inférieure à 4Ko (nombre de blocs faibles voire inférieure à celle d'un bloc). Il y aura donc de nombreux fichiers.
• un jeu de fichiers plus volumineux, dont la taille sera comprise entre 5 et 50Mo.
• L'ensemble de ces fichiers occupera une taille similaire d'environ 820Mo pour pouvoir éviter l'effet de bord inhérent au volume.

Voici ce que nous retiendrons pour la création automatisée de ces données.

Pour l'ensemble de fichiers volumineux, nous allons partir de fichiers dits primaires, remplis de données aléatoires et créés par la commande dd qui utilisera le générateur de nombre aléatoire /dev/urandom pour des questions de rapidité (création de 10 fichiers de 5 à 50Mo):

$ for f in $(seq 0 9);do dd if=/dev/urandom of=fichier_$f.data bs=1M count=$(( (f+1)*5 )); done

Pour l'ensemble de petits fichiers, nous allons partir de fichiers textes primaires du répertoire /etc. Il s'agit de fichiers de configuration dont la taille est très souvent inférieure à 4Ko. De plus, ces fichiers seront un bon exemple de ce qu'on peut retrouver comme petits fichiers à dé-dupliquer dans un système courant. Nous n'allons pas réimporter toute l'arborescence de /etc que nous allons plutôt aplanir grâce à la commande suivante: $ for f in $(find /etc/ -type f);do cp $f ./$(basename $f); done

Pour permettre la déduplication, nous allons recopier cet ensemble de fichiers dans d'autres répertoires en nous contentant d'en faire varier 10% du contenu. Cette variation doit avoir lieu aléatoirement dans le fichier. Le script suivant doit nous permettre de générer de nouveaux fichiers dans un autre répertoire en respectant les règles énoncées:

#!/bin/bash
# Script pour faire varier des fichiers

# Il faut renseigner un répertoire source et un répertoire cible
if [ "$#" -lt "2" ];then
  echo "Usage: $0 repertoire_source repertoire_cible"
  exit 1
fi

REP_SRC="$1"
REP_DST="$2"

# vérification du répertoire source
if [ ! -d "$REP_SRC" ]; then
   echo -e "Le répertoire source: $REP_SRC n'existe pas !\n"
   exit 2
fi

if [ ! -d "$REP_DST" ]; then
   mkdir "$REP_DST"
fi

# Création des fichiers initiaux:
for f in $(find "$REP_SRC" -maxdepth 1 -name '*' -type f)
do
  TARGET=$(basename $f)
  TARGET="${REP_DST}/${TARGET}"
  echo "Modification de $f dans $TARGET"

  # Quelques calculs
  SIZE=$(stat -c %s $f) # Taille du fichier à traiter
  # gestion des fichiers vides:
  if [ "$SIZE" -eq "0" ];then
	continue
  fi
  USIZE=$(( SIZE/10 ))              # 10% du fichier
  # Pour définir un emplacement aléatoire dans le fichier, on utilise 
  # la variable Bash $RANDOM. Comme cette dernière varie de 0 à 32767,
  # il faut faire un petit produit en croix pour obtenir une vraie taille variable.
  if [ "$(( SIZE-USIZE ))" -le "32767" ]; then
	CUTTER=$(( $RANDOM % (SIZE-USIZE) ))
  else
	CUTTER=$(( (($SIZE-$USIZE)/32767)*$RANDOM ))
  fi
  # L'espace commun aux fichiers recommence à l'emplacement suivant:
  BCUTTER=$(( $CUTTER + $USIZE ))
  TARGET=$(basename $f)
  TARGET="${REP_DST}/${TARGET}"
  echo "Modification de $f dans $TARGET" 
  # On commence ensuite la création de l'autre fichier
  ## le premier pas est de récupérer ce qui ne change pas (avant le CUTTER)
  dd if=$f of=$TARGET bs=1 count=$CUTTER
  ## Ensuite, on remplit avec d'autres nombres aléatoires:
  dd if=/dev/urandom of=$TARGET bs=1 seek=$CUTTER count=$USIZE
  ## Enfin, on termine le remplissage du fichier cible avec le reste du fichier source:
  dd if=$f of=$TARGET bs=1 seek=$BCUTTER skip=$BCUTTER count=$(( $SIZE - $BCUTTER ))
done

En utilisant le script plusieurs fois, on obtient l'arborescence suivante:

.
├── big
│   ├── dedup1
│   ├── dedup2
│   └── orig
└── small
    ├── dedup1
    ├── dedup2
    ├── dedup3
    …
    ├── dedup31
    └── orig

Dans le répertoire big/orig sont contenus nos gros fichiers originels. Dans small/orig, c'est la même chose pour les petits fichiers. Ensuite, les répertoires dedup"n" correspondent aux répertoires où nous avons fait jouer le script présent plus haut.

En ce qui concerne les logiciels qui font de la déduplication, nous allons évaluer Obnam, Bup et ZFS. Les trois solutions agissent à des niveaux bien différents:

• ZFS est un système de fichiers et la déduplication intervient dans les couches basses.
• Obnam est un logiciel de sauvegarde qui s'appuie sur une déduplication en blocs de tailles identiques. Les blocs sont répartis dans des répertoires et des fichiers.
• Bup est également un logiciel de sauvegarde qui agit au niveau blocs. Les blocs sont répartis dans un arbre git.

Réalisons la déduplication des petits fichiers avec obnam:

$ mkdir obnam_small
$ obnam --repository=./obnam_small --root=./small backup
Backed up 3331 files, uploaded 52.9 MiB in 19s at 2.8 MiB/s average speed
$ SRC=$(du -s ./small | awk '{ print $1 }');CIB=$(du -s ./obnam_small | awk '{ print $1 }'); echo "scale=4;($SRC/$CIB)" | bc
1.9072

On a donc un taux de 1.9072 de déduplication pour les petits fichiers. Voyons maintenant ce qui se passe avec les gros fichiers:

$ mkdir obnam_big
$ obnam --repository=./obnam_big --root=./big backup
Backed up 34 files, uploaded 350.0 MiB in 11s at 32.9 MiB/s average speed
$ SRC=$(du -s ./big | awk '{ print $1 }');CIB=$(du -s ./obnam_big | awk '{ print $1 }'); echo "scale=4;($SRC/$CIB)" | bc
2.3439

Pour les gros fichiers, ça se passe mieux: nous avons un taux de déduplication de 2.3439. On voit donc que même avec un ratio de variation identique de 10% (environ, car les petits fichiers de moins de 10 octets ne se découpent pas facilement par pas de 10%) il y a une différence notable entre un ensemble de petits fichiers répétés plusieurs fois.

Faisons la même chose avec bup. Nous voulons dé-dupliquer nos fichiers dans le répertoire de sauvegarde ./bup:

$ mkdir bup_small
$ bup -d ./bup_small init
$ bup -d ./bup_small index -uv ./small -f ./bup_small/bupindex
$ bup -d ./bup_small save -n small ./small
$ SRC=$(du -s ./small | awk '{ print $1 }');CIB=$(du -s ./bup_small | awk '{ print $1 }'); echo "scale=4;($SRC/$CIB)" | bc
7.2160

Très rapidement, nous pouvons voir que le taux de déduplication de bup sur les petits fichiers est bien meilleur que celui d'obnam. Maintenant, voyons quels sont les résultats de cette même méthode sur les fichiers de grosse taille:

$ mkdir bup_big
$ bup -d ./bup_big init
$ bup -d ./bup_big index -uv ./big -f ./bup_big/bupindex
$ bup -d ./bup_big save -n big ./big
$ SRC=$(du -s ./big | awk '{ print $1 }');CIB=$(du -s ./bup_big | awk '{ print $1 }'); echo "scale=4;($SRC/$CIB)" | bc
2.4723

Pour les gros fichiers, on voit que bup se révèle un peu au-dessus d'Obnam.

Étudions maintenant la déduplication sur un système ZFS. Nous disposons d'un pool ZFS (un zpool) nommé tank. Celui-ci dispose de l'option de déduplication. Nous allons juste copier les fichiers des répertoires dans le point de montage du système de fichiers ZFS: /tank.

$ zpool status
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank    1008M  1,17M  1007M    16%  1.00x  ONLINE  -
$ zfs list

zfs list
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  1,10M   975M    30K  /tank
$ cp -r ./small /tank
$ zpool status
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank    1008M   233M   775M    23%  3.61x  ONLINE  -
$ rm -r /tank/small
$ cp -r ./big /tank
$ zpool status
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank    1008M   335M   673M    33%  2.48x  ONLINE  -

Sur la déduplication des gros fichiers, on voit que ZFS est proche des autres logiciels, un peu meilleur qu'Obnam. Toutefois, sur les petits fichiers, ZFS tire plutôt bien son jeu avec un taux intermédiaire à celui de Bup.

Faisons un petit tableau récapitulatif:

Nous pouvons en retenir que Bup se détache du lot avec les petits fichiers. Globalement, pour les gros fichiers, les performances des trois logiciels évalués sont similaires. Les chiffres ne sont pas vraiment surprenant pour ces fichiers. En effet, si on fait un peu de calculs manuels, on voit qu'il n'y a qu'un jeu de 3 répertoires contenant la même chose (orig, dedup1 et dedup2). Sachant que pour chaque lot de fichiers, j'ai fait varier le contenu de 10%, le contenu fixe qui n'a pas changé représente 1,2 fois le lot originel. 3 que divise 1,2 fait 2,5. On est donc dans l'ordre naturel des performances de la déduplication.

Nous pouvons chiffrer de plusieurs manières et selon de nombreux critères qu'on peut rassembler dans la liste suivante:

• Chiffrement en amont ou en aval de la déduplication. Dans le premier cas, on chiffre des fichiers avant de les injecter dans le système de déduplication. Dans le second cas, on chiffre les blocs déjà dé-dupliqués. Suivant ce critère, on se doute bien que les performances de la déduplication seront différentes. C'est ce que nous essayerons de mesurer.
• Chiffrement symétrique/asymétrique. Dans le premier cas, on utilise des algorithmes connus tels qu'AES ou Blowfish. Il faut juste posséder un mot de passe pour pouvoir déchiffrer. Dans le second cas, on utilise les systèmes de clefs publiques et privées. Ces deux méthodes étant bien différentes, il peut y avoir également un impact soupçonné sur les performances de la déduplication.
• Bien entendu, peut-être que les différents algorithmes utilisés pour chiffrer les fichiers ont un effet. Dans notre cas, nous allons comparer AES et Blowfish pour le chiffrement symétrique.
• Il existe également plusieurs outils pour réaliser le chiffrement. Nous allons en évaluer deux dans nos tests: openssl et gnupg.
• Enfin, certains logiciels intègrent le chiffrement en leur sein. C'est le cas d'Obnam. Il faut également vérifier comment il se comporte en mode chiffrement amont ou chiffrement interne (aval).

Les différents cas qui découlent de ces critères seront maintenant explicités.

Pour ce cas de figure, nous allons utiliser gnupg et ses fonctionnalités de chiffrement symétriques. Nous allons utiliser l'algorithme AES et chiffrer l'intégralité des répertoires small et big. Voici les commandes à lancer:

find small/ -type d -exec mkdir ./chiffre/{} \;
for f in $(find small -type f);do gpg --symmetric -o ./chiffre/$f --passphrase thepassphrase --cipher-algo AES256 $f; done
find big/ -type d -exec mkdir ./chiffre/{} \;
for f in $(find big -type f);do gpg --symmetric -o ./chiffre/$f --passphrase thepassphrase --cipher-algo AES256 $f; done

Ces commandes produisent une arborescence de fichiers similaire à celle située dans les répertoires d'origine mais qui dispose uniquement de fichiers chiffrés. Ils partagent tous le même mot de passe.

On peut déjà remarquer que le chiffrement symétrique de cet ensemble de fichiers prend un temps non négligeable dans le cas de nombreux petits fichiers. En revanche, sur les fichiers volumineux, le chiffrement symétrique ne pose aucun problème (différence de l'ordre d'une seconde sur 20 soit aux alentours de 5% de perte).

• copie de petits fichiers: 40.098s
• copie des petits fichiers avec chiffrement: 3m52.952s
• copie des gros fichiers: 18.699s
• copie des gros fichiers avec chiffrement: 19.793s

Réappliquons les procédures évoquées plus haut avec Obnam, Bup et ZFS et comparons les résultats:

La conclusion s'impose d'elle-même: le chiffrement symétrique avec gnupg et l'algorithme AES supprime complètement les capacités de déduplication des trois logiciels utilisés. Ce comportement semble quasi universel et s'explique par la méthode de chiffrement: une très petite variation du fichier entraîne un changement complet de son contenu chiffré. On ne retrouve donc pas de motifs répétés.

Nous allons reprendre le même protocole que précédemment mais en utilisant l'algorithme blowfish à la place d'AES. La commande gpg va légèrement évoluer:

find small/ -type d -exec mkdir ./chiffre/{} \;
for f in $(find small -type f);do gpg --symmetric -o ./chiffre/$f --passphrase thepassphrase --cipher-algo BLOWFISH $f; done
find big/ -type d -exec mkdir ./chiffre/{} \;
for f in $(find big -type f);do gpg --symmetric -o ./chiffre/$f --passphrase thepassphrase --cipher-algo BLOWFISH $f; done

Voyons quels chiffres nous pouvons sortir de ce mode de chiffrement:

On voit donc ici que dans un mode de chiffrement symétrique, l'algorithme n'a pas d'influence sur la déduplication.

Cette partie a pour objectif de vérifier s'il existe une différence de comportement entre deux outils de chiffrement qui mettent en œuvre les mêmes algorithmes.

La suite de commandes pour réaliser le chiffrement deviendra donc:

find small/ -type d -exec mkdir ./chiffre/{} \;
for f in $(find small -type f);do openssl enc -aes256 -out ./chiffre/$f -pass pass:thepassphrase -in $f; done
find big/ -type d -exec mkdir ./chiffre/{} \;
for f in $(find big -type f);do openssl enc -aes256 -out ./chiffre/$f -pass pass:thepassphrase -in $f; done

Là encore, les chiffres sont sans appel: les outils de chiffrement ont le même impact.

Cette fois, nous allons utiliser un chiffrement asymétrique qui implique de disposer de clefs publiques et privées. Nous allons utiliser GnuPG pour gérer nos clefs de chiffrement ainsi que pour effectuer le chiffrement.

D'abord, il nous faut générer notre clef. Nous allons générer des clefs DSA et RSA d'une taille de 2048 octets pour l'utilisateur Joe Dassin. Je ne reviendrai pas sur la méthode de génération de clef (commande interactive gpg --gen-key). Disons que nous disposons de cette clef:

gpg --list-keys
/home/mederic.ribreux/.gnupg/pubring.gpg
----------------------------------------
pub   2048R/E73ACBFD 2013-05-30
uid                  Médéric RIBREUX <mederic.ribreux@agriculture.gouv.fr>
sub   2048R/37258210 2013-05-30

Nous allons chiffrer à destination de cet utilisateur en utilisant les commandes suivantes:

find small/ -type d -exec mkdir ./chiffre/{} \;
for f in $(find small -type f);do gpg --output ./chiffre/$f --encrypt --recipient mederic.ribreux@agriculture.gouv.fr $f; done
find big/ -type d -exec mkdir ./chiffre/{} \;
for f in $(find big -type f);do gpg --output ./chiffre/$f --encrypt --recipient mederic.ribreux@agriculture.gouv.fr $f; done

Encore une fois, on peut mesurer que le chiffrement asymétrique annule la déduplication.

Obnam propose des options pour réaliser le chiffrement des données qui sont sauvegardées. Il s'appuie sur GnuPG pour réaliser toutes les opérations de cryptographie. Le chiffrement intervient après la déduplication. Dans notre cas, une seule clef publique sera utilisée pour notre ensemble de données.

Il convient de vérifier si ce chiffrement interne a le même comportement que le chiffrement amont.

Les performances en lecture/écriture d'Obnam sont légèrement dégradées par le fait d'utiliser le chiffrement interne. Elles sont similaires aux dégradations constatées lors du chiffrement asymétrique, c'est-à-dire un facteur 4 à 5 pour les petits fichiers et un facteur 1 à 2 pour les fichiers volumineux.

Voici les résultats du taux de déduplication pour Obnam:

• Petits fichiers (clair/chiffrement interne): 1.9072 en clair contre 2.9586 avec le chiffrement interne.
• Fichiers volumineux: 2.4723 en clair contre 2.3457 avec le chiffrement interne.

On voit bien que le chiffrement interne d'Obnam montre des performances très proches du mode non chiffré, voire meilleures pour ce qui concerne les petits fichiers. L'inconvénient de notre test, c'est qu'il utilise la même clef pour tout le dépôt Obnam. Il n'est donc pas garanti que ces taux de déduplication s'appliquent pour un pool de clients disposant chacun de leur clef.

Pour ce cas précis, nous allons utiliser un système de fichiers ZFS. Ce dernier offre une couche de déduplication de blocs directement intégrée au niveau du système de fichiers. Les opérations de déduplication ont lieu en arrière plan de manière complètement transparente pour l'utilisateur. Pour le chiffrement, nous allons utiliser une couche nécessairement située en dessous de ZFS. Elle s'appuiera sur les mécanismes dm-crypt du noyau Linux.

Voici un schéma qui correspond à l'opération d'écriture d'un fichier dans ZFS:

On voit bien que le chiffrement sera géré après la déduplication. D'ailleurs, ZFS ne saura rien du chiffrement situé en dessous de lui: il est géré directement par le noyau qui réalise les opérations cryptographiques nécessaires. On peut donc penser que la déduplication ne sera pas affectée. Il convient toutefois de le mesurer et pour cela, nous allons devoir mettre en place cette infrastructure.

Commençons par créer des volumes dm-crypt. Nous allons créer deux volumes dm-crypt simplement pour pouvoir disposer d'un pool ZFS en miroir. Ces volumes s'appuieront sur les disques durs entiers /dev/sdd et /dev/sde:

# cryptsetup luksFormat /dev/sdd

WARNING!
========
Cette action écrasera définitivement les données sur /dev/sdd.

Are you sure? (Type uppercase yes): YES
Entrez la phrase secrète LUKS :
Verify passphrase:

# cryptsetup luksFormat /dev/sde

WARNING!
========
Cette action écrasera définitivement les données sur /dev/sdd.

Are you sure? (Type uppercase yes): YES
Entrez la phrase secrète LUKS :
Verify passphrase:

Nous pouvons ensuite nommer et utiliser nos volumes chiffrés:

# cryptsetup luksOpen /dev/sdd crypted_sdd
Entrez la phrase secrète pour /dev/sdd
# cryptsetup luksOpen /dev/sde crypted_sde
Entrez la phrase secrète pour /dev/sde

Ensuite, nous pouvons créer un zpool en utilisant nos volumes crypted_sdd et crypted_sde en mode miroir. Ce pool sera nommé backup. Le miroir sert à rendre redondant nos informations. Il correspond également à la configuration qui a été utilisée pour le pool ZFS non chiffré (tank):

# zpool create -f backup mirror /dev/mapper/crypted_sdd /dev/mapper/crypted_sde
# zpool status backup
    pool: backup
   state: ONLINE
    scan: none requested
config:

    NAME             STATE     READ WRITE CKSUM
    backup           ONLINE       0     0     0
      mirror-0       ONLINE       0     0     0
	  crypted_sdd  ONLINE     0     0     0
	  crypted_sde  ONLINE     0     0     0

Activons la déduplication sur le filesystem ZFS qui repose sur le pool backup:

# zfs set dedup=on backup

Enfin, nous pouvons ajouter nos données dans le répertoire backup. Après l'avoir fait, nous pouvons retenir les scores suivants de déduplication:

J'ajoute au passage les données relatives aux temps de traitement:

Comme on pouvait s'y attendre, sous ZFS, le chiffrement en aval de la déduplication n'a aucun impact sur la performance de la déduplication. En revanche, les performances disques deviennent légèrement moindres.

Voici un petit tableau récapitulatif des différents cas d'utilisation du chiffrement dans la déduplication:

Nous pouvons retenir deux points importants. D'abord, nous pouvons dire que le chiffrement en amont avec des solutions non intégrées annule la déduplication, et ce peu importe la méthode de chiffrement ou l'algorithme utilisé !

Ensuite, on a également pu observer que l'utilisation de solutions de chiffrement directement intégrées à la déduplication permet à cette dernière d'être complète. C'est le cas pour le chiffrement interne d'Obnam qui repose sur GnuPG et qui offre des chiffres comparables à ceux du mode non chiffré. À l'inverse, nous avons pu constater que l'utilisation seule de GnuPG en amont pose des problèmes. L'utilisation de ZFS avec une couche de chiffrement située sous le pool ZFS permet à ce dernier d'être pleinement opérationnel du point de vue de la déduplication. Ces opérations de chiffrement se font au détriment des performances globales (vitesse d'écriture notamment).

La recommandation qui découle de ces observations, c'est qu'il faut limiter à un périmètre très restreint les sauvegardes chiffrées en amont si l'on ne souhaite pas mettre en péril l'intérêt d'une solution de déduplication.

À l'inverse, on ne peut pas considérer le chiffrement aval comme une solution sécurisée. En effet, dans tous les cas présentés, la clef de chiffrement est identique pour tout l'ensemble ce qui est une sécurité bien faible et peu adaptée dans un contexte où on cherche à se prémunir de malveillances internes.

De plus, pour le cas de ZFS, le chiffrement se déroule sur le système en activité. Cela ne permet de se prémunir que du vol d'un disque dur. Un accès frauduleux sur un système en activité, utilisant ZFS+dm-crypt, permettra de récupérer l'intégralité des données en clair ce qui est loin de répondre à certaines exigences de sécurité.

Pour terminer, je retiendrai tout de même que la déduplication est une technologie intéressante. Il existe quelques logiciels libres qui la prennent en charge avec des scores tout à fait honorables. Tout ceci devrait nous permettre de trouver de bonnes bases techniques pour mettre en place une sauvegarde dé-dupliquée à grande échelle. Mais ceci est pour un autre article !