Proxmox Backup Server (PBS) est la plateforme de sauvegarde conçue pour Proxmox VE. Elle centralise les sauvegardes de machines virtuelles et de conteneurs, réduit les transferts suivants grâce à l'incrémental et déduplique les blocs identiques. Pour que PBS apporte une vraie capacité de reprise, il faut toutefois le séparer du cluster, choisir une rétention explicite, vérifier l'intégrité des données, conserver une copie indépendante et tester la restauration.
Ce guide s'appuie sur la documentation PBS 4.2.6-1, consultée le 18 septembre 2026. Il couvre les décisions qui influencent directement le RPO, le RTO et le risque de perdre production et sauvegardes dans le même incident.
À retenir
- Un Proxmox Backup Server de production doit rester accessible si un hyperviseur tombe.
- La documentation recommande au moins 4 cœurs, 4 GiB de RAM + 1 GiB par TiB de stockage et 32 GiB pour le système ; côté Tomco, AMD Ryzen 9 est prioritaire pour un PBS dédié quand le dimensionnement le permet.
- La rétention sélectionne les snapshots à conserver ; le garbage collection libère ensuite les chunks non référencés.
- Les Verify Jobs détectent les erreurs d'intégrité, mais seul un test de restauration valide réellement la reprise.
- Une seconde instance PBS distante et des identités séparées réduisent le domaine de panne.
Sommaire
- Ce que change PBS
- Architecture recommandée
- Dimensionnement
- Installation et connexion
- Rétention et intégrité
- Copie hors site
- Restauration et RPO/RTO
- Checklist de mise en production
En un coup d'œil — les décisions qui structurent un PBS de production
| Décision | Choix recommandé | Risque évité |
|---|---|---|
| Emplacement | Serveur séparé des hyperviseurs | Perdre le dépôt avec le cluster |
| Stockage | Local, redondant, bonnes IOPS | Vérification et restauration trop lentes |
| Rétention | Politique multi-horizons testée | Historique insuffisant ou datastore saturé |
| Intégrité | Verify Jobs + supervision | Découvrir une corruption pendant l'incident |
| Seconde copie | Sync vers un PBS distant | Sinistre du site principal |
| Validation | Restauration périodique isolée | Confondre backup réussi et reprise possible |
Ce que change Proxmox Backup Server
Un Proxmox Backup Server est un dépôt spécialisé, pas un simple partage de fichiers. Proxmox VE s'y connecte comme à un stockage PBS et envoie les sauvegardes de VM et conteneurs. Après la première copie, les sauvegardes suivantes sont incrémentales : le client ne retransfère que les données nécessaires, tandis que PBS découpe et déduplique les chunks déjà présents.
Cette architecture réduit les transferts et peut limiter la croissance du datastore lorsque plusieurs snapshots partagent des blocs identiques. Elle ne permet pas de prédire un ratio universel : une base chiffrée très changeante, une flotte de VM clonées depuis le même template et un serveur de fichiers ont des profils de déduplication différents. La capacité doit donc partir du volume réellement utilisé, du taux de changement et de la profondeur de rétention.
PBS apporte surtout trois fonctions d'exploitation : Verify Jobs pour contrôler l'intégrité, politiques de prune pour choisir les snapshots conservés et Sync Jobs pour créer une copie sur une autre instance. Le guide du cluster Proxmox traite le quorum et la continuité de service ; la sauvegarde répond à une autre question : à quel état fiable revenir lorsque le redémarrage sur un autre nœud ne suffit plus ?
Où installer PBS
Le point le plus important est la séparation du domaine de panne. Un Proxmox Backup Server hébergé sur le même hôte et le même stockage que les VM protégées reste dépendant de l'infrastructure qu'il est censé sauver. Pour la production, le choix le plus robuste est un serveur séparé, relié au cluster par un réseau de sauvegarde, puis synchronisé vers une seconde cible.
L'architecture minimale devient : Proxmox VE → PBS local → PBS distant. Une panne d'hyperviseur ne doit pas couper l'interface de restauration. Une erreur sur le stockage du cluster ne doit pas effacer le datastore PBS. Et un incident de site ne doit pas rendre la seconde copie inaccessible.
Séparer aussi les identités et les clés
La séparation n'est pas uniquement matérielle. Utilisez des comptes ou jetons dédiés aux sauvegardes et aux synchronisations, avec les permissions minimales. La documentation des Sync Jobs recommande notamment une configuration distante dédiée à chaque synchronisation en push et un utilisateur distant limité lorsque des opérations de suppression sont possibles.
Si vous activez le chiffrement côté client, conservez la clé en dehors du cluster et du PBS principal. Une sauvegarde chiffrée sans sa clé reste intacte mais inutilisable. Le principe 3-2-1 reste donc pertinent : la stratégie de sauvegarde 3-2-1 s'applique aussi à l'infrastructure, à condition que les copies ne partagent pas les mêmes dépendances.
Proxmox Backup Server requirements et dimensionnement
Les prérequis officiels de PBS distinguent l'évaluation de la production. Au 18 septembre 2026, la documentation 4.2.6-1 recommande pour la production un CPU AMD ou Intel 64 bits moderne avec au moins 4 cœurs, 4 GiB de RAM pour le système, le cache et les services PBS, puis au moins 1 GiB supplémentaire par TiB de stockage.
Elle recommande aussi 32 GiB ou plus pour le système, du stockage local délivrant de bonnes IOPS et des SSD d'entreprise pour les meilleures performances. Pour un PBS dédié chez Tomco, la priorité va à AMD Ryzen 9 lorsque la capacité mémoire et le nombre de lignes PCIe restent dans le périmètre de la plateforme ; AMD EPYC reste le choix à envisager lorsque le besoin porte d'abord sur davantage de cœurs, de RAM ou d'extension PCIe. Avec des HDD, un cache de métadonnées rapide tel qu'un special device ZFS en miroir est recommandé. Les interfaces réseau multi-gigabit redondantes deviennent utiles dès que plusieurs sauvegardes, vérifications et restaurations se chevauchent.
Dimensionner avec le taux de changement
Le volume source seul ne suffit pas. Relevez le volume réellement utilisé, la quantité modifiée entre deux sauvegardes, la fréquence des jobs et la durée de rétention. Mesurez ensuite la croissance réelle du datastore pendant plusieurs semaines. Le comparatif VPS, serveur dédié et mutualisé aide à distinguer les cas où le contrôle du matériel et des I/O justifie un serveur dédié.
Chez Tomco, les sauvegardes Enhance disposent d'une rétention de 90 jours et sont complétées par des snapshots ZFS. Cette donnée illustre le point essentiel : la profondeur de sauvegarde doit être explicite et mesurable ; elle ne remplace ni la séparation du domaine de panne ni les tests de restauration.
Installer PBS et le connecter à Proxmox VE
L'installation la plus directe utilise l'ISO PBS. L'installateur peut préparer ext4, XFS ou ZFS et efface les disques sélectionnés. Une installation sur Debian reste possible, mais elle laisse davantage de choix de stockage et de réseau à administrer manuellement. L'interface web de Proxmox Backup Server répond en HTTPS sur le port 8007.
Avant le premier job : mettez PBS à jour, vérifiez DNS et heure, créez le datastore, puis créez une identité dédiée. Récupérez ensuite l'empreinte du certificat auto-signé :
proxmox-backup-manager cert infoDans Proxmox VE, ajoutez le dépôt depuis Datacenter > Storage > Add > Proxmox Backup Server. La même opération peut être automatisée avec pvesm ; adaptez le serveur, le datastore, l'utilisateur et l'empreinte à votre environnement :
pvesm add pbs pbs-prod \
--server 10.10.20.10 \
--datastore datastore1 \
--username backup@pbs \
--fingerprint 'AA:BB:CC:DD:...'Créez ensuite un job sur une VM non critique et restaurez-la avant d'élargir le périmètre. Ce test valide les droits, le réseau et le chemin de restauration beaucoup plus tôt qu'un incident réel.
Rétention, prune, garbage collection et vérification
Une politique de Proxmox Backup Server peut combiner keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly et keep-yearly. Le but n'est pas de conserver le maximum, mais de disposer de points cohérents avec le RPO et les scénarios de retour arrière.
Le prune retire les snapshots qui ne correspondent plus à la politique. Comme plusieurs snapshots peuvent partager les mêmes chunks, cette suppression ne libère pas immédiatement tout l'espace attendu. Le garbage collection parcourt ensuite le datastore et récupère les chunks qui ne sont plus référencés. Le simulateur de prune officiel permet de vérifier une combinaison de règles avant de l'appliquer.
Les Verify Jobs relisent les sauvegardes et contrôlent leur intégrité. Activez une planification adaptée au volume et surveillez les notifications d'échec. Trois niveaux doivent rester distincts : job terminé, données vérifiées, service restauré. Seul le troisième valide la reprise de bout en bout.
Pour éviter que la maintenance n'entre en concurrence avec les sauvegardes de nuit, observez la durée réelle de chaque Verify Job et du garbage collection. Si une vérification déborde régulièrement sur la fenêtre de production, réduisez le chevauchement des tâches ou augmentez les ressources de stockage plutôt que de désactiver le contrôle. L'objectif est de connaître la durée d'une vérification complète et de détecter une dérive avant qu'elle ne transforme une restauration urgente en opération imprévisible.
Créer une copie hors site avec les Sync Jobs
Un PBS dédié protège du cluster, mais pas forcément du bâtiment, du compte administrateur ou de l'alimentation partagée. Les Sync Jobs permettent de synchroniser les datastores entre instances PBS. La documentation 4.2.6-1 décrit les synchronisations en pull et en push et recommande, pour le push, une configuration distante dédiée par job avec des permissions limitées.
Une copie distante doit rester indépendante du système source. Évitez qu'un seul compte puisse supprimer simultanément le datastore local et le datastore distant. Examinez aussi l'effet de remove-vanished avant de l'activer : une automatisation de nettoyage est utile uniquement si son périmètre est parfaitement compris.
Pour une infrastructure hébergée sur serveur dédié, le réseau, la capacité de stockage et la fenêtre de synchronisation doivent être dimensionnés ensemble. Les pages serveurs dédiés et technologies décrivent les briques d'infrastructure disponibles chez Tomco sans remplacer le dimensionnement propre au plan de reprise.
Restaurer et mesurer RPO/RTO
Une sauvegarde est exploitable lorsqu'elle permet de reconstruire un service dans le temps attendu. PBS permet de restaurer une VM, un conteneur et des fichiers individuels. Proxmox VE propose aussi le live-restore pour certains scénarios de VM afin de remettre la machine en fonctionnement pendant que le reste des données est encore transféré.
Testez au moins trois scénarios : récupération d'un fichier avec ses permissions, restauration complète d'une VM dans un réseau isolé et reprise depuis la copie distante. Si les sauvegardes sont chiffrées, réalisez l'exercice avec la procédure réelle de récupération des clés.
Le RPO correspond au dernier point de restauration acceptable ; le RTO mesure le temps nécessaire pour remettre le service dans un état utilisable. Une sauvegarde toutes les quatre heures ne permet pas d'annoncer un RPO de quinze minutes. De la même manière, un débit de restauration théorique ne constitue pas un RTO : il faut inclure le diagnostic, la récupération, le démarrage et les contrôles fonctionnels.
Checklist PBS avant production
Avant d'étendre les jobs à toutes les VM, vérifiez que le PBS reste joignable avec un hyperviseur éteint, que le datastore n'est pas sur le stockage de production, que la capacité inclut la croissance et la rétention, et que les identités de sauvegarde ont des droits limités. Contrôlez aussi que les clés de chiffrement existent dans un emplacement indépendant.
Planifiez backup, prune, garbage collection et Verify Jobs dans des fenêtres compatibles. Surveillez leurs erreurs, synchronisez une seconde copie et restaurez réellement une charge complète. Un PBS bien configuré n'est pas celui dont tous les jobs sont verts : c'est celui pour lequel l'équipe connaît le point de reprise disponible et a déjà mesuré le temps nécessaire pour revenir en service.
