Proxmox Backup Server en profondeur : déduplication, vérification et rétention dans un cloud privé

Presque personne ne regarde ses sauvegardes avant le jour où il en a besoin. Ce jour-là, toutes les questions arrivent d’un coup : la copie existe-t-elle ? Est-elle intègre ? De quand date-t-elle ? Combien de temps prend une restauration ? Se trouve-t-elle au même endroit que le système qui vient de tomber ? Et la pire de toutes : quelqu’un a-t-il déjà prouvé que tout cela fonctionne ?

Dans les environnements Proxmox VE, Proxmox Backup Server (PBS) répond à ces questions mieux que la plupart des alternatives de l’écosystème open source. Nous avons déjà écrit sur le passage de Proxmox du statut d’« alternative » à celui de standard et sur les questions que posent réellement les CIO et les CTO lors d’une migration. Cet article va un cran plus loin et entre dans la mécanique : ce que fait exactement la déduplication, pourquoi la vérification n’est pas optionnelle, ce qui distingue prune et garbage collection, comment un même serveur peut servir plusieurs clients sans rien mélanger, comment récupérer un fichier isolé sans toucher à la machine entière, et comment tout cela se traduit en décisions d’architecture lorsque l’infrastructure vit dans un cloud privé avec du stockage réparti sur deux zones de Madrid distantes de plus de 10 kilomètres.

PBS n’est pas « un logiciel de sauvegarde de plus »

Proxmox Backup Server est une distribution Linux basée sur Debian, écrite en grande partie en Rust et publiée sous licence GNU AGPLv3. Elle est conçue pour une seule chose : stocker et restituer les données de machines virtuelles, de conteneurs et de serveurs physiques. La version 4.2, publiée en avril 2026, repose sur Debian 13.4 « Trixie », le noyau Linux 7.0 et ZFS 2.4, et apporte la prise en charge officielle des stockages objet compatibles S3 comme backend, le chiffrement dans les tâches de synchronisation et le traitement concurrent de plusieurs groupes de sauvegarde.

La différence pratique avec une copie classique vers un disque ou un NAS tient à trois mécanismes qui travaillent ensemble : la déduplication (l’espace occupé), la vérification (l’utilité réelle le jour J) et la rétention (la durée de conservation et le moment où l’espace se libère vraiment). Qui comprend ces trois-là dimensionne correctement. Qui ne les comprend pas finit avec un dépôt saturé, des copies que personne n’a jamais contrôlées et une restauration qui tourne à l’expérimentation.

Déduplication : pourquoi 30 copies n’occupent pas 30 fois la place

PBS ne stocke pas de fichiers de sauvegarde monolithiques. Il découpe les données en blocs — des chunks d’environ 4 Mio en moyenne —, calcule l’empreinte SHA-256 de chacun et ne le stocke qu’une seule fois dans le datastore. Si ce même bloc réapparaît demain, la sauvegarde se contente d’enregistrer une référence.

Trois conséquences à avoir en tête avant tout dimensionnement :

Toutes les sauvegardes sont incrémentales, mais se restaurent comme des complètes. Après la première copie, chaque exécution n’ajoute que les blocs nouveaux. À la restauration, aucune chaîne d’incréments à reconstruire : chaque snapshot se suffit à lui-même.
La déduplication est globale au sein du datastore. Elle ne se limite pas à une VM : dix machines dotées du même système d’exploitation partagent la partie commune une seule fois. Et comme les namespaces vivent à l’intérieur du même datastore, on peut séparer les environnements (production, préproduction, clients) sans perdre cette économie.
Le calcul « taille de la VM × nombre de copies » ne sert à rien. C’est l’opération que tout le monde fait lors de la première réunion, et le chiffre obtenu est toujours démesuré. La consommation réelle n’en est qu’une fraction, car ce qui croît n’est pas le nombre de copies mais le volume de données qui change entre elles.

Ce dernier point change la conversation. La bonne question n’est pas « combien pèse chaque sauvegarde ? », mais « quelle quantité de données change chaque jour sur cette plateforme ? ». Une base de données transactionnelle et un serveur de fichiers contenant des documents qu’on ne touche presque jamais peuvent occuper un volume comparable sur disque et exiger des capacités de sauvegarde très différentes.

Côté hyperviseur, un détail accélère nettement le processus : Proxmox VE utilise les dirty bitmaps de QEMU pour savoir quels blocs d’une VM ont été modifiés depuis la dernière copie, sans relire le disque entier. Cette carte réside en mémoire et se perd lorsque la machine est arrêtée ou migrée ; à l’exécution suivante, PBS relira l’intégralité du disque, mais ne transférera et ne stockera que ce qui est réellement nouveau. Une sauvegarde ponctuellement plus lente après une maintenance n’est donc pas le signe d’une panne.

Vérification : découvrir la corruption tant qu’elle n’a pas d’importance

Le problème du bit rot, c’est qu’il ne prévient pas. Un bloc peut se dégrader sur le support, une défaillance matérielle ou logicielle peut altérer des données déjà écrites, et rien ne passe au rouge dans la console. La sauvegarde continue d’apparaître dans la liste, avec sa date et sa taille. Le jour où l’on en a besoin, elle ne s’ouvre pas.

PBS répond à cela avec des tâches de vérification planifiables : elles relisent les blocs stockés, recalculent leurs empreintes et les comparent aux originales. Ce que l’on gagne, ce n’est pas d’éviter la corruption, mais d’avancer le moment où on la découvre : non pas en pleine nuit pendant un sinistre, mais un mardi ordinaire, alors que la bonne copie existe encore ailleurs et qu’il reste de la marge pour réagir.

Deux détails opérationnels qui font la différence sur les grands dépôts :

La vérification peut être configurée pour ignorer les snapshots déjà vérifiés au cours des N derniers jours, afin que chaque passe se concentre sur le nouveau au lieu de relire tout le dépôt chaque semaine.
Un snapshot qui échoue à la vérification est marqué. Faites en sorte que ce marquage atteigne une personne et pas seulement une ligne de journal : une sauvegarde signalée comme défectueuse et laissée de côté est exactement aussi utile que pas de sauvegarde du tout.

Attention toutefois à ne pas confondre deux choses. Vérifier prouve que les blocs sont intègres ; cela ne prouve pas que le service démarre. Qu’une base de données se lève, que l’application se connecte et que l’activité puisse reprendre, seule une restauration réelle le démontre. La vérification est la condition nécessaire ; le test de restauration périodique, la condition suffisante.

Rétention et garbage collection : deux choses distinctes que tout le monde mélange

C’est ici que se loge le malentendu le plus fréquent autour de PBS, et celui qui sature les dépôts : le prune ne libère pas d’espace.

Prune applique la politique de rétention et décide quels snapshots ne sont plus nécessaires. Il supprime la référence à la sauvegarde, mais ne touche pas aux blocs : ils sont dédupliqués et très probablement encore utilisés par une autre copie.
La garbage collection (GC) est ce qui récupère l’espace. Elle parcourt le datastore, marque les blocs encore référencés et supprime les orphelins. Elle travaille avec une marge de sécurité temporelle pour ne jamais effacer les blocs d’une sauvegarde en cours d’écriture : c’est pourquoi l’espace libéré n’apparaît pas instantanément.

Les deux processus se planifient séparément, et les deux doivent être planifiés. Un environnement doté d’une politique de rétention mais sans GC périodique grossit jusqu’à ce que quelqu’un reçoive une alerte de disque plein, en général le week-end.

Quant à la politique elle-même, PBS permet de construire une pyramide à plusieurs niveaux : N dernières, quotidiennes, hebdomadaires, mensuelles et annuelles. Un point de départ raisonnable pour une plateforme de production :

Niveau	Exemple	À quoi cela sert
Dernières	3 copies	Annuler une erreur récente (un déploiement, une suppression)
Quotidiennes	7	Revenir à n’importe quel jour de la semaine écoulée
Hebdomadaires	4	Couvrir le mois avec peu de points de restauration
Mensuelles	6-12	Historique et exigences métier
Annuelles	1-5	Obligations légales ou contractuelles, le cas échéant

La tentation de tout garder « au cas où » est compréhensible, mais la rétention n’est pas une décision technique : c’est une décision métier et, dans certains secteurs, réglementaire. Mieux vaut la fixer par écrit avec celui qui répond des données, plutôt que de la laisser à l’appréciation de celui qui configure la tâche.

Chiffrement côté client : ce qui rend la copie distante viable

PBS chiffre côté client, sur le nœud Proxmox lui-même, avant que les données ne quittent le réseau, en AES-256-GCM. Le serveur de sauvegarde conserve des informations qu’il ne peut pas lire. Cela se lit de deux façons en pratique :

On peut envoyer des copies vers un site distant ou vers un stockage objet sans que la destination ait à être un point de confiance. La donnée voyage chiffrée et reste chiffrée.
Qui perd la clé perd les sauvegardes. Il n’existe aucune récupération possible. La clé doit être gardée comme un actif critique : une copie hors de l’environnement qu’elle protège, une version imprimée en lieu sûr et une procédure écrite précisant qui peut y accéder.

Un détail technique surprend souvent : la déduplication continue de fonctionner avec le chiffrement activé, mais entre sauvegardes partageant la même clé. Utiliser une clé différente par client ou par environnement est un choix d’isolation légitime ; il faut simplement savoir qu’il réduit l’économie d’espace, puisque ces ensembles ne partagent plus de blocs entre eux.

Depuis la version 4.2, les tâches de synchronisation gèrent elles aussi le chiffrement : les tâches push chiffrent avant l’envoi et les tâches pull peuvent déchiffrer des données distantes, avec une gestion des clés centralisée aux côtés de celle des bandes.

Éloigner suffisamment la copie : les sync jobs entre sites

Un dépôt unique, si bien vérifié soit-il, reste un point de défaillance unique. PBS règle la distribution avec des tâches de synchronisation entre serveurs ou datastores : en mode pull, la destination récupère ; en mode push, la source pousse. Dans les deux cas, seuls les blocs manquants voyagent, ce qui rend une réplique quotidienne entre sites parfaitement tenable même sur de gros volumes. La 4.2 ajoute le traitement concurrent de plusieurs groupes, ce qui se remarque surtout lorsqu’il y a de la latence.

Un seul PBS pour plusieurs clients : à quoi servent les namespaces

Les namespaces sont des subdivisions hiérarchiques à l’intérieur d’un même datastore, et ce sont précisément eux qui transforment un serveur de sauvegarde en plateforme multiclient. Grâce à eux, une seule instance PBS peut servir plusieurs clients, plusieurs entités ou plusieurs clusters sans que rien ne se mélange.

Isolation par les permissions. Chaque namespace dispose de ses propres ACL. Un client, un partenaire ou une équipe interne ne voit que sa branche de l’arbre, et les jetons d’API sont émis avec cette portée exacte : impossible de lister, restaurer ou supprimer ce qui se trouve à côté.
Des politiques propres. Rétention, vérification et synchronisation se configurent par namespace. Un client avec sept jours de copies et un autre soumis à une conservation de plusieurs années cohabitent dans le même dépôt sans que l’un impose ses règles à l’autre.
Sans coût de stockage supplémentaire. La déduplication reste globale au sein du datastore : séparer les clients ne multiplie donc pas le stockage. Si chaque client chiffre avec sa propre clé, l’isolation est plus forte, mais les blocs ne sont alors partagés qu’à l’intérieur de chaque ensemble : c’est le prix de cette séparation.
Destination des synchronisations. Une tâche de synchronisation peut déposer chaque source distante dans un namespace précis. C’est le schéma habituel lorsque plusieurs clusters, plusieurs agences ou plusieurs clients sont centralisés sur un seul PBS.

C’est l’architecture qu’utilisent les infogéreurs et les partenaires qui proposent de la sauvegarde en tant que service : un dépôt, de nombreux locataires, des comptes séparés. Avec deux réserves honnêtes. D’abord, il n’existe pas de quotas stricts par namespace : la croissance se pilote par la politique de rétention et la supervision, pas par une limite qui arrêterait un client qui déborde. Ensuite, la récupération d’espace (GC) porte sur l’ensemble du datastore : les fenêtres de maintenance se planifient donc globalement et non client par client.

En 4.2, les groupes et les namespaces peuvent en outre être déplacés, ce qui aide lorsque la structure initiale devient trop étroite — un client qui grandit, un environnement à isoler — et qu’il faut réorganiser sans refaire les sauvegardes.

Sauvegarder depuis la machine : proxmox-backup-client et les fichiers isolés

Jusqu’ici, nous avons parlé de sauvegardes de la machine complète, celles que l’on lance depuis Proxmox VE. Mais PBS ne s’arrête pas là : il existe proxmox-backup-client, un client qui s’installe à l’intérieur de la VM, du conteneur ou d’un serveur Linux physique, et qui sauvegarde exactement les répertoires que vous lui indiquez, avec son propre calendrier, son propre chiffrement et son propre namespace.

Cela change ce que l’on peut récupérer, et à quelle vitesse :

Récupérer un fichier isolé — une pièce jointe supprimée par erreur, un fichier de configuration, le répertoire de données d’une application — sans restaurer la machine entière ni monter une copie parallèle pour en extraire un simple dossier.
Protéger certains chemins à une autre fréquence. Le répertoire de données d’une application peut être sauvegardé toutes les heures tandis que la copie complète de la machine reste quotidienne.
Couvrir des serveurs qui ne sont pas dans ce cluster : machines physiques, systèmes historiques ou hôtes hébergés ailleurs qui envoient leurs données vers le même dépôt, avec le même chiffrement et la même rétention.

La mise en œuvre est simple : on installe le client, on déclare le dépôt et on lance la sauvegarde des chemins choisis, qui voyagent au format pxar et sont dédupliqués et chiffrés comme le reste.

proxmox-backup-client backup donnees.pxar:/var/www \
  --repository backup@pb*@*bs.interne:depot \
  --ns client-a

Ces archives peuvent ensuite être listées ou montées pour n’en extraire que le nécessaire, sans télécharger l’ensemble.

À considérer comme un complément, non comme un remplacement. La copie de la machine complète rétablit le service après un sinistre ; le client installé à l’intérieur règle le « je viens d’effacer un fichier » d’un mardi matin. Pour les sauvegardes de VM, Proxmox VE propose par ailleurs la restauration au niveau fichier depuis l’interface et le live restore, qui démarre la machine pendant que la restauration se poursuit en arrière-plan ; entre ces trois voies, presque tous les incidents réels sont couverts.

Comment cela se concrétise dans un cloud privé Proxmox chez Stackscale

Toute la théorie précédente se ramène à une question très concrète : où vivent les blocs ? Chez Stackscale, nous construisons la sauvegarde des environnements Proxmox sur le stockage Archive, accessible en NFS ou via une API compatible S3, et disponible sur des sites physiquement séparés : deux zones à Madrid, distantes de plus de 10 kilomètres, et une troisième à Amsterdam.

Cette distance n’est pas un détail de brochure. C’est elle qui met deux centres de données à l’abri d’un même incident physique — un incendie, une inondation, une coupure d’alimentation sur une zone — tout en conservant des latences métropolitaines, assez basses pour qu’une synchronisation quotidienne, voire plusieurs par jour, ne devienne jamais un problème. C’est la différence entre « nous avons une copie dans une autre baie » et « nous avons une copie dans une autre zone de risque ».

Architecture de référence

Couche	Où	Pour quoi faire
Datastore principal	Archive à Madrid, zone A (NFS ou S3)	Copie de référence. Toutes les tâches de sauvegarde écrivent ici
Réplique	Archive à Madrid, zone B (>10 km) ou Amsterdam	Sync job quotidien. Survie à la perte complète d’un site
Couche rapide (optionnelle)	Stockage réseau all-flash	Copies les plus récentes, pour restaurations fréquentes et RTO bas
Disque local du PBS	Serveur de sauvegarde	Tampon temporaire tout au plus. Jamais le dépôt unique

Le principe de conception est simple : la copie de référence vit toujours sur Archive, pas sur le disque du serveur qui réalise les sauvegardes. Un dépôt local dépend de la santé d’une machine précise et n’apporte aucune redondance ; si ce serveur disparaît dans le même incident que le cluster, la capacité à restaurer disparaît avec lui. Les couches rapides sont un cache destiné à accélérer les restaurations, pas la source de vérité.

Avec ce schéma, la règle 3-2-1 cesse d’être un slogan : trois copies (production plus deux dépôts), sur des supports et des systèmes différents, dont au moins une hors du site primaire. Et tout cela avec des données dans des centres de données européens, un point passé, dans bien des secteurs, de la préférence technique à l’exigence contractuelle.

Un calendrier d’exploitation qui tient

Plus important que l’architecture : que quelqu’un la maintienne en vie. Voici un calendrier de départ raisonnable pour une plateforme de production :

Tâche	Fréquence indicative	Remarque
Sauvegarde des VM et conteneurs	Quotidienne, en fenêtre de faible charge	Avec limites de bande passante si le réseau est partagé avec la production
Synchronisation vers le second site	Quotidienne, après la fenêtre de sauvegarde	Seuls les blocs nouveaux voyagent
Vérification	Hebdomadaire, en ignorant ce qui est déjà vérifié	Avec une alerte vers une personne, pas seulement vers le journal
Prune	Quotidien	Applique la politique ; ne libère pas d’espace
Garbage collection	Hebdomadaire	C’est elle qui récupère réellement l’espace
Test de restauration	Trimestriel, et après tout changement notable	Restaurer et démarrer, pas seulement vérifier

Six erreurs qui reviennent toujours

Dimensionner en multipliant. Calculer le stockage comme la taille multipliée par le nombre de copies mène à des budgets irréalistes et à des rétentions bien trop courtes.
Planifier le prune et oublier la GC. L’espace ne revient pas tout seul.
Confondre vérification et test de restauration. Ce sont deux contrôles différents et aucun ne remplace l’autre.
Garder la clé de chiffrement dans l’environnement qu’elle protège. Si l’incident emporte le cluster, il emporte la clé avec lui.
Ne concevoir que pour le grand sinistre. La majorité des restaurations réelles portent sur un fichier ou un répertoire, pas sur un centre de données entier ; sans proxmox-backup-client ni restauration au niveau fichier, chaque incident mineur oblige à remonter une VM complète.
Laisser l’unique copie dans le même bâtiment. C’est la réplique vers un second site distant de plusieurs kilomètres qui transforme une sauvegarde en véritable plan B.

Questions fréquentes

De combien d’espace ai-je réellement besoin pour 30 jours de sauvegardes ?

Cela dépend du volume de données qui change, pas de la taille totale des machines. Comme la déduplication est globale au sein du datastore et que les sauvegardes sont incrémentales, conserver 30 jours ne multiplie pas la consommation par 30 : on est bien plus proche de la taille de la première copie augmentée du changement quotidien cumulé. Le plus prudent est de mesurer le taux de changement réel pendant quelques semaines avant de figer le dimensionnement.

Quelle différence entre prune et garbage collection ?

Le prune applique la politique de rétention et retire des snapshots de la liste, mais ne supprime pas les blocs, car ceux-ci sont généralement partagés avec d’autres copies. La garbage collection identifie les blocs qu’aucune sauvegarde ne référence plus et les supprime : c’est à ce moment que l’espace est récupéré. Les deux doivent être planifiés.

Si je vérifie mes sauvegardes, dois-je encore tester des restaurations ?

Oui. La vérification contrôle que les blocs stockés sont intègres ; elle ne contrôle pas que le système démarre, que la base de données est cohérente ou que l’application fonctionne. Seul un test de restauration périodique, avec démarrage réel du service, valide l’ensemble de la chaîne.

Est-il sûr de conserver des sauvegardes sur un site distant ?

Avec le chiffrement côté client, oui : les données sont chiffrées en AES-256-GCM sur le nœud Proxmox avant de sortir et la destination ne peut pas les lire. La contrepartie est la garde de la clé : sans elle, aucune restauration n’est possible, elle doit donc être conservée hors de l’environnement qu’elle protège.

Pourquoi est-il important que les deux zones de Madrid soient distantes de plus de 10 km ?

Parce que cela met les deux sites à l’abri d’un même incident physique — incendie, inondation, coupure électrique de zone — tout en conservant des latences métropolitaines. Cela permet de synchroniser les copies quotidiennement, voire plusieurs fois par jour, sans pénalité d’exploitation, et de satisfaire aux exigences de séparation géographique d’un plan de continuité sans sortir d’Espagne.

Puis-je servir plusieurs clients avec un seul Proxmox Backup Server ?

Oui, grâce aux namespaces. Chaque client travaille dans sa propre branche du datastore, avec des permissions, des jetons d’API, une rétention et une vérification indépendants, tandis que la déduplication reste globale : la séparation ne coûte donc pas de stockage supplémentaire. À noter qu’il n’existe pas de quotas stricts par namespace et que la récupération d’espace concerne tout le datastore.

Puis-je récupérer un fichier isolé sans restaurer toute la machine ?

Oui, de deux façons. Sur une sauvegarde de VM, Proxmox VE propose la restauration au niveau fichier directement depuis l’interface. Et si vous installez proxmox-backup-client dans la machine, vous sauvegardez les chemins qui vous intéressent selon votre propre calendrier, puis vous les listez ou les montez pour n’extraire que le nécessaire.

En résumé

Proxmox Backup Server fait bien la partie difficile : stocker peu, détecter la corruption à temps et restituer les données rapidement. Ce qu’il ne peut pas décider à notre place, ce sont quatre choses : combien de temps on conserve, où vit la seconde copie, qui garde les clés et à quelle fréquence on éprouve une vraie restauration. Ces quatre décisions séparent une sauvegarde qui rassure d’une sauvegarde qui en a seulement l’air.

Chez Stackscale, nous concevons l’ensemble — cluster Proxmox, PBS et stockage Archive sur plusieurs sites — comme une seule pièce. Si vous montez ou révisez la stratégie de sauvegarde de votre environnement Proxmox, parlons-en ensemble.