En une phrase : PBS découpe chaque sauvegarde en blocs, identifie chaque bloc par l'empreinte SHA-256 de son contenu, et ne stocke qu'une fois chaque bloc identique dans un datastore. Une sauvegarde reste un point de restauration complet, même si presque tous ses blocs existaient déjà.
La documentation le résume ainsi : « multiple indexes can reference the same chunks, reducing the amount of space needed to contain the data (even across backup snapshots) » (Technical Overview).
1. Deux façons de découper : blocs fixes et blocs dynamiques
Disques de VM : blocs fixes de 4 Mio
Pour une sauvegarde de type bloc (disque de VM, image .img), PBS découpe le contenu en blocs de même taille : « typically 4 MiB », dit la documentation. Dans le code, ce n'est pas seulement typique : l'API de sauvegarde n'a jamais créé d'index fixe dans une autre taille, et depuis PBS 4.2.8 (2 octobre 2026), un index fixe d'une autre taille est refusé à la lecture comme à l'écriture (pbs-datastore/src/fixed_index.rs). Le dernier bloc d'un disque peut être plus petit.
Conséquence pratique : l'option --chunk-size de proxmox-backup-client ne sert à rien pour une image. Notre banc l'a constaté avant de le lire dans le code : en dessous de 4096 Ko, toute archive .img échoue.
Fichiers et conteneurs : blocs dynamiques de 1 à 16 Mio
Pour une sauvegarde de fichiers (archive pxar : conteneurs LXC, serveurs sauvegardés avec le client), PBS place les frontières de blocs selon le contenu, avec une empreinte glissante : « We use a variant of Buzhash » (Technical Overview). Un ajout au milieu d'un fichier ne décale donc pas tous les blocs suivants.
- Taille moyenne visée par défaut : 4 Mio.
- Taille réelle d'un bloc : du quart au quadruple de la moyenne, soit 1 à 16 Mio par défaut (
pbs-datastore/src/chunker.rs). --chunk-size(de 64 Kio à 4 Mio, puissance de 2) règle cette moyenne, pas un maximum.
Chaque bloc, fixe ou dynamique, est ensuite compressé en zstd, quand la compression réduit sa taille, avant d'être chiffré si besoin puis écrit. Pour l'étape suivante, retenez que la compression s'ajoute à la déduplication.
2. La portée : tout le datastore, mais un seul
Les blocs d'un datastore sont rangés dans un unique répertoire .chunks/, où le chemin d'un bloc ne dépend que de son empreinte. Un bloc déjà présent n'est pas réécrit, quelle que soit la machine ou le namespace qui l'envoie. La documentation présente d'ailleurs les namespaces comme un moyen de réutiliser « a single chunk store deduplication domain for multiple sources » (Terminology).
- Stockage : déduplication sur tout le datastore, toutes machines et tous namespaces confondus.
- Réseau : le client télécharge la liste des blocs du snapshot précédent du même groupe et n'envoie pas ceux qu'il y trouve. La première sauvegarde d'une nouvelle VM transfère donc ses blocs, même si le serveur n'en garde qu'un exemplaire.
- Entre datastores : rien. Chacun a son propre magasin de blocs.
3. Chiffrement et déduplication
Un bloc chiffré ne peut pas être identifié par l'empreinte de son contenu chiffré, sinon rien ne se dédupliquerait. PBS calcule l'empreinte sur les données en clair, concaténées à une clé dérivée de votre clé de chiffrement (dans le code : SHA-256(données ‖ id_key), avec une id_key dérivée par PBKDF2, pbs-tools/src/crypt_config.rs). La documentation en donne la raison : deux blocs identiques chiffrés avec des clés différentes donnent deux empreintes différentes (Encrypted Chunks).
- Mêmes données, même clé, plusieurs machines : déduplication normale.
- Deux clés différentes : aucune déduplication entre elles.
- Sauvegarde chiffrée et sauvegarde en clair : aucune déduplication. Activer le chiffrement après coup renvoie donc toutes les données une fois.
Le client ne chiffre que les blocs qu'il doit réellement envoyer : la déduplication se décide sur votre machine, et le serveur ne reçoit que des blocs chiffrés. Chez NimbusBackup : clé non demandée pour la sauvegarde seule ; elle reste chez vous. Pour la créer et la conserver, voir la clé de chiffrement PBS.
4. Lire le facteur de déduplication
Dans l'interface de PBS, onglet Summary du datastore, le cadre Stats from last Garbage Collection affiche un Deduplication Factor. Trois choses à savoir pour le lire correctement :
- Il n'est calculé qu'en fin de garbage collection, et enregistré jusqu'au suivant. Avant le premier, il vaut 1.00.
- C'est un rapport de volumes : la taille logique cumulée de tous les index de tous les snapshots (
index-data-bytes), divisée par la place réelle des blocs sur le disque (disk-bytes). Il inclut donc la compression. - Chaque snapshot compte comme une copie complète. Pour une VM, c'est la taille entière du disque virtuel, blocs vides compris. Plus un datastore contient de snapshots, plus le facteur est élevé, sans que la déduplication soit « meilleure ».
En ligne de commande, l'état du dernier garbage collection donne les deux valeurs brutes ; le facteur est leur quotient.
proxmox-backup-manager garbage-collection status <datastore> --output-format json
# facteur = index-data-bytes / disk-bytes5. Nos chiffres mesurés
Nous ne publions pas de « taux typique » : il dépend de vos données. Voici deux mesures que nous avons faites nous-mêmes, avec leur date. Attention, aucune n'est le facteur de PBS décrit plus haut : ce sont des parts de données (ou de blocs) déjà présentes au moment d'une sauvegarde.
MariaDB vers PBS (dumps SQL, blocs dynamiques de 1 Mo en moyenne)
Six bases, environ 30 Gio de dumps non compressés, une sauvegarde par nuit. Part des données du dump déjà présentes sur le datastore, calculée comme 1 − (nouveau / total). Détail complet sur notre banc MariaDB vers Proxmox Backup Server.
| Sauvegarde | Date | Déjà présent | Commentaire |
|---|---|---|---|
| 2ᵉ, 7 h après la 1ʳᵉ | 29/09/2026 | 99,57 % | 132,2 Mio de données nouvelles sur 29,77 Gio |
| 3ᵉ, 24 h après | 30/09/2026 | 97,82 % | 668,9 Mio nouveaux sur 29,93 Gio |
| Après suppression d'une partition mensuelle | 02/10/2026 | 54,4 % | les frontières des INSERT étendus se décalent |
| Nuit suivante | 03/10/2026 | 98,69 % | 36,0 Mio envoyés |
La ligne à 54,4 % est la plus utile : une opération banale côté base suffit à diviser la déduplication d'une nuit. Une moyenne aurait caché ce cas.
Serveur Windows de 1 To
Sur un serveur Windows de 877 Go sauvegardé avec le client Windows, le 2ᵉ passage (18→19/04/2026) a trouvé 99,97 % de ses blocs déjà présents, et n'a envoyé que 1,73 Go. Ici, le pourcentage compte des blocs, pas des octets. Le détail est dans le retour d'expérience Windows 1 To.
6. Garbage collection : pourquoi l'espace ne revient pas tout de suite
Un bloc partagé par plusieurs sauvegardes ne peut pas être effacé dès qu'une d'elles n'en a plus besoin. PBS confie ce travail au garbage collection, en deux phases (Maintenance) :
- Marquage : tous les index sont relus, et la date d'accès (
atime) de chaque bloc référencé est mise à jour. - Balayage : seuls les blocs dont la date d'accès est antérieure à la limite sont effacés. Par défaut, cette limite est de 24 h 5 min avant le début du garbage collection, ou plus tôt si une sauvegarde est encore en cours. Les blocs dans ce délai de grâce sont signalés en fin de tâche comme Pending removals.
Ce délai vient de l'option de montage relatime, qui ne met à jour la date d'accès d'un fichier qu'au plus une fois toutes les 24 h. Il se règle par datastore avec l'option gc-atime-cutoff, en minutes (de 1 à 2880). En pratique, un bloc devenu inutile occupe encore de la place jusqu'au garbage collection qui suit de plus de 24 h son dernier marquage.
7. Ce que ça change pour le prix chez NimbusBackup
Chez NimbusBackup, vous réservez une capacité en To. Ce qui remplit cette réservation, ce sont les blocs stockés une seule fois et compressés, pas la somme de vos sauvegardes : la déduplication détermine combien de points de restauration tiennent dans les To réservés. Pour dimensionner, partez du volume de vos données, puis ajustez la réservation après les premiers garbage collections, quand la place réellement occupée est connue.
Pour comparer les offres et estimer votre besoin, voir choisir mon backup.
Questions fréquentes
Quel taux de déduplication attendre avec Proxmox Backup Server ?
Il dépend entièrement de vos données, et nous ne publions pas de moyenne. Sur notre banc MariaDB, 97,82 % des données d'un dump étaient déjà présentes 24 h après le précédent (30/09/2026), mais seulement 54,4 % le lendemain de la suppression d'une partition (02/10/2026). Le « Deduplication Factor » affiché par PBS est un autre indicateur : il inclut la compression et compte chaque snapshot comme une copie complète.
Deux VM identiques sont-elles stockées deux fois dans PBS ?
Non, si elles sont sauvegardées dans le même datastore : chaque bloc identique n'y est stocké qu'une fois, tous namespaces et toutes machines confondus. En revanche, le client n'évite l'envoi réseau que des blocs déjà présents dans le snapshot précédent du même groupe : la première sauvegarde d'une nouvelle VM transfère ses blocs, même si le serveur n'en garde qu'un exemplaire. Deux datastores différents ne partagent rien.
Le chiffrement côté client empêche-t-il la déduplication ?
Non, tant que la clé est la même. L'empreinte d'un bloc chiffré est calculée sur les données en clair et une clé dérivée de la clé de chiffrement : les mêmes données avec la même clé donnent la même empreinte, et se dédupliquent. Avec deux clés différentes, ou entre une sauvegarde chiffrée et une sauvegarde en clair, il n'y a aucune déduplication.
Un PBS hébergé, dimensionné sur la place réelle
NimbusBackup héberge des Proxmox Backup Server managés : vous réservez des To, la déduplication et la compression font tenir vos sauvegardes dedans, et la clé de chiffrement reste chez vous. À partir de 12 € HT par To et par mois.