3. Proxmox Backup Server : pourquoi, et comment ça marche

PBS est un produit distinct de Proxmox VE, avec sa propre installation, sa propre interface web et son propre port. C'est le 8007, à ne pas confondre avec le 8006 de PVE. C'est le premier point à poser, parce qu'il explique la logique de tout le chapitre : la sauvegarde ne vit pas sur l'hyperviseur qu'elle protège.

Voici l'interface du PBS du lab, tel qu'il se présente à la connexion, juste après la création de son datastore :

Le tableau de bord de PBS 4.2.7 (lab) — l'essentiel se lit dans le tableau du milieu.

Trois zones à repérer dès la première connexion.

Le panneau Datastore Usage, sous les informations du serveur, est celui qu'on regarde en premier au quotidien. Il donne l'espace consommé et, surtout, la colonne Estimated Full : la date projetée de saturation, calculée à partir de la tendance.

Sur un datastore neuf, elle affiche Not enough data : il faut quelques jours d'historique. C'est l'indicateur qui prévient avant la panne, plutôt qu'après.

Le menu Datastore, en bas à gauche, liste les magasins de sauvegarde. Un PBS peut en héberger plusieurs, chacun sur un stockage différent — ici un seul, demo-store.

Le Task Summary (30 days), plus bas sur la page, compte les sauvegardes, les élagages, les collectes d'ordures et les vérifications des trente derniers jours. Une sauvegarde qui n'est jamais vérifiée n'est pas une sauvegarde. La ligne Verify doit rester à zéro échec ; c'est l'objet de la section sur la vérification d'intégrité.

« No valid subscription » n'est pas une erreur. Comme pour PVE, PBS fonctionne sans abonnement ; le bandeau signale seulement l'usage du dépôt sans souscription. La ligne Repository Status du panneau du serveur l'indique d'ailleurs explicitement (Non production-ready repository enabled!) — un rappel utile avant une mise en production, où l'on préférera le dépôt entreprise.

3.1 Le problème de vzdump et pourquoi PBS existe

Depuis les débuts de Proxmox VE, vzdump a assuré la sauvegarde des VMs et conteneurs. Son principe est simple : à chaque sauvegarde, il produit une archive complète de la VM — un fichier .vma.zst pour les VMs KVM, un .tar.zst pour les conteneurs LXC.

C'est fiable et facile à comprendre. Mais c'est aussi inefficace.

Prenons un exemple concret : une VM Debian avec 30 Go de données. Vous la sauvegardez tous les jours. Chaque jour, vzdump copie les 30 Go en entier — même si seuls 200 Mo ont changé depuis la veille.

Une semaine de rétention consomme 210 Go. Un mois : 900 Go. Pour une infrastructure de 20 VMs, le dimensionnement du stockage de backup devient problématique.

La sauvegarde incrémentale existe depuis des décennies dans des outils comme Bacula, Amanda ou Veeam. Le principe : ne transférer et ne stocker que ce qui a changé depuis la dernière sauvegarde. Proxmox Server Solutions a implémenté ce principe dans Proxmox Backup Server (PBS), lancé en 2020, écrit entièrement en Rust.

Le choix de Rust est délibéré : c'est un langage compilé, sans garbage collector, qui garantit des performances proches du C avec une sécurité mémoire par construction. PBS partage cette implémentation avec les outils de plus en plus nombreux de l'écosystème Proxmox.

3.2 Déduplication par chunks — le mécanisme clé

La déduplication de PBS découpe chaque sauvegarde en blocs (chunks), calcule l'empreinte SHA-256 de chacun, et ne stocke qu'une fois les blocs identiques. La façon de découper dépend de ce qu'on sauvegarde, et la différence explique les performances de PBS.

Pour un disque de VM : des blocs fixes de 4 Mio. Un disque virtuel est un grand fichier dont les blocs ne se déplacent pas : le secteur 1 000 reste le secteur 1 000.

Un découpage à taille fixe est donc idéal. Il se combine avec le dirty bitmap de QEMU, qui note les blocs modifiés depuis la dernière sauvegarde : PBS n'a même pas besoin de relire les autres.

Pour un conteneur ou des fichiers : des blocs de taille variable. Une archive de fichiers pose un problème que le découpage fixe gère mal.

Insérer un octet au début d'un fichier décale toutes les frontières suivantes, et tous les blocs changent d'empreinte. C'est le problème du boundary shift.

PBS découpe alors selon le contenu : un hachage glissant (Buzhash) parcourt les données et place une frontière quand sa valeur remplit une condition. Une insertion ne déplace que les frontières voisines ; le reste de l'archive produit exactement les mêmes blocs qu'avant.

