Sauvegarde Proxmox : le guide complet 2026 (PVE + PBS)

L’adoption de Proxmox a explosé depuis l’acquisition de VMware par Broadcom. Les équipes qui migrent y trouvent un hyperviseur open source mature, mais elles héritent aussi d’un sujet que beaucoup repoussent à plus tard : la stratégie de sauvegarde. Ce guide pose la base complète pour 2026, de vzdump au Proxmox Backup Server (PBS), en passant par la règle 3-2-1-1-0 et les tests de restauration. Il s’adresse aux administrateurs qui exploitent déjà Proxmox VE en production, aux MSP qui gèrent des parcs clients, et aux DSI qui arbitrent entre solutions payantes héritées de VMware et l’écosystème Proxmox natif.

On y traite la théorie, mais surtout les choix concrets : quel outil pour quel besoin, comment dimensionner, comment tester, et comment automatiser. Tous les chiffres et pratiques reflètent PVE 8.x et PBS 3.x, les versions de référence en 2026.

Pourquoi sauvegarder un hyperviseur Proxmox

Un hyperviseur concentre la production. Perdre un nœud Proxmox sans sauvegarde, c’est perdre potentiellement des dizaines de VM et containers d’un seul coup. Les causes sont toujours les mêmes : panne matérielle (disques, contrôleur RAID, alimentation), erreur humaine (suppression d’une VM, mauvaise commande qm destroy), corruption logicielle (filesystem, fs ZFS en échec), et ces dernières années, ransomware. Sur ce dernier point, les groupes APT professionnels chiffrent les hôtes de virtualisation en priorité parce qu’ils savent que c’est là que se concentre la valeur.

Les coûts quantifiables d’une perte sont connus. RTO (Recovery Time Objective) : combien de temps votre activité peut tenir sans ses VM. RPO (Recovery Point Objective) : combien de données récentes vous pouvez accepter de perdre. Sur un parc Proxmox typique, les valeurs cibles tournent autour de RTO 4 à 24 heures selon la criticité, et RPO 6 à 24 heures pour la production standard, 15 minutes à 1 heure pour les bases de données critiques. Ces valeurs déterminent votre fréquence de sauvegarde et votre topologie de restauration.

Le cadre réglementaire pousse aussi à formaliser la stratégie. NIS2 impose depuis 2024 aux opérateurs essentiels et importants de démontrer une capacité de reprise. DORA fait de même pour le secteur financier. Le RGPD exige depuis 2018 des mesures techniques adéquates pour protéger les données, et plusieurs recommandations sectorielles (HDS pour la santé, PCI DSS pour les paiements) spécifient explicitement des exigences de backup immutable. L’argument “on a du RAID donc on est protégé” ne tient plus devant un auditeur.

Le seuil d’entrée réaliste en 2026 est ce que nous appelons le 5-2-1 minimum : cinq jours de rétention, deux copies physiquement distinctes, un site externe. C’est le plancher. Une stratégie sérieuse monte vite au 3-2-1-1-0 qu’on détaille plus loin.

vzdump vs Proxmox Backup Server

Proxmox offre deux outils natifs pour sauvegarder. Comprendre leurs différences est la première décision stratégique.

vzdump est l’outil historique, intégré depuis les débuts de Proxmox VE. Il produit des archives complètes (format vma.zst, vma.gz ou tar) pour chaque VM ou container, qu’il dépose sur un stockage local ou distant (NFS, CIFS, répertoire). Chaque run = un fichier archive complet. Pas de déduplication entre runs, pas de compression fine, pas d’incrémental natif. Avec PVE 8, vzdump gère cependant un mode snapshot qui fige un instantané LVM ou ZFS pendant le dump, limitant l’impact sur la VM live.

Proxmox Backup Server (PBS) est une application séparée, installée sur un serveur dédié ou une VM. Son architecture est fondamentalement différente : chaque fichier de VM est découpé en chunks de 1 à 4 MiB par un algorithme de content-defined chunking. Les chunks sont indexés par leur hash SHA-256 et stockés une seule fois, où qu’ils apparaissent. Le protocole d’échange entre PVE et PBS est un HTTP/2 binaire qui ne transporte que les chunks absents du datastore cible. Résultat : à partir du deuxième backup, seuls les chunks réellement modifiés traversent le réseau, typiquement 2 à 5 % d’une VM active par jour.

Concrètement, cela change trois choses :

• Volume stocké : sur un parc de 20 VM Windows/Linux mixtes, PBS atteint des ratios logique/physique de 6 à 12 après quelques semaines. 10 To de backups logiques peuvent tenir sur 1 à 2 To physiques.
• Temps de sauvegarde quotidien : une VM de 500 GB qui prend 40 minutes en vzdump prend 2 à 4 minutes en PBS incrémental, CBT (Change Block Tracking) activé.
• Restauration granulaire : PBS monte un datastore comme filesystem FUSE, vous pouvez extraire un seul fichier sans restaurer toute la VM. vzdump impose un restore complet.

Le choix raisonnable en 2026 : PBS pour la production, vzdump seulement pour les cas marginaux (export ponctuel, migration vers un autre hyperviseur, sauvegarde one-shot avant une opération risquée). Si votre parc dépasse 5 VM, PBS amortit son coût opérationnel en quelques semaines.

Installer et configurer PBS

Trois options de déploiement : hôte physique dédié, VM sur un cluster Proxmox, ou service infogéré comme Cloud-PBS. Nous couvrons ici le self-hosted physique, qui reste la base pour comprendre ce qui tourne sous un service managé.

Prérequis matériel réalistes : 8 cœurs x86_64 modernes, 16 à 32 GB de RAM ECC, et un pool de disques qui respecte la règle “3x la volumétrie logique prévue”. Le filesystem recommandé est ZFS avec une topologie RAIDZ2 pour les gros pools (au-delà de 24 TB utiles) ou miroirs pour les pools plus petits où la performance prime. Un special vdev NVMe en miroir accélère drastiquement les opérations de métadonnées (garbage collection, verify), comptez environ 0,3 % de la taille du pool en NVMe mirror.

L’installation passe par l’ISO officielle disponible sur proxmox.com. Le système installé est un Debian minimal avec les paquets PBS préconfigurés. L’interface web répond sur le port 8007 en TLS. Le premier accès propose de créer un datastore : c’est le répertoire ZFS ou ext4 qui stockera vos chunks. Pour la production, on configure toujours un pool ZFS séparé du système, avec compression LZ4 ou zstd-3.

Une fois PBS en place, trois étapes côté Proxmox VE :

1. Ajouter le datastore distant dans Datacenter > Storage > Add > Proxmox Backup Server. Renseignez l’adresse PBS, le nom du datastore, et le user (backup@pbs ou un user API dédié).
2. Copier l’empreinte TLS depuis le dashboard PBS (onglet Dashboard, champ Fingerprint) et la coller dans la configuration storage PVE. Sans empreinte valide, la connexion échoue.
3. Activer le chiffrement côté client si vos données l’exigent. PBS génère une clé AES-256-GCM que vous téléchargez et sauvegardez séparément. Les données sont chiffrées sur l’hôte PVE avant transfert, PBS ne voit jamais la clé. La perte de cette clé rend vos backups irrécupérables, prévoyez un HSM ou un gestionnaire de secrets pour la stocker hors de votre infrastructure Proxmox.

À ce stade, PBS est prêt à recevoir ses premiers jobs. Un schedule par défaut de type daily fonctionne pour commencer. Les optimisations fines (fenêtres de backup, groupes de VM, bandwidth throttling) s’affinent au fur et à mesure.

Planifier ses jobs de backup

Un job PBS a cinq paramètres qui structurent toute votre stratégie : quoi sauvegarder, quand, avec quelle rétention, dans quelle fenêtre, et avec quelle priorité réseau.

Quoi : des VMs et containers, individuellement ou par groupe (pool Proxmox, tag, pattern). Pour un parc homogène, les tags sont l’outil le plus souple : vous marquez vos VMs backup-daily, backup-weekly, critical, et vous déclarez des jobs qui ciblent ces tags. Changer la stratégie d’une VM = changer son tag.

Quand : les schedules PBS suivent la syntaxe systemd (daily, weekly, mon..fri 22:00, *-*-* 03:00). La cadence dépend du RPO cible. Pour de la production standard, un backup quotidien à 22h ou 2h du matin convient. Pour des bases de données, 6 à 8 fois par jour n’est pas excessif, PBS les ingère sans pic de charge grâce à l’incrémental.

Rétention : cinq règles qui se combinent. keep-last N (toujours garder les N plus récents), keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. Un profil production classique : keep-daily 14, keep-weekly 4, keep-monthly 12, keep-yearly 3. Cela stocke 33 snapshots uniques par VM, soit environ 4 à 6 fois le volume logique d’une VM active, pour une rétention effective de 3 ans. Notre simulateur de rétention calcule cette combinatoire visuellement.

Fenêtre : PBS sait limiter la bande passante par job (bwlimit) et respecte les fenêtres de maintenance. Sur un site avec liaison internet partagée, on cappe les backups hors heures ouvrées à 50 % de l’uplink. Sur un site avec lien dédié PVE-PBS, pas de throttling. Les snapshots PVE étant pris instantanément, la durée du job ne bloque pas les VM, seule la charge I/O en dépend.

Priorité : un verify job devrait tourner chaque semaine sur tous les datastores. Un garbage collection quotidien ou hebdomadaire selon votre taux d’écriture. Un prune job aligné sur chaque job de backup. Ces trois tâches de maintenance sont aussi critiques que les backups eux-mêmes ; un PBS non verifié ne vaut pas plus que l’espoir que le hash corresponde encore aux données.

Pour dimensionner précisément votre stockage en fonction du volume et de la rétention, le calculateur de stockage PBS traite les inputs en temps réel.

Stratégie 3-2-1-1-0 appliquée à Proxmox

La règle 3-2-1 historique disait : trois copies de vos données, sur deux supports différents, dont une hors site. C’était suffisant avant le ransomware moderne, ça ne l’est plus. La version 3-2-1-1-0 ajoute deux exigences essentielles :

• Trois copies : la production + deux sauvegardes indépendantes.
• Deux supports : pas toutes les copies sur le même type de stockage.
• Un site externe : au moins une copie géographiquement séparée.
• Un immutable : au moins une copie que personne, même un attaquant avec les droits admin, ne peut altérer.
• Zéro erreur : chaque sauvegarde doit être vérifiée, pas juste écrite.

L’implémentation concrète sur Proxmox tient en trois couches.

Couche 1, PBS on-premise ou datacenter local. C’est la cible primaire des jobs de backup quotidiens. Restauration rapide grâce au lien LAN 10 Gbps. Un hôte PBS séparé physiquement des hôtes PVE, sur un VLAN d’administration différent, avec des credentials qui ne sont PAS ceux des admins PVE.

Couche 2, sync PBS vers un second PBS distant. Native dans PBS, la synchronisation push/pull réplique les chunks vers un second datastore. Ce second PBS est idéalement chez un opérateur différent : autre datacenter, autre opérateur réseau, autre juridiction. Le service Cloud-PBS est conçu pour ce rôle précis, avec sites en France, en Allemagne et aux États-Unis.

Couche 3, immutabilité. Deux options natives en 2026. D’abord, les protected snapshots de PBS 3.x permettent de marquer un backup comme non supprimable jusqu’à une date donnée. Un pveum admin peut lever la protection, mais pas un user API standard. Ensuite, pour une vraie immutabilité physique, une copie hors ligne sur bande LTO ou sur un datastore explicitement offline reprise uniquement pendant les fenêtres de synchronisation. La bande LTO rejoue son rôle historique ici : un ransomware ne peut pas écraser un média qui n’est pas monté.

La dimension “zéro erreur” est trop souvent négligée. Un verify job hebdomadaire qui relit tous les chunks et compare leur hash au manifest détecte les corruptions silencieuses avant qu’elles ne bloquent une restauration. Un vrai test restaurer-mesurer-restaurer trimestriel sur une VM aléatoire ancre la confiance dans le système.

Pour creuser le positionnement infogéré sur cette stratégie, la comparaison Cloud-PBS vs auto-hébergé détaille les arbitrages concrets sur chaque couche.

Restauration : méthodes et tests

Une sauvegarde non testée n’est pas une sauvegarde. Cette phrase est trop récente dans le discours marketing pour encore être un cliché inoffensif : la quasi-totalité des équipes qu’on audite n’ont jamais fait un test de restauration formalisé.

PBS supporte quatre méthodes de restauration, classées du plus granulaire au plus massif.

File-level restore. Vous montez un backup comme filesystem FUSE depuis l’interface PVE, vous naviguez dans l’arborescence, vous copiez ce que vous voulez. Idéal pour récupérer un fichier spécifique sans rebooter la VM. Sous le capot, PBS sert uniquement les chunks demandés, pas toute l’archive.

Disque individuel. Vous restaurez un seul disque virtuel d’une VM multi-disque. Utile quand seul le disque de données est corrompu et que l’OS est sain.

VM complète. Restauration classique d’une VM entière vers un stockage PVE cible. Durée proportionnelle à la taille : comptez 5 à 15 minutes par 100 GB sur un lien 10 Gbps PBS-PVE, davantage sur du 1 Gbps.

Live restore. PBS 2.4+ permet de démarrer une VM pendant que sa restauration est en cours. Les lectures pointent vers PBS tant que les blocs ne sont pas localement présents, les écritures vont sur le stockage cible. RTO effectif réduit à quelques minutes pour une VM de 500 GB, au prix d’une dégradation temporaire des performances I/O.

Les tests doivent suivre un plan systématique. Nous recommandons une cadence trimestrielle avec trois scénarios :

1. File-level : restaurer un fichier spécifique, mesurer le temps de la requête à la disponibilité du fichier. Cible : sous 2 minutes pour un fichier de moins de 100 MB.
2. VM standard : restaurer une VM de production aléatoire vers un nœud de test, vérifier le boot, tester un service métier. Cible : RTO conforme au RTO déclaré.
3. Scénario désastre : simuler la perte d’un nœud PVE complet, restaurer 5 VM critiques depuis PBS sur un nouveau nœud. Cible : RTO global sous 4 heures.

Le scénario 3 est celui qui révèle les failles : credentials manquants, documentation absente, dépendances réseau oubliées. Il se joue en runbook, pas en improvisation. Pour les équipes qui n’ont pas le temps de le formaliser elles-mêmes, le service Managed Restore de Cloud-PBS fournit à la fois le runbook et l’assistance d’astreinte.

Automatiser avec l’API REST

PBS et PVE exposent tous deux une API REST documentée. En 2026, automatiser vos opérations de backup n’est plus une option exotique, c’est la norme professionnelle.

Authentification. Créez un user dédié (automation@pbs) avec un API token. Le token apparaît une seule fois lors de sa génération, notez-le dans votre gestionnaire de secrets. Les permissions granulaires permettent de n’autoriser que la création de backup et la lecture de status, pas la suppression. Révoquez tokens obsolètes à chaque rotation d’équipe.

Endpoints clés. GET /api2/json/admin/datastore/{store}/status pour la volumétrie, GET /api2/json/admin/datastore/{store}/groups pour lister les backup groups, POST /api2/json/admin/datastore/{store}/prune pour déclencher une purge manuelle. Côté PVE, POST /api2/json/nodes/{node}/vzdump lance un backup à la demande.

Outils d’orchestration. Ansible avec la collection community.general inclut un module proxmox_kvm mais pas encore de module PBS natif en 2026 ; on passe par ansible.builtin.uri pour les appels PBS. Terraform avec le provider bpg/proxmox gère la partie PVE, pas la partie PBS directement. Pour des workflows avancés, un wrapper Python autour du client proxmoxer reste la voie la plus flexible.

Monitoring. Les métriques PBS sont exposées en Prometheus natif sur /api2/json/admin/metrics. Un dashboard Grafana standard track la volumétrie par datastore, le ratio de dédup, le taux d’échec des jobs et la durée du dernier verify. Une alerte simple : si aucun backup n’a réussi sur un groupe depuis 36 heures, page l’astreinte.

Pour un template de dashboard Grafana et les scripts d’automatisation, la section docs/advanced du site en liste plusieurs versions maintenues.

FAQ

La déduplication de PBS est-elle aussi efficace que Veeam ? Sur une charge Proxmox homogène, oui et souvent plus. Veeam excelle sur VMware/Hyper-V où il utilise du CBT vendor-spécifique. PBS utilise le CBT natif de PVE via QEMU, combiné à son content-defined chunking, avec des ratios typiques de 6 à 12 sur des parcs mixtes. Les chiffres Veeam annoncés à 25:1 ou plus se réfèrent à des datasets très spécifiques (VMs desktop, templates identiques). Sur de la production standard, les deux solutions produisent des ratios du même ordre de grandeur.

Puis-je sauvegarder des VMs chiffrées LUKS sur PBS ? Oui. PBS travaille au niveau bloc, il ne lit pas le contenu chiffré de vos VMs. Le chiffrement LUKS de la VM et le chiffrement côté client de PBS sont complémentaires et indépendants. Les deux combinés vous donnent un at-rest chiffré en production ET dans la sauvegarde.

Faut-il un PBS par site ou un PBS central ? Dépend de la topologie. En dessous de 3 sites et 100 VM, un PBS central suffit si le lien réseau entre sites supporte les backups incrémentaux. Au-delà, on déploie un PBS par site (collecte locale LAN) + un PBS central qui sync via PBS remote replication. La bande passante nécessaire est typiquement 2 à 5 % du volume quotidien une fois le seed initial passé.

Comment passer de vzdump à PBS sans perdre l’historique ? Gardez votre stockage vzdump existant en read-only pendant 3 à 6 mois après la bascule PBS, le temps de valider les restaurations depuis le nouveau système. L’historique vzdump n’est pas convertible en format PBS, mais il reste restaurable via l’interface PVE tant que le stockage source est monté. Passé la période de validation, archivez les .vma.zst les plus anciens et supprimez.

PBS peut-il sauvegarder autre chose que du Proxmox ? PBS expose aussi un client proxmox-backup-client pour sauvegarder des hôtes Linux arbitraires (fichiers, répertoires entiers). Le fonctionnement est similaire : chunking, déduplication, chiffrement côté client. Cela ne remplace pas un vrai outil de sauvegarde file-level comme restic ou BorgBackup pour des usages très fins, mais ça suffit pour consolider sauvegardes VM et sauvegardes serveurs physiques dans un seul datastore.

La mise à niveau de PBS est-elle disruptive ? Non. PBS utilise le modèle de release Debian, les mises à jour de patch sont non disruptives (reload des services sans interruption des jobs en cours). Les mises à jour majeures (2.x vers 3.x, 3.x vers 4.x) demandent 15 à 30 minutes de fenêtre de maintenance, généralement effectuées hors heures de backup. Le service Cloud-PBS prend en charge ces mises à jour côté infogéré.

Passer à l’action

Si vous démarrez une stratégie de sauvegarde Proxmox, l’ordre logique est : installer PBS (ou souscrire à une instance infogérée), configurer un premier job de backup, vérifier que les restaurations fonctionnent, puis affiner la rétention et ajouter la couche off-site.

Cloud-PBS est conçu pour cette seconde partie : vous recevez une instance PBS infogérée en France, Allemagne ou aux États-Unis, vous la pointez comme remote datastore dans votre Proxmox VE, et vos jobs de sync poussent vos backups hors site. Le partenariat officiel Proxmox Authorized Reseller garantit l’alignement avec l’upstream, et le support est assuré par des ingénieurs qui opèrent des instances PBS de production depuis 12 ans.

L’essai gratuit de 7 jours permet de tester sur votre propre charge avant tout engagement. Pour chiffrer le coût sur votre parc, le calculateur TCO vs auto-hébergé compare les deux approches sur trois ans.