Introduction #

La déduplication est l’une des caractéristiques majeures qui distinguent Cybee des solutions de sauvegarde traditionnelles.

Dans Cybee, chaque octet stocké dans le dépôt a été passé au crible d’un algorithme de déduplication avant d’être transmis au stockage objet S3 : seules les données réellement nouvelles sont envoyées et conservées.

Cette propriété est décisive pour les clients dont les serveurs contiennent de nombreux fichiers similaires, des sauvegardes fréquentes, ou des volumes de données importants. Comprendre ce mécanisme permet de dimensionner les dépôts, d’expliquer les ratios de compression aux clients et de diagnostiquer des comportements de stockage inattendus.

Les quatre objets fondamentaux du format utilisé #

Avant d’expliquer la déduplication, il est nécessaire de maîtriser la terminologie exacte utilisée chez Cybee :

Règle fondamentale du format : tous les fichiers d’un dépôt Cybee sont écrits une seule fois et ne sont jamais modifiés. Seule l’opération d’élaguage appelée prune supprime des données du dépôt.

Le mécanisme de déduplication : CDC + SHA-256 #

Étape 1 — Découpage en chunks par Content-Defined Chunking (CDC) #

La solution Cybee ne découpe pas les fichiers en blocs de taille fixe comme le font les solutions de sauvegarde traditionnelles. Elle utilise le Content-Defined Chunking (CDC), un algorithme qui détermine les points de découpe en analysant le contenu du fichier lui-même via une fonction de hachage glissante (Rabin fingerprint).

La conséquence directe est capitale : si un fichier est modifié au milieu, seuls les chunks dont le contenu a réellement changé sont nouveaux. Les chunks avant et après la modification sont identiques à ceux de la sauvegarde précédente et ne sont pas re-transmis.

Fichier original :
[  chunk A  ][  chunk B  ][  chunk C  ][  chunk D  ]

Fichier modifié (insertion au milieu) :
[  chunk A  ][  chunk B' ][  chunk C  ][  chunk D  ]
                  ↑
              Seul ce chunk est nouveau — les 3 autres existent déjà dans le dépôt

Cette approche est particulièrement efficace pour :

• Les sauvegardes images d’OS (Windows, Linux) : une VM modifiée ne retransmet que les blocs de données qui ont changé

• Les bases de données : seuls les blocs contenant les pages modifiées depuis la dernière sauvegarde sont nouveaux

• Les archives et répertoires de fichiers : tout fichier identique à une version précédente n’est pas retransmis

Étape 2 — Identification par empreinte SHA-256 #

Chaque chunk produit par le CDC se voit attribuer une empreinte SHA-256 de son contenu. Cette empreinte est l’identifiant unique et universel du chunk dans le dépôt (c’est ce qui appellé le Storage ID).

Avant d’écrire un chunk dans le dépôt, l’index du dépôt est consulté pour vérifier si un Blob portant cette empreinte SHA-256 existe déjà. Si oui, le chunk n’est pas re-transmis. Si non, il est écrit dans un nouveau Pack.

Nouveau chunk produit par CDC
        │
        ▼
  Calcul SHA-256
        │
        ▼
  Lookup dans l'index du dépôt
        │
   ┌────┴────┐
   │         │
Existe     N'existe
  déjà       pas
   │         │
Ignoré    Écrit dans
           un Pack

Étape 3 — Regroupement en Pack files #

Les Blobs sont regroupés dans des Pack files avant d’être écrits sur le stockage objet. Un Pack file contient typiquement plusieurs Blobs. Cette organisation permet de limiter le nombre d’objets S3 créés — un seul objet S3 par Pack, et non un objet par chunk.

Chaque Pack file dispose d’un en-tête chiffré décrivant les Blobs qu’il contient (empreintes, offsets, longueurs), permettant à Cybee de retrouver et déchiffrer précisément un Blob individuel sans charger l’intégralité du Pack.

Étape 4 — Chiffrement avant stockage #

Les Blobs sont chiffrés (AES-256-CTR + Poly1305-AES pour l’authentification) avant d’être assemblés dans les Packs et écrits sur le stockage. La déduplication opère donc sur les données en clair côté agent, avant chiffrement — ce qui maximise l’efficacité de la déduplication (deux fichiers identiques produisent le même hash SHA-256 et un seul Blob, même si leurs versions chiffrées seraient différentes).

La déduplication inter-sauvegardes #

La déduplication Cybee est inter-sauvegardes par nature : elle s’applique non seulement au sein d’une même sauvegarde, mais aussi entre toutes les sauvegardes d’un même dépôt.

Exemple concret — Serveur de fichiers avec sauvegardes quotidiennes #

Un serveur contient 100 Go de données. Chaque jour, 2 Go de fichiers sont modifiés.

Sans déduplication, 30 sauvegardes complètes auraient consommé 3 000 Go. Avec la déduplication Cybee, la consommation est d’environ 160 Go pour le même niveau de protection.

Déduplication entre machines différentes dans le même dépôt #

Lorsque plusieurs machines partagent un même dépôt partagé dans Cybee, la déduplication s’applique entre toutes les sources. Des fichiers identiques présents sur plusieurs machines — binaires système, librairies partagées, templates, images de base — ne sont stockés qu’une seule fois.

Ce comportement est une des raisons pour lesquelles le dépôt partagé Cybee maximise les économies de stockage : plus les machines sauvegardées se ressemblent (même OS, mêmes applicatifs), plus le taux de déduplication est élevé.

Déduplication et compression #

La solution Cybee intègre la compression. Compression et déduplication sont deux mécanismes complémentaires qui opèrent à des niveaux différents :

Les deux s’appliquent conjointement : un Blob est d’abord dédupliqué (s’il est nouveau), puis compressé avant d’être chiffré et écrit dans le Pack.

Trois modes de compression sont disponibles, Cybee utilise par défaut le mode auto

Ce que la déduplication ne couvre pas #

Il est important de comprendre les limites du mécanisme pour éviter des attentes erronées sur les mécanismes de dédumplications:

Impact sur le dimensionnement du stockage #

En pratique, le taux de déduplication obtenu dépend fortement du profil des données sauvegardées :

Cybee : pourquoi le CDC change tout #

Les solutions de sauvegarde traditionnelles utilisent des blocs de taille fixe. Si un octet est inséré au début d’un fichier de 10 Go, tous les blocs suivants sont décalés et apparaissent comme nouveaux — la déduplication est inefficace.

Avec le CDC utilisé par la solution Cybee, les points de découpe sont déterminés par le contenu et non par la position. Une insertion en début de fichier ne perturbe que les chunks directement affectés ; les chunks non modifiés retrouvent leurs mêmes empreintes SHA-256.