Le parcours d'une sauvegarde (disque de VM ou archive de conteneur) :

Découpage en blocs : 4 Mio fixes (VM) ou taille variable (conteneur, fichiers).
Pour chaque bloc : calcul de l'empreinte SHA-256.
Le bloc existe-t-il dans le datastore PBS ? - oui → seule la référence est enregistrée (0 octet transféré) ; - non → compression zstd + stockage du bloc.

En pratique, dix VM clonées du même template partagent la plupart de leurs blocs de 4 Mio. À la même position dans l'image disque se trouve le même contenu, donc la même empreinte.

Ces blocs ne sont stockés qu'une fois dans le datastore ; seuls les blocs que chaque VM a modifiés depuis le clonage (données applicatives, journaux, configuration) sont stockés à part. Dix VM installées séparément depuis l'ISO, au contraire, rangent leurs fichiers à des positions différentes et partagent beaucoup moins de blocs.

Le facteur de déduplication s'affiche dans l'interface de PBS, Datastore → demo-store → Summary, et dans le journal de chaque ramasse-miettes (garbage collection, §5.1), qui fait le compte exact :

Dans le Shell de PBS (interface web de PBS → Administration → Shell) :

# Sur PBS : lancer un ramasse-miettes, puis lire la fin de son journal
proxmox-backup-manager garbage-collection start demo-store

Résultat attendu (fin du journal) :

Original data usage: 79.00 GiB
On-Disk usage: 12.20 GiB (15.44%)
On-Disk chunks: 20510
Deduplication factor: 6.47
Average chunk size: 624.18 KiB
TASK OK

Un facteur de 6,47 signifie que 79 Gio de données sauvegardées tiennent dans 12,2 Gio. Ce n'est pas de la compression : ce sont les blocs identiques, stockés une seule fois, qui font la différence.

L'effet est spectaculaire sur un parc homogène. Dix VM Debian partagent l'essentiel de leur système : le second système d'exploitation identique ne coûte presque rien. C'est ce qui rend une rétention longue économiquement tenable — trente sauvegardes quotidiennes ne pèsent pas trente fois la première.

Le ratio se dégrade sur des données déjà compressées ou chiffrées : des vidéos, des archives, ou des disques de VM chiffrés n'ont aucun bloc en commun. Un ratio proche de 1 sur un datastore n'est donc pas un dysfonctionnement, mais le signe que les données ne s'y prêtent pas.

Déduplication vs compression — ne pas confondre : La compression (zstd) réduit la taille d'un chunk en éliminant les redondances internes à ce chunk. La déduplication élimine les chunks identiques entre différentes sauvegardes. PBS applique les deux : chaque chunk unique est d'abord dédupliqué, puis compressé avant d'être écrit sur disque.

Revenons à la définition de base : une sauvegarde est une copie des données, gardée ailleurs, pour les restaurer. Garder trente copies d'un même système coûterait trente fois sa taille, sauf si l'on ne garde qu'une fois ce qui se répète. C'est le principe de PBS :

Terme	Ce que c'est	Dans le laboratoire
Chunk	Un bloc de la sauvegarde : 4 Mio fixes pour une VM, taille variable pour un conteneur	—
Empreinte SHA-256	Un identifiant calculé sur le contenu : même contenu, même empreinte	—
Datastore	Le stockage de PBS, où chaque chunk n'existe qu'une fois	`demo-store`
Index	La liste ordonnée des empreintes qui reconstituent une sauvegarde	Une par sauvegarde, dans Content
Déduplication	Un bloc déjà présent n'est ni transféré ni stocké : seule sa référence est enregistrée	Dix clones du même template partagent leurs chunks
Facteur de déduplication	Données sauvegardées ÷ place occupée	`Deduplication factor` du ramasse-miettes
Dirty bitmap	Les blocs d'un disque de VM modifiés depuis la dernière sauvegarde : seuls ceux-là sont relus	Sauvegarde incrémentale rapide d'une VM allumée
Ramasse-miettes (garbage collection)	Libère les blocs des sauvegardes supprimées par la rétention (§5.1)	`proxmox-backup-manager garbage-collection start demo-store`

Une sauvegarde ne contient que son index ; le datastore garde les chunks. C'est pourquoi trente sauvegardes quotidiennes ne pèsent pas trente fois la première. Un chunk de données déjà compressées ou chiffrées ne ressemble à aucun autre : sur ces données, le facteur reste proche de 1.

Où voir la déduplication :

Notion	Où la voir
Le facteur et l'espace occupé	Interface de PBS : Datastore → demo-store → Summary
Le compte exact	Le journal du ramasse-miettes : `Original data usage`, `On-Disk usage`, `Deduplication factor`
Les sauvegardes (les notices)	Datastore → demo-store → Content ; côté Proxmox VE, le stockage PBS → Backups
La part transférée à chaque sauvegarde	Le journal de la tâche de sauvegarde, côté Proxmox VE

3.3 Chiffrement côté client — un modèle de sécurité fort

PBS intègre un mécanisme de chiffrement AES-256 en mode GCM avec une particularité importante : le chiffrement est côté client. Cela signifie que les données sont chiffrées sur le nœud Proxmox VE avant d'être envoyées vers PBS.

Pourquoi est-ce important ? Dans un modèle de chiffrement côté serveur (comme la plupart des solutions de backup traditionnelles), l'administrateur du serveur de backup peut techniquement accéder aux données déchiffrées. Avec le chiffrement côté client de PBS :

La clé de chiffrement ne quitte jamais le nœud PVE
PBS stocke uniquement des chunks chiffrés opaques
Même un accès physique au serveur PBS ne permet pas de lire les données
Ce modèle est conforme aux exigences de confidentialité les plus strictes. Il répond au RGPD (Règlement général sur la protection des données), à HDS (Hébergement de données de santé) et à PCI-DSS (Payment Card Industry Data Security Standard)

Dans Proxmox VE, le chiffrement est une propriété du stockage PBS, pas de chaque VM : toutes les sauvegardes envoyées par ce stockage sont chiffrées avec la même clé. Il s'active dans Datacenter → Storage → pbs-backup → Edit → onglet Encryption → Auto-generate a client encryption key, ou en ligne de commande :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Générer la clé et l'attacher au stockage PBS (clé stockée côté PVE, sans phrase de passe)
pvesm set pbs-backup --encryption-key autogen

# Relire les métadonnées de la clé : son empreinte, jamais le secret
proxmox-backup-client key show /etc/pve/priv/storage/pbs-backup.enc

Résultat attendu de key show — sur pxe211 avec une clé d'essai créée au même format (proxmox-backup-client key create /tmp/demo-cle.enc --kdf none, supprimée ensuite) :

┌─────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Name        │ Value                                                                                           │
╞═════════════╪═════════════════════════════════════════════════════════════════════════════════════════════════╡
│ path        │ "/tmp/demo-cle.enc"                                                                             │
├─────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────┤
│ kdf         │ none                                                                                            │
├─────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────┤
│ created     │ Tue Sep 29 14:01:27 2026                                                                        │
├─────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────┤
│ modified    │ Tue Sep 29 14:01:27 2026                                                                        │
├─────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────┤
│ fingerprint │ 12:37:94:df:f6:ea:64:4b:9f:1e:c1:27:05:e8:c6:fe:10:ca:30:ac:eb:02:2e:4a:7a:0c:be:f7:5c:f0:b9:3e │
└─────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────┘

kdf none n'est pas un oubli : Proxmox VE doit pouvoir lire la clé seul, à 3 h du matin, sans personne pour taper une phrase de passe. La clé vit donc en clair dans /etc/pve/priv/, lisible par root seulement.

L'empreinte est ce que PBS enregistre avec chaque sauvegarde : c'est elle qui dira, le jour de la restauration, si vous avez la bonne clé. Le client autonome, lui, peut protéger sa clé par une phrase de passe (proxmox-backup-client key create --kdf scrypt).

Avertissement critique : si vous perdez la clé de chiffrement, vos sauvegardes chiffrées deviennent définitivement irrécupérables — même pour l'équipe Proxmox. Or la clé vit sur le cluster : si le cluster brûle, elle brûle avec lui.

Conservez-en toujours une copie hors du cluster, dans un endroit sûr et physiquement séparé : coffre-fort d'entreprise, gestionnaire de secrets (HashiCorp Vault), ou papier. L'onglet Encryption propose de la télécharger et de l'imprimer sous forme de QR code (proxmox-backup-client key paperkey en ligne de commande).

À retenir : PBS est un produit à part (port 8007). Il découpe les sauvegardes en chunks, identifiés par leur empreinte SHA-256, et ne stocke qu'une fois chaque bloc identique : les sauvegardes suivantes ne coûtent que ce qui a changé. Le chiffrement côté client empêche le serveur de lire les données ; la clé perdue, les sauvegardes le sont aussi.