Proxmox Backup Server est la solution de sauvegarde libre éditée par Proxmox pour protéger les machines virtuelles, les conteneurs LXC et les hôtes physiques. Contrairement aux sauvegardes intégrées à Proxmox VE, qui produisent toujours une archive complète, il travaille en incrémental avec déduplication : seuls les blocs réellement modifiés sont transférés et stockés. Résultat, une sauvegarde quotidienne d’une VM de 100 Go peut n’occuper que quelques centaines de mégaoctets une fois la première copie effectuée.
Ce guide couvre l’installation, la création d’un datastore (y compris sur stockage S3, nouveauté de la version 4.2), l’intégration à Proxmox VE, la sauvegarde des VM et des conteneurs, la restauration, le chiffrement et la protection contre les rançongiciels.
Versions et périmètre
Proxmox Backup Server 4.2.5-1 (documentation du 5 août 2026), version majeure 4.2 sortie le 29 avril 2026, basée sur Debian 13.4, noyau Linux 7.0 et ZFS 2.4.
Proxmox VE 9.2 côté hyperviseur.
Distribution : Debian uniquement. Proxmox Backup Server n’est pas distribué pour Fedora, Arch ou openSUSE. Le client de sauvegarde, lui, est également packagé pour d’autres systèmes.
Niveau de fiabilité : procédures conformes à la documentation officielle Proxmox, consultée le 27 août 2026. Voir l’encadré de transparence en fin d’article.
Prérequis : un Proxmox VE fonctionnel et un accès root en SSH.
Ce que Proxmox Backup Server change par rapport à vzdump
Proxmox VE sait déjà sauvegarder sans logiciel supplémentaire, via vzdump. Mais la documentation Proxmox est explicite sur la limite de ce mécanisme : les sauvegardes de Proxmox VE sont toujours des sauvegardes complètes, contenant la configuration de la VM ou du conteneur et l’intégralité de ses données.
Concrètement, dix jours de rétention sur une VM de 100 Go, c’est un téraoctet de stockage et dix transferts complets. Proxmox Backup Server change ce modèle : il découpe les données en fragments (chunks) identifiés par leur somme de contrôle, ne stocke chaque fragment qu’une fois, et ne transfère que ceux qui ont changé.
| Critère | vzdump seul | Proxmox Backup Server |
|---|---|---|
| Type de sauvegarde | Toujours complète | Incrémentale après la première |
| Déduplication | Non | Oui, entre snapshots et entre machines |
| Chiffrement | Non | Oui, côté client, AES-256-GCM |
| Vérification d’intégrité | Non | Oui, tâches de vérification par somme de contrôle |
| Restauration d’un seul fichier | Non | Oui |
| Réplication hors site | Manuelle | Tâches de synchronisation intégrées |
| Infrastructure requise | Aucune | Un serveur dédié ou une VM |
Le prix à payer est réel : il faut une machine de plus. Si vous gérez un seul hôte Proxmox avec deux conteneurs et un disque externe, vzdump vers un partage réseau reste un choix défendable. Au-delà, la déduplication rentabilise très vite le serveur supplémentaire.
Si vous n’avez pas encore d’hyperviseur en place, commencez par installer Proxmox VE avant d’ajouter le serveur de sauvegarde : Proxmox Backup Server se connecte à un Proxmox VE existant, il ne le remplace pas.
Pour la sauvegarde de fichiers sur un serveur Linux classique, sans virtualisation, la logique est différente et rsync associé à crontab répond mieux au besoin.
Proxmox Backup Server est-il gratuit ?
Oui. Le logiciel est libre, publié sous licence AGPLv3, et téléchargeable sans compte ni limitation de fonctionnalité. Aucune fonctionnalité n’est verrouillée derrière un abonnement : un serveur sans abonnement sauvegarde, restaure, chiffre et déduplique exactement comme un serveur sous contrat.
Ce qui est payant, c’est l’abonnement de support commercial, qui ouvre l’accès au dépôt « entreprise » et au support technique de l’éditeur. La nuance mérite d’être posée franchement, parce que beaucoup de tutoriels la gomment : la documentation présente le dépôt pbs-no-subscription comme utilisable pour les tests et les usages hors production, et précise qu’il n’est pas recommandé sur des serveurs de production, ses paquets n’étant pas toujours aussi testés et validés que ceux du dépôt entreprise. Gratuit ne veut donc pas dire équivalent : c’est un arbitrage entre coût et niveau de validation, à faire en connaissance de cause.
Sans abonnement, l’interface affiche un avertissement au démarrage et le dépôt entreprise renvoie une erreur d’authentification tant qu’il reste activé. Ce n’est pas une panne, c’est le comportement attendu.
Dimensionner son serveur de sauvegarde
C’est l’étape que la plupart des tutoriels sautent, et c’est celle qui décide si votre serveur tiendra dans deux ans.
RAM, processeur et disques : les chiffres officiels
La documentation distingue deux profils.
Pour une évaluation : un processeur 64 bits de 2 cœurs, 2 Go de RAM, plus de 8 Go d’espace disque, une carte réseau.
Pour la production : un processeur récent Intel ou AMD 64 bits d’au moins 4 cœurs, et surtout une règle de RAM qu’il faut appliquer littéralement — « minimum 4 GiB pour le système, le cache du système de fichiers et les démons Proxmox Backup Server. Ajoutez au moins 1 GiB de plus par TiB d’espace de stockage. »
Attention aux unités : la règle est exprimée en gibioctets par tébioctet, pas en gigaoctets par téraoctet. Un disque vendu pour 32 To offre 29,1 Tio réels.
| Espace du datastore | RAM minimale selon la règle officielle |
|---|---|
| 2 Tio | 6 Gio |
| 4 Tio | 8 Gio |
| 8 Tio | 12 Gio |
| 16 Tio | 20 Gio |
| 32 Tio | 36 Gio |
Si le datastore repose sur ZFS, deux règles officielles coexistent, ne portent pas sur la même base et n’utilisent pas les mêmes unités. Le guide d’installation de Proxmox VE, dans sa section « ZFS Performance Tips », donne une formule de dimensionnement du pool, en unités décimales telles qu’écrites dans la documentation : « A good calculation is 4GB plus 1GB RAM for each TB RAW disk space » (4 Go, plus 1 Go par téraoctet d’espace disque brut du pool).
La documentation de Proxmox Backup Server, elle, se contente d’une recommandation plancher pour le service lui-même, en gibioctets : « ZFS dépend fortement de la mémoire, il est donc recommandé d’avoir au moins 8 Go pour démarrer. En pratique, utilisez-en autant que votre matériel et votre budget le permettent. »
Les deux ne s’additionnent pas mécaniquement, mais elles ne se substituent pas non plus l’une à l’autre : la formule PVE dimensionne le pool ZFS d’après son espace brut en To décimaux, la règle PBS (4 Gio + 1 Gio par Tio de datastore, calculée plus haut, en unités binaires) dimensionne le service de sauvegarde d’après l’espace utile du datastore, et les 8 Go sont un plancher absolu pour que ZFS lui-même reste stable, quelle que soit la taille.
Sur un pool ZFS de 16 To bruts hébergeant un datastore de taille comparable, retenez le plus élevé des calculs applicables — de l’ordre de 20 Go côté pool (4 + 16) et 20 Gio côté datastore dans cet exemple, deux valeurs proches mais qui divergent dès que la taille brute du pool s’écarte de l’espace utile du datastore (RAID, snapshots, marge libre) — et ne descendez jamais sous 8 Go.
Côté disques, la documentation recommande pour le système 32 Gio ou plus, avec un RAID matériel à batterie ou du ZFS redondant. Pour le datastore, elle privilégie « un stockage local rapide délivrant des IOPS élevées en charge d’entrées-sorties aléatoires », avec des SSD d’entreprise. Sur des disques mécaniques, « l’utilisation d’un cache de métadonnées est fortement recommandée » — typiquement un special device ZFS en miroir.
Cette recommandation n’est pas cosmétique. Le garbage collector parcourt l’intégralité des fragments : sur un datastore de plusieurs téraoctets sur disques mécaniques sans cache de métadonnées, l’opération peut durer des heures.
Le piège du système de fichiers
Un datastore Proxmox Backup Server est un répertoire contenant un dossier .chunks composé de 65 536 sous-répertoires, numérotés de 0000 à ffff en hexadécimal. La documentation en tire une exigence exprimée avec deux de plus : le système de fichiers doit supporter au moins 65 538 sous-répertoires dans un même répertoire, les entrées . et .. étant comptées.
Cela exclut ext3, et ext4 lorsque la fonctionnalité dir_nlink est désactivée. FAT est également hors jeu, pour des raisons de limites POSIX et de nombre de fichiers. Les systèmes de fichiers recommandés sont ZFS pour la performance et les snapshots, ext4 ou xfs pour la simplicité.
Vérifiez avant de créer votre datastore, avec une commande non destructive qui ne demande aucun privilège particulier :
# Affiche le type de système de fichiers du point de montage indiqué
findmnt -no FSTYPE --target /mnt/datastore
La sortie doit être ext4, xfs ou zfs. Si elle renvoie ext3 ou un système de fichiers réseau exotique, changez de support avant d’aller plus loin.
Faut-il installer Proxmox Backup Server en machine virtuelle ?
C’est possible, et c’est même une pratique courante en homelab. La documentation ne l’interdit pas et fournit une procédure d’installation sur Debian existant qui fonctionne aussi bien dans une VM.
Mais posez-vous la question qui compte : si l’hôte Proxmox VE brûle, tombe en panne de carte mère ou est chiffré par un rançongiciel, que reste-t-il de vos sauvegardes ? Un serveur de sauvegarde virtualisé sur l’hyperviseur qu’il protège partage le destin de ce dernier.
Deux compromis acceptables : héberger la VM de sauvegarde sur un second hôte physique, ou virtualiser le serveur sur l’hôte principal mais synchroniser son datastore vers une cible distante. La section sur la protection contre les rançongiciels revient sur ce point.
Installer Proxmox Backup Server
Deux voies existent. L’image ISO installe un système complet avec le noyau Proxmox, la gestion ZFS et l’assistant de partitionnement — c’est le choix par défaut sur une machine dédiée. L’installation sur un Debian existant convient à une VM ou à un serveur déjà provisionné.
Sur un Debian 13 existant
Ajoutez le dépôt sans abonnement. Proxmox utilise désormais le format deb822, dans un fichier .sources et non dans l’ancien sources.list :
# Fichier /etc/apt/sources.list.d/proxmox.sources
Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
Récupérez ensuite la clé de signature du dépôt :
# Téléchargement de la clé d'archive Proxmox pour Debian 13 (Trixie)
wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
-O /usr/share/keyrings/proxmox-archive-keyring.gpg
Vérifiez son empreinte avant de l’utiliser. La documentation publie la somme de contrôle attendue, et un écart signifie que le fichier téléchargé n’est pas celui publié par Proxmox :
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg
# Attendu :
# 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45
Installez enfin le serveur :
apt update
apt install proxmox-backup-server
Le paquet proxmox-backup-server fournit le serveur seul. Le méta-paquet proxmox-backup installe en plus le noyau Proxmox — utile sur une machine physique où vous voulez ZFS et les pilotes récents, superflu dans une VM.
L’interface web répond ensuite sur le port 8007, en HTTPS, avec un certificat auto-signé : https://adresse-du-serveur:8007. Connectez-vous avec l’utilisateur root@pam et le mot de passe système.
Depuis l’image ISO
Téléchargez l’ISO depuis la page de téléchargement officielle, écrivez-la sur une clé USB, démarrez dessus et suivez l’assistant : disposition disque, réseau, nom d’hôte, mot de passe root. L’installateur écrase intégralement le disque cible.
Avertissement
L’installateur ISO efface la totalité du disque sélectionné, table de partitions comprise. Vérifiez le disque cible dans l’assistant avant de valider : sur un serveur multi-disques, une erreur de sélection détruit les données sans confirmation supplémentaire.
Créer un datastore
Un datastore est l’espace où les sauvegardes atterrissent. Sans datastore, le serveur est installé mais inutilisable.
Datastore local
Dans l’interface, la section Datastore de la barre latérale propose Add Datastore. Trois informations suffisent : un nom, un chemin sur le système de fichiers, et éventuellement une planification de garbage collection et de vérification.
Le chemin doit pointer vers un système de fichiers validé à l’étape précédente. Évitez de placer le datastore sur le disque système : une saturation rendrait le serveur inutilisable au moment précis où vous en auriez besoin.
Datastore sur stockage S3 : la nouveauté 4.2
C’est le changement majeur de la version 4.2, et c’est aussi le point que les tutoriels français existants ne couvrent pas — la plupart ont été écrits avant avril 2026 ou n’ont pas été mis à jour depuis.
Le principe : le datastore ne réside plus sur un disque local mais dans un bucket compatible S3, avec un cache local qui absorbe les entrées-sorties.
La fonctionnalité a mûri sur trois versions. Le backend S3 est apparu en avant-première technologique dans la version 4.0, le 6 août 2025. La 4.1, le 26 novembre 2025, y a ajouté la limitation de débit sur les points de terminaison, toujours en avant-première. La 4.2 l’a fait passer en fonctionnalité officiellement supportée. Si vous êtes en 4.0 ou 4.1, le backend existe donc déjà chez vous, avec le statut d’avant-première.
La configuration se fait en deux temps. D’abord un point de terminaison S3, avec clé d’accès, clé secrète et URL du bucket :
# Déclaration du point de terminaison S3
# --access-key, --secret-key et --endpoint sont obligatoires
proxmox-backup-manager s3 endpoint create my-s3-ep \
--access-key 'ma-cle-d-acces' \
--secret-key 'ma-cle-secrete' \
--endpoint '{{bucket}}.s3.{{region}}.amazonaws.com' \
--region eu-central-1
Les accolades doubles ne sont pas une coquille : ce sont des variables que Proxmox Backup Server remplace lui-même. Avec un bucket mon-bucket en région eu-central-1, l’exemple ci-dessus se développe en mon-bucket.s3.eu-central-1.amazonaws.com.
Seuls --access-key, --secret-key et --endpoint sont formellement obligatoires ; la commande accepte une douzaine d’options supplémentaires. En pratique, --region le devient dès que l’URL du point de terminaison contient la variable {{region}}, comme dans l’exemple AWS ci-dessus : sans elle, la variable ne peut pas être résolue. Sur Cloudflare R2, la documentation va plus loin et impose --region auto explicitement, faute de quoi l’authentification de la requête peut échouer.
Deux options méritent votre attention si vous n’êtes pas chez AWS : --port, pour un point de terminaison sur un port non standard, et surtout --path-style, qui bascule de l’adressage par sous-domaine à l’adressage par chemin. C’est l’option qui débloque MinIO, Ceph RadosGW et la plupart des stockages objet auto-hébergés, et son absence explique une bonne partie des échecs de connexion en homelab.
Puis un datastore qui s’appuie dessus :
# Datastore adossé au bucket S3 déclaré ci-dessus
# Remplacez les valeurs en majuscules par les vôtres
proxmox-backup-manager datastore create NOM_DATASTORE /chemin/vers/le/cache \
--backend type=s3,client=my-s3-ep,bucket=NOM_DU_BUCKET
Dans l’interface 4.2, un élément de menu S3 Endpoints apparaît sous Configuration, à côté de Remotes et Traffic Control.
Avant de vous lancer, lisez les limitations que la documentation énonce noir sur blanc. Elles expliquent la majorité des déconvenues rapportées sur les forums.
| Limitation officielle | Conséquence pratique |
|---|---|
| Proxmox Backup Server ne gère ni la création du bucket ni le contrôle d’accès | Créez le bucket et sa politique d’accès chez votre fournisseur, en amont |
| Un cache local persistant est nécessaire, 64 à 128 Gio recommandés | Prévoyez un dataset dédié avec quota ; ce n’est pas optionnel |
| Si le stockage objet sature pendant une écriture, le nettoyage du snapshot concerné échoue également | Des objets orphelins subsistent dans le bucket : il faut les supprimer manuellement, puis lancer un S3 refresh du datastore |
| Une seule instance Proxmox Backup Server peut opérer sur un datastore à la fois | Pas de partage d’un même bucket entre deux serveurs de sauvegarde |
| Des coûts additionnels sont à prévoir | Stockage, mais aussi requêtes API et bande passante sortante |
Cette dernière ligne mérite un développement, parce qu’elle est la source d’un mauvais calcul fréquent. La déduplication de Proxmox Backup Server travaille par fragments : une sauvegarde incrémentale génère beaucoup de petites requêtes plutôt qu’un gros transfert. Chez un fournisseur qui facture la requête API, la facture ne suit pas le volume stocké mais le nombre d’opérations. Estimez les deux avant de migrer un datastore existant vers S3.
La troisième limitation demande une réaction manuelle, ce qui est inhabituel dans un produit Proxmox. Quand une écriture échoue faute de place, la documentation indique que le nettoyage du contenu du répertoire de snapshot concerné échoue également, et elle donne la procédure de sortie : supprimer manuellement les objets résiduels correspondant à ce snapshot sur le stockage objet, puis rafraîchir le contenu du datastore avec un S3 refresh. Surveillez donc le taux de remplissage du bucket : une saturation ne se répare pas toute seule au passage suivant.
Niveau de preuve
Les limitations ci-dessus sont citées de la documentation officielle Proxmox Backup Server 4.2.5-1. Le comportement réel varie selon le fournisseur S3 : des retours d’expérience publics font état de difficultés avec certaines offres de stockage objet à bas coût. Testez sur un datastore secondaire avant d’y confier vos seules sauvegardes.
Connecter Proxmox Backup Server à Proxmox VE
Le serveur est prêt, il faut maintenant que l’hyperviseur le connaisse.
Récupérer l’empreinte du certificat
Le certificat de Proxmox Backup Server est auto-signé : Proxmox VE refusera la connexion tant qu’il ne connaîtra pas son empreinte. Sur le serveur de sauvegarde :
proxmox-backup-manager cert info | grep Fingerprint
La sortie ressemble à ceci :
Fingerprint (sha256): 64:d3:ff:3a:50:38:53:5a:9b:f7:50:...:ab:fe
Cette empreinte est également accessible dans l’interface, via le bouton Show Fingerprint du tableau de bord.
Déclarer le stockage côté Proxmox VE
Sur l’hôte Proxmox VE, trois commandes suffisent :
# Déclaration du stockage de type pbs
pvesm add pbs store2 --server localhost --datastore store2
# Identifiants de connexion
pvesm set store2 --username user1@pbs --password
# Empreinte du certificat relevée à l'étape précédente
pvesm set store2 --fingerprint 64:d3:ff:3a:50:38:53:5a:9b:f7:50:...:ab:fe
Remplacez localhost par l’adresse réelle du serveur de sauvegarde, et store2 par le nom de votre datastore. Le paramètre --password passé sans valeur déclenche une invite de saisie, ce qui évite d’inscrire le mot de passe dans l’historique du shell.
Vérifiez que le stockage répond :
pvesm status --storage store2
Si la commande retourne une erreur de certificat, l’empreinte est erronée ou incomplète — recopiez-la intégralement, sans espace ni retour à la ligne.
Le port 8007 doit être joignable depuis l’hyperviseur. Sur un serveur exposé, restreignez cet accès avec une règle de pare-feu explicite plutôt que de laisser l’interface ouverte à tout le réseau.
Créer un jeton API dédié plutôt qu’utiliser root
Connecter Proxmox VE avec root@pam fonctionne. C’est aussi la première erreur à corriger, et la raison figure dans la section sur les rançongiciels : un compte disposant du droit de suppression permet à un attaquant qui compromet l’hyperviseur d’effacer les sauvegardes depuis ce même hyperviseur.
La documentation recommande explicitement des jetons API isolés par hôte, avec des permissions minimales portant sur un chemin précis, du type /datastore/tank/pve-abc-cluster. Créez-les dans Configuration → Access Control, puis utilisez le jeton comme identifiant dans la commande pvesm set.
Sauvegarder une VM : le mode compte plus que le bouton
Lancer une sauvegarde depuis Proxmox VE prend trois clics. Choisir le bon mode décide si elle sera restaurable.
Les trois modes de Proxmox VE
Stop offre la cohérence maximale. Proxmox VE procède à un arrêt ordonné de la machine virtuelle, puis lance un processus QEMU en arrière-plan pour la sauvegarde ; la VM redémarre dès que la sauvegarde est amorcée, sans attendre sa fin. L’interruption est courte mais réelle.
Suspend est maintenu pour compatibilité. Il suspend la VM avant d’appeler le mode snapshot, ce qui allonge l’indisponibilité sans garantie d’amélioration de la cohérence. La documentation recommande le mode snapshot à la place.
Snapshot est le mode opérationnel par défaut. Proxmox VE réalise une sauvegarde à chaud : les blocs de données sont copiés pendant que la machine virtuelle continue de tourner. C’est le mode dont le temps d’interruption est le plus faible, au prix d’un risque d’incohérence que la section suivante permet d’écarter.
Le point que les tutoriels omettent : la cohérence applicative
Une sauvegarde en mode snapshot sans précaution est crash-consistent. Autrement dit, elle équivaut à une coupure de courant : le système de fichiers est dans l’état où il se serait trouvé si la prise avait été arrachée à cet instant. Un système de fichiers journalisé s’en remet. Une base de données avec des écritures en vol, beaucoup moins.
La parade existe et elle est intégrée. Si l’agent invité QEMU est activé (agent: 1 dans la configuration de la VM) et effectivement en cours d’exécution dans le système invité, Proxmox VE appelle guest-fsfreeze-freeze puis guest-fsfreeze-thaw autour de la copie. Les systèmes de fichiers de l’invité sont gelés le temps de prendre le point de cohérence, ce qui améliore la cohérence des données pendant la sauvegarde à chaud.
L’agent doit être installé dans la VM, pas seulement coché dans Proxmox VE. Une case activée côté hyperviseur avec un agent absent côté invité ne produit aucun gel — et aucune erreur visible. Vérifiez dans la VM Linux que le service qemu-guest-agent tourne réellement.
Le fleecing, quand la sauvegarde ralentit la machine
Pendant une sauvegarde à chaud, chaque écriture de l’invité sur un bloc pas encore sauvegardé oblige l’hyperviseur à copier l’ancien bloc vers la cible avant d’autoriser l’écriture. Si la cible est lente, c’est la VM qui attend.
Le backup fleecing règle ce problème : au lieu d’être envoyées directement à la cible, les anciennes données sont mises en cache dans une image de fleecing. L’impact sur les entrées-sorties de l’invité diminue, au prix d’espace disque supplémentaire.
# Sauvegarde de la VM 123 avec fleecing sur un stockage local rapide
vzdump 123 --fleecing enabled=1,storage=local-lvm
Le stockage de fleecing doit être local, rapide, et supporter le provisionnement fin et le discard. Ne le placez pas sur la cible de sauvegarde : cela reviendrait à ajouter une écriture là où vous vouliez en retirer.
Sauvegarder un conteneur LXC : un mécanisme différent
Une VM et un conteneur ne se sauvegardent pas de la même façon, et la confusion produit des attentes fausses sur les temps d’arrêt.
Une machine virtuelle passe par un processus QEMU en arrière-plan avec copie avant écriture. Un conteneur n’a pas de processus de ce type : il repose sur rsync et sur les snapshots du stockage sous-jacent.
| Machine virtuelle | Conteneur LXC | |
|---|---|---|
| Mécanisme | Processus QEMU, copie avant écriture | rsync ou snapshot du stockage |
| Mode stop | Arrêt ordonné, redémarrage rapide | Conteneur arrêté toute la durée de la sauvegarde |
| Mode suspend | Suspend puis snapshot, déconseillé | rsync, suspension, second rsync des fichiers modifiés |
| Mode snapshot | Interruption minimale (aucun arrêt, gel bref si agent invité) | Suspension brève, snapshot, archivage tar |
| Prérequis snapshot | — | Tous les volumes doivent supporter le snapshot |
Trois conséquences pratiques.
Le mode stop d’un conteneur immobilise le service pendant toute la sauvegarde, pas seulement au démarrage de celle-ci comme pour une VM. Sur un gros conteneur, l’indisponibilité peut être longue.
Le mode suspend d’un conteneur copie les données vers un emplacement temporaire avec rsync, suspend le conteneur, puis relance un rsync des fichiers modifiés avant de le redémarrer. Le temps d’arrêt est minime, mais l’opération consomme de l’espace disque supplémentaire.
Le mode snapshot d’un conteneur exige que tous les volumes montés supportent les snapshots. Un seul volume sur un stockage qui ne les gère pas, et le mode échoue. C’est la cause la plus fréquente d’une sauvegarde de conteneur qui refuse de démarrer alors que la même configuration fonctionne pour les VM.
La différence se lit jusque dans le contenu des sauvegardes. Un snapshot de conteneur contient un fichier root.pxar.didx — une archive de fichiers — accompagné de pct.conf.blob pour la configuration. Un snapshot de VM contient drive-scsi0.img.fidx, une image de blocs à taille fixe, accompagnée de qemu-server.conf.blob. Le conteneur est sauvegardé fichier par fichier, la VM bloc par bloc.
Restaurer : le seul test qui compte
Une sauvegarde jamais restaurée est une hypothèse, pas une protection. C’est aussi la partie que plusieurs guides francophones sur le sujet passent entièrement sous silence.
Restaurer une machine ou un conteneur complet
Depuis Proxmox VE, sélectionnez le stockage de sauvegarde, choisissez le snapshot et lancez la restauration. Proxmox VE peut recréer la machine sur un identifiant différent, ce qui permet de restaurer sans écraser la machine d’origine — la bonne méthode pour tester une restauration sans risque.
Avertissement
Restaurer sur l’identifiant d’une machine existante écrase ses disques sans possibilité de retour. Pour un test de restauration, choisissez toujours un nouvel identifiant.
Restaurer un seul fichier
C’est l’usage le plus fréquent au quotidien, et l’un des arguments les plus solides en faveur de Proxmox Backup Server. Un fichier de configuration effacé ne justifie pas de restaurer une VM entière.
Le client propose un shell de navigation dans le catalogue d’une sauvegarde :
# Ouvre un shell interactif dans le catalogue du snapshot
proxmox-backup-client catalog shell SNAPSHOT root.pxar
Ce shell accepte des commandes de navigation familières — cd, ls, find — puis restore-selected ou restore --pattern pour extraire ce que vous avez sélectionné.
Pour restaurer une archive complète vers un répertoire :
proxmox-backup-client restore SNAPSHOT root.pxar /chemin/de/destination/
Monter une sauvegarde en lecture seule
Plus souple encore, le montage FUSE expose la sauvegarde comme un système de fichiers en lecture seule :
# Monte l'archive du snapshot sur un point de montage local
proxmox-backup-client mount SNAPSHOT root.pxar /mnt/point-de-montage
Vous parcourez ensuite l’arborescence avec vos outils habituels, vous copiez ce dont vous avez besoin, puis vous démontez avec umount. Aucun espace disque supplémentaire n’est consommé, seuls les fragments réellement lus sont récupérés.
Chiffrer ses sauvegardes
Le chiffrement de Proxmox Backup Server s’effectue côté client, en AES-256 en mode GCM : les données sont chiffrées avant de quitter la machine sauvegardée. Le serveur de sauvegarde ne voit jamais le contenu en clair, ce qui rend le modèle utilisable même sur un stockage que vous ne contrôlez pas entièrement.
La génération d’une clé se fait de deux manières, et la différence n’est pas cosmétique : elle décide si vos sauvegardes seront réellement chiffrées.
Sans argument, la clé créée devient la clé de chiffrement par défaut du client, enregistrée dans ~/.config/proxmox-backup/encryption-key.json. Toutes les sauvegardes suivantes l’utilisent automatiquement :
# La clé devient la clé par défaut du client
proxmox-backup-client key create
Avec un chemin en argument, la clé est écrite dans le fichier indiqué, relativement au répertoire courant, et elle ne devient pas la clé par défaut :
# La clé est écrite dans ./ma-sauvegarde.key et n'est PAS utilisée automatiquement
proxmox-backup-client key create ma-sauvegarde.key
Dans ce second cas, il faut la désigner explicitement à chaque sauvegarde avec l’option --keyfile. L’oublier produit des sauvegardes non chiffrées, sans message d’alerte : vous croyez chiffrer, vous ne chiffrez pas. Vérifiez la colonne Encrypted du contenu du datastore pour lever le doute.
Avertissement : perte de clé, perte de données
La documentation est sans ambiguïté : sans la clé, les fichiers sauvegardés sont inaccessibles. Il n’existe aucune procédure de récupération. Conservez la clé dans un endroit séparé du contenu sauvegardé — gestionnaire de mots de passe, support chiffré hors ligne, ou impression papier via QR code, méthode que la documentation mentionne explicitement.
Sauvegardez le fichier que vous avez réellement créé :~/.config/proxmox-backup/encryption-key.jsonsi vous avez lancé la commande sans argument, le fichier que vous avez nommé sinon. Copier le mauvais chemin revient à n’avoir aucune sauvegarde de clé.
Un mécanisme de clé maîtresse existe pour les environnements qui ne peuvent pas tolérer ce risque : la clé symétrique est alors chiffrée avec une paire de clés RSA, ce qui autorise une récupération d’urgence.
Depuis la version 4.2, les tâches de synchronisation peuvent également chiffrer les données avant de les transmettre à un serveur distant, avec gestion centralisée des clés. La boîte de dialogue de création d’une tâche comporte un onglet Encryption avec deux champs, dont les rôles sont souvent confondus alors qu’ils s’appliquent à des sens de synchronisation opposés.
La clé active ne concerne que les tâches en direction push. Elle chiffre les snapshots sources non chiffrés, laisse tel quel le contenu déjà chiffré, et ignore purement et simplement le contenu partiellement chiffré, par précaution. La documentation est explicite : sur une tâche en direction pull, cette clé est sans effet et ne doit pas être renseignée.
Les clés associées jouent le rôle inverse : elles servent à déchiffrer le contenu des snapshots en direction pull, lorsque l’empreinte de l’une d’elles correspond à celle utilisée pour chiffrer la sauvegarde. Lors d’une rotation, l’ancienne clé active bascule automatiquement dans cette liste, ce qui préserve l’accès aux contenus anciens.
Maintenance : prune, garbage collection, verify
Trois opérations distinctes, souvent confondues, et dont l’ordre compte.
| Opération | Ce qu’elle fait | Ce qu’elle ne fait pas |
|---|---|---|
| Prune | Supprime les snapshots selon la politique de rétention | Ne libère aucun espace disque |
| Garbage collection | Supprime les fragments qui ne sont plus référencés par aucun snapshot | Ne décide pas quels snapshots garder |
| Verify | Recalcule les sommes de contrôle et les compare à celles enregistrées | Ne répare rien |
La distinction entre les deux premières est la source d’incompréhension la plus courante : après un prune, l’espace occupé ne bouge pas. C’est normal. Le prune retire des références ; seul le garbage collection supprime les fragments devenus orphelins. Tant qu’il n’est pas passé, l’espace reste occupé.
Un garbage collection lancé dans la foulée d’un prune ne libère pas non plus tout l’espace attendu, et c’est également normal. La documentation définit un seuil de sécurité : le point de coupure correspond à la plus ancienne instance d’écriture de sauvegarde en cours, ou, à défaut, à 24 heures et 5 minutes avant le démarrage du garbage collection. Les fragments touchés plus récemment sont conservés et ne disparaîtront qu’au passage suivant. Ce délai vient du comportement de l’option de montage relatime, qui n’actualise la date d’accès d’un fichier qu’une fois par vingt-quatre heures.
La vérification a une seconde fonction, moins évidente, qui la place au cœur de la section suivante : en comparant les données à leurs sommes de contrôle, elle détecte toute modification non autorisée du contenu du datastore.
Planifiez les trois depuis les onglets Prune & GC Jobs et Verify Jobs du datastore. Une planification hebdomadaire du garbage collection et de la vérification convient à la plupart des installations ; sur un gros datastore en disques mécaniques, décalez-les pour qu’ils ne se chevauchent pas.
Protéger ses sauvegardes contre un rançongiciel
C’est le point qui distingue une sauvegarde d’une illusion de sauvegarde. Un rançongiciel moderne cherche les sauvegardes en priorité, et il les trouve d’autant plus facilement que l’hyperviseur compromis dispose des droits pour les effacer.
Proxmox Backup Server oppose plusieurs couches, documentées dans le chapitre consacré au stockage.
L’immuabilité de fait. Proxmox Backup Server ne réécrit pas les données des blocs existants. Un système compromis ne peut donc pas altérer le contenu des sauvegardes antérieures : il pourrait en créer de nouvelles, pas corrompre les anciennes.
Le modèle de permissions. Le privilège Datastore.Backup autorise la création de sauvegardes, pas leur suppression. C’est la clé de voûte : donnez ce privilège à vos hyperviseurs, et rien de plus. La documentation recommande des jetons API isolés par hôte, avec des permissions restreintes à un chemin précis.
Le prune côté serveur. Puisque les clients n’ont pas le droit de supprimer, la rétention doit être appliquée par le serveur de sauvegarde lui-même, via des tâches de prune planifiées. Un attaquant qui contrôle l’hyperviseur ne dispose alors d’aucun mécanisme pour effacer l’historique.
La détection par vérification. Les tâches de vérification contrôlent régulièrement la correspondance entre les sauvegardes et leurs sommes de contrôle enregistrées, ce qui révèle toute modification non autorisée.
La règle 3-2-1. Trois copies, sur deux types de supports différents, dont une hors site. Proxmox Backup Server la rend praticable par les tâches de synchronisation vers un serveur distant et par la sauvegarde sur bande.
Si votre serveur de sauvegarde n’est joignable que depuis votre réseau local, un réseau maillé chiffré évite de publier son interface sur Internet pour y accéder à distance.
Erreurs fréquentes
Le datastore refuse d’être créé. Le système de fichiers ne supporte probablement pas 65 538 sous-répertoires. Vérifiez avec findmnt -no FSTYPE --target.
Proxmox VE refuse la connexion au serveur de sauvegarde. L’empreinte du certificat est absente, tronquée ou périmée. Relevez-la à nouveau avec proxmox-backup-manager cert info | grep Fingerprint et réappliquez-la.
Le mode snapshot échoue sur un conteneur. Un des volumes ne supporte pas les snapshots. Repliez-vous sur le mode suspend, ou déplacez le volume vers un stockage compatible.
L’espace disque ne diminue pas après un prune. Comportement normal. Lancez un garbage collection — et si l’espace ne se libère toujours pas entièrement, souvenez-vous du seuil de 24 heures et 5 minutes : les fragments récents attendront le passage suivant.
Une sauvegarde vers S3 a échoué et le snapshot reste incomplet. Le bucket est probablement saturé. Supprimez manuellement les objets résiduels de ce snapshot chez votre fournisseur, puis resynchronisez le contenu du datastore. L’opération s’appelle S3 refresh dans l’interface, et s3-refresh en ligne de commande :
proxmox-backup-manager datastore s3-refresh NOM_DATASTORE
La connexion au stockage objet échoue alors que les identifiants sont bons. Si votre fournisseur n’est pas AWS — MinIO, Ceph RadosGW, stockage objet auto-hébergé — ajoutez --path-style à la déclaration du point de terminaison. L’adressage par sous-domaine utilisé par défaut n’est pas supporté partout.
Le serveur consomme toute sa RAM. Vérifiez le dimensionnement : 4 Gio plus au moins 1 Gio par Tio de datastore (règle PBS), et si le stockage repose sur un pool ZFS, croisez-la avec la formule du guide d’installation PVE — 4 Go plus 1 Go par To d’espace disque brut du pool — sans jamais descendre sous 8 Go. La mise en cache ARC consomme ensuite toute la mémoire disponible au-delà de ce plancher, ce qui est normal et voulu.
Questions fréquentes
Combien de RAM faut-il prévoir ?
Quatre gibioctets pour le système, plus au moins un gibioctet par tébioctet d’espace de stockage (Tio) : un datastore de 8 Tio demande donc 12 Gio de RAM au minimum. Sur un pool ZFS, croisez ce résultat avec la formule du guide d’installation Proxmox VE — 4 Go plus 1 Go par To brut du pool — et retenez le plus élevé des deux, sans jamais descendre sous les 8 Go que la documentation PBS fixe comme plancher absolu pour que ZFS reste stable.
Proxmox Backup Server sauvegarde-t-il autre chose que des VM et des conteneurs ?
Oui. Le client proxmox-backup-client sauvegarde des hôtes physiques et des répertoires de fichiers sur des systèmes Linux qui ne sont pas gérés par Proxmox VE, avec la même déduplication et le même chiffrement.
Peut-on utiliser Proxmox Backup Server gratuitement en production ?
Techniquement oui, rien ne l’empêche. Mais la documentation ne le recommande pas : le dépôt sans abonnement est présenté comme destiné aux tests et aux usages hors production, ses paquets n’étant pas aussi systématiquement validés que ceux du dépôt entreprise.
Peut-on sauvegarder vers un NAS plutôt que vers un disque local ?
Oui, à condition que le système de fichiers exposé supporte les 65 538 sous-répertoires requis et offre des performances suffisantes en accès aléatoire. Un partage réseau lent transforme le garbage collection en opération de plusieurs heures.
Que se passe-t-il si je perds la clé de chiffrement ?
Les sauvegardes chiffrées avec cette clé deviennent définitivement inaccessibles. Il n’existe aucune procédure de récupération, sauf si vous aviez configuré une clé maîtresse RSA au préalable.
Ce qui a été vérifié, et comment
Cet article repose sur la documentation officielle Proxmox Backup Server 4.2.5-1 et sur la documentation Proxmox VE, consultées le 27 puis le 29 août 2026. Les commandes, les chiffres de dimensionnement et les limitations du backend S3 sont cités de ces sources, avec leurs liens ci-dessous.
Les procédures décrites n’ont pas été exécutées sur une installation de test. Elles sont conformes à la documentation officielle, ce qui n’est pas la même chose qu’un retour d’expérience terrain. Les commandes ont été relevées mot pour mot dans les pages d’installation, de stockage, de client de sauvegarde et d’intégration Proxmox VE.
Trois relectures indépendantes ont porté sur cet article avant publication, la troisième portant spécifiquement sur les corrections issues de la seconde : c’est cette dernière passe qui a permis de repérer qu’une correction antérieure — la suppression de la formule de RAM pour ZFS, jugée à tort inexistante après consultation d’une seule page — était elle-même erronée. La formule existe bien, dans une page différente de celle initialement consultée (guide d’installation Proxmox VE, section « ZFS Performance Tips »), et a été réintégrée après vérification directe de la source.
Les captures d’écran publiées dans la documentation officielle n’ont volontairement pas été reprises. Celle du tableau de bord affiche « Backup Server 0.8-15 BETA » et celle de la gestion des disques « Backup Server 2.2-8 », soit des interfaces de 2020 et 2022, antérieures de plusieurs versions majeures à celle décrite ici. Les reprendre aurait montré au lecteur un écran qu’il ne verra jamais. Les libellés d’interface cités plus haut — l’entrée S3 Endpoints sous Configuration, le bouton Show Fingerprint du tableau de bord, les onglets d’un datastore — ont été relevés sur les captures de la version 4.2.0 publiées par Proxmox sur sa page produit.
Sources officielles consultées les 27 et 29 août 2026 : documentation Proxmox Backup Server, sauvegarde et restauration dans Proxmox VE, guide d’installation Proxmox VE (ZFS Performance Tips), annonce de la version 4.2.
Conclusion
Installez Proxmox Backup Server dès que votre infrastructure dépasse un hôte et deux machines : la déduplication rentabilise le serveur supplémentaire en quelques semaines, et la restauration de fichier individuel change le quotidien. Dimensionnez la RAM sur la règle officielle plutôt qu’à l’estime, vérifiez le système de fichiers du datastore avant de le créer, et activez l’agent invité QEMU dans vos VM — sans lui, vos sauvegardes à chaud restent équivalentes à une coupure de courant.
Sur la protection contre les rançongiciels, retenez une seule décision structurante : ne donnez jamais à vos hyperviseurs le droit de supprimer des sauvegardes. Un jeton API par hôte, limité au privilège Datastore.Backup, et la rétention appliquée par le serveur. C’est ce qui sépare une sauvegarde d’une copie qu’un attaquant effacera en même temps que le reste.
Enfin, restaurez pour de vrai, sur un identifiant de machine différent, avant d’en avoir besoin. Si vous démarrez sur Proxmox, le guide d’installation de Proxmox VE couvre l’étape précédente ; pour la sauvegarde de fichiers sur un serveur Linux non virtualisé, rsync et crontab restent la réponse adaptée.
