Stratégies de déduplication pour le stockage cloud

La déduplication de fichiers réduit le stockage cloud de 20 à 90 % selon la charge de travail, en utilisant l'une des trois techniques suivantes : niveau fichier (stocker les fichiers identiques une seule fois, indexés par hash SHA-256), niveau bloc (découper les fichiers en blocs de 4 à 128 Ko et dédupliquer par bloc), ou découpage à longueur variable via le Content-Defined Chunking (CDC) avec des empreintes Rabin. Les sauvegardes de VM atteignent des réductions de 10:1 ; les fichiers bureautiques courants, 2:1 ; les médiathèques, presque rien. Choisissez la technique qui correspond à vos données — exécuter la dédup bloc sur une bibliothèque de .mp4 déjà uniques gaspille du CPU sans aucun gain.

Dédup niveau fichier : le gain le plus simple

La dédup niveau fichier compare les hashes de fichiers entiers. Deux fichiers avec le même SHA-256 sont identiques ; gardez l'un, pointez l'autre vers lui. L'implémentation prend un week-end :

1. Inventoriez le contenu du bucket (S3 Inventory, Azure Inventory, liste de bucket GCS)
2. Calculez le SHA-256 pour chaque objet (ou utilisez les ETags fournis par le fournisseur, avec des mises en garde)
3. Regroupez par hash, choisissez une clé canonique par groupe, mettez à jour les références, supprimez les doublons

Mises en garde : les ETags S3 correspondent au SHA-256 uniquement pour les envois en partie unique inférieurs à 5 Go. Les envois multipart utilisent une formule différente (hash de hashes). Pour une dédup fiable, calculez votre propre hash avec aws s3 cp s3://bucket/cle - | sha256sum ou calculez à l'envoi et stockez dans les métadonnées.

La dédup niveau fichier brille quand les utilisateurs envoient régulièrement les mêmes fichiers — PDFs de fournisseurs, modèles d'entreprise, images partagées. Attendez-vous à 10 à 30 % d'économies sur les charges de travail bureautiques typiques.

Dédup niveau bloc : le multiplicateur

La dédup niveau bloc découpe chaque fichier en blocs de taille fixe (4 Ko, 16 Ko, 64 Ko) et hache chaque bloc. Deux fichiers partageant 80 % de leurs blocs ne stockent que les 20 % uniques plus une copie des blocs partagés. Les produits de sauvegarde (Veeam, Rubrik, Commvault), les systèmes de fichiers (ZFS avec dedup=on, Btrfs) et certains clouds de sauvegarde (Backblaze B2 avec dédup côté client) utilisent cette technique.

Avantages : compression massive sur les images VM, sauvegardes de bases de données et archives de journaux où les fichiers partagent de larges plages. Inconvénients : forte utilisation mémoire (l'index de dédup vit en RAM), coût CPU à l'écriture, et amplification catastrophique si l'index se corrompt.

Pour le stockage objet cloud, la dédup bloc se produit généralement à l'intérieur d'un produit de sauvegarde plutôt que comme fonctionnalité native. S3 lui-même ne déduplique pas ; Backblaze B2 déduplique à l'envoi quand le client envoie d'abord les hashes de blocs (b2_start_large_file avec des parties pré-hachées).

Content-Defined Chunking (CDC)

Le découpage en blocs de taille fixe échoue quand un octet est inséré au début d'un fichier — tous les blocs suivants hashent différemment. Le Content-Defined Chunking utilise un hash glissant (empreinte Rabin-Karp) pour définir les limites des blocs en fonction des motifs du contenu. Insérez un octet et seul le bloc immédiat change.

Le CDC est la base de restic, BorgBackup, Duplicacy et Kopia. Ces outils open source déduplicent côté client avec des blocs variables d'une moyenne de 1 à 4 Mo. Pour sauvegarder 500 Go de fichiers qui changent de manière incrémentale, les sauvegardes basées sur CDC utilisent souvent moins de 50 Go de stockage unique.

Si vous construisez un système de sauvegarde ou de synchronisation, le CDC via une bibliothèque comme fastcdc-rs ou chunky est le choix moderne. N'implémentez pas votre propre hash glissant — les cas limites sont subtils.

Dédup inline vs post-traitement

La dédup inline s'exécute à l'écriture — avant que les données atteignent le disque, le système vérifie si le bloc existe déjà. Si oui, écrit une référence ; si non, écrit le bloc. Utilisée par ZFS, la plupart des appliances de sauvegarde et certains niveaux de stockage cloud.

La dédup post-traitement écrit d'abord, puis exécute un job en arrière-plan pour trouver les doublons et récupérer l'espace. Utilisée par la Déduplication de données Windows Server, SnapVault de NetApp et la plupart des outils en espace utilisateur. La dédup post-traitement a une latence d'écriture plus faible mais nécessite plus de stockage crête (les doublons existent brièvement avant la récupération).

Pour les charges de travail cloud, la dédup inline est généralement indisponible — S3 ne la propose pas. La dédup post-traitement avec un job planifié (inventaire quotidien, exécution quotidienne de dédup) est le schéma pratique.

Où la dédup n'aide pas

Les données déjà compressées ou chiffrées dédupliquent mal. Deux fichiers .mp4 différents, même de contenu similaire, partagent presque aucun octet. Deux fichiers .zip chiffrés du même texte clair ne partagent zéro octet après le chiffrement — c'est tout le but du chiffrement.

Cela signifie que le stockage de fichiers chiffré de bout en bout ne peut pas dédupliquer entre utilisateurs. Le chiffrement convergent (hacher le texte clair, utiliser le hash comme clé) était une tentative de permettre la dédup entre systèmes E2EE mais présente des problèmes de sécurité — il permet des attaques de confirmation de fichier. Pour les services de fichiers E2EE, acceptez que la dédup se produise dans les fichiers d'un même utilisateur, pas entre utilisateurs.

L'aspect sécurité de la dédup

La dédup inter-utilisateurs dans les systèmes non E2EE crée un canal latéral : si un fichier que vous envoyez déduplique vers un bloc existant, le serveur sait que quelqu'un d'autre avait déjà ce fichier. Dropbox a eu cette exposition en 2011 ; d'autres services aussi. Pour les comptes professionnels partagés c'est correct, mais pour les services qui revendiquent la confidentialité, c'est une fuite.

Si la confidentialité compte, ne déduplicuez qu'à l'intérieur des données d'un même utilisateur (salées avec une clé spécifique à l'utilisateur), pas à travers l'ensemble du système. Ou acceptez que le chiffrement E2EE exclut la dédup et dimensionnez le stockage en conséquence. Les outils qui privilégient la confidentialité — HexaTransfer pour les transferts chiffrés ponctuels, par exemple — échangent l'efficacité de la dédup contre la garantie que personne d'autre (y compris le service) ne peut savoir si deux utilisateurs ont le même fichier. C'est également ce qu'exige le RGPD s'agissant de la minimisation des données.

Mesurer l'efficacité de la dédup

N'activez pas simplement la dédup et espérez. Mesurez le ratio :

ratio_dedup = octets_logiques / octets_physiques

Un ratio de 2:1 signifie que vous stockez 2 octets logiques pour chaque octet physique. Outils de rapport : zpool get dedupratio sur ZFS, Get-DedupStatus sur Windows Server, statistiques par dépôt sur restic/Borg.

Ratios sains par charge de travail :

• Images VM : 8-20:1
• Sauvegardes de bases de données : 10-30:1
• Serveur de fichiers (documents bureautiques) : 1,5-3:1
• Archives d'e-mails : 2-5:1
• Médiathèques : 1,0-1,1:1 (inutile)
• Archives chiffrées : 1,0:1 (impossible)

Si le ratio d'une charge de travail est inférieur à 1,5:1, désactivez la dédup — le CPU et la mémoire ne s'amortissent pas.

Intégration avec les produits de sauvegarde

La plupart des entreprises n'implémentent pas la dédup à partir de zéro — elles utilisent un produit de sauvegarde qui le fait. Points de comparaison lors de la sélection :

• Veeam : dédup bloc inline, blocs par défaut de 512 Ko, compression après dédup
• Rubrik : blocs variables à contenu défini, dédup sous-bloc
• Commvault : dédup côté client avec pools par client et global
• restic/Borg/Kopia : CDC open source, côté client, backends S3/B2/Azure
• BackupPC : niveau fichier par hardlinks, simple mais daté

Pour une PME sauvegardant 2 To vers S3 Glacier, restic vers Glacier Instant Retrieval coûte environ 15 $/mois avec un ratio de dédup de 5:1. Pour un parc de données d'entreprise de 500 To, une plateforme de sauvegarde complète avec dédup s'amortit dès la première année d'économies de stockage.

Quand ajouter la compression par-dessus

La dédup supprime les octets dupliqués ; la compression supprime la redondance au sein des octets uniques. Elles se cumulent. Après dédup, appliquez la compression zstd pour une réduction supplémentaire de 1,5 à 2x sur les données à forte densité textuelle. BorgBackup supporte --compression zstd ; restic a --compression max ; AWS EFS a une compression transparente pour OneZone-IA.

L'ordre compte : dédup d'abord (pour exposer les blocs dupliqués), puis compressez les blocs uniques. Compresser d'abord échoue généralement la dédup parce que de petits changements en entrée se propagent dans toute la sortie compressée. Tous les produits de sauvegarde sérieux gèrent cela correctement — vous choisissez simplement les réglages.

La dédup est ennuyeuse, ingrate, et le levier unique le plus puissant sur les coûts de stockage pour les charges de travail mixtes. Inventoriez les données, choisissez la technique qui correspond au contenu, mesurez le ratio, et récupérez le budget.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.