Proxmox Backup Server comme socle de restauration

Proxmox Backup Server ne devrait pas être déployé uniquement pour cocher une case sauvegarde. Le cas d’usage utile est plus concret : protéger un petit cluster Proxmox VE, restaurer rapidement une VM supprimée par erreur, revenir avant une mise à jour applicative ratée, et disposer d’un point de reprise si un stockage local devient indisponible. Dans ce contexte, l’installation de PBS n’est que la première étape. Le vrai sujet est la capacité à restaurer.

Le scénario retenu est un cluster de trois nœuds Proxmox VE avec une quinzaine de machines virtuelles. Certaines VM sont critiques, comme un serveur de fichiers, un outil de supervision, un serveur applicatif interne ou un contrôleur de domaine de test. D’autres sont reconstruisibles par Ansible ou Terraform. PBS est installé sur une machine séparée, avec un datastore dédié, un réseau de sauvegarde identifié et un compte Proxmox VE limité à l’écriture des sauvegardes.

Définir les classes de sauvegarde

La première action consiste à classer les VM. Une politique unique appliquée à tout le cluster est simple, mais elle ne répond pas aux vrais besoins. Une VM critique doit avoir une fréquence et une rétention différentes d’une VM temporaire. Une VM reconstruisible ne mérite pas toujours le même coût de stockage qu’un serveur contenant de l’état.

Classe critique
Exemples: fichiers, supervision, annuaire, application interne
Sauvegarde quotidienne ou plus fréquente
Rétention longue
Test de restauration planifié

Classe standard
Exemples: outils internes, serveurs applicatifs secondaires
Sauvegarde quotidienne
Rétention intermédiaire
Test de restauration par échantillon

Classe reconstruisible
Exemples: workers, VM de test, machines générées par IaC
Rétention courte
Sauvegarde optionnelle
Reconstruction documentée

Cette classification doit être écrite avant de créer les jobs. Sinon, la rétention devient un choix technique dans l’interface au lieu d’une décision d’exploitation. Le stockage finit par compenser l’absence de priorité.

Créer un datastore exploitable

Le datastore PBS doit être dimensionné avec la rétention et le taux de changement des VM en tête. La déduplication aide beaucoup, mais elle ne remplace pas le suivi de capacité. Un datastore qui semble confortable au démarrage peut devenir fragile après quelques mois si de nouvelles VM arrivent ou si la rétention est allongée.

Le minimum est de suivre l’espace disponible, la durée des backups, les erreurs de vérification et la durée du garbage collection. Si PBS tourne sur un stockage trop lent, les backups peuvent passer, mais les restaurations deviennent pénibles. Le test de restauration est donc aussi un test de performance du datastore.

# Sur le serveur PBS
proxmox-backup-manager datastore list
proxmox-backup-manager garbage-collection status <datastore>
proxmox-backup-manager verify-job list

# Contrôle système simple
df -h
lsblk
journalctl -u proxmox-backup-proxy -n 100 --no-pager

Le datastore ne doit pas être traité comme un disque oublié. Une alerte sur l’espace disponible doit exister. Une erreur de vérification doit être lue. Une tâche de garbage collection anormalement longue doit déclencher une question sur le stockage, la fenêtre d’exécution ou la croissance des backups.

Connecter Proxmox VE avec un compte limité

Proxmox VE doit écrire dans PBS avec un compte adapté. Utiliser un compte administrateur général pour les backups simplifie la configuration, mais augmente le risque. Un compte dédié au datastore, avec les permissions nécessaires et pas davantage, rend le modèle plus propre.

Dans Proxmox VE, le stockage PBS doit être ajouté avec le datastore, le fingerprint, le compte, le namespace si utilisé, et les options de chiffrement si la politique le demande. Le chiffrement côté client est utile, mais il impose une discipline sur la conservation des clés. Une sauvegarde chiffrée dont la clé est perdue devient inutilisable.

Compte PBS dédié
Utilisé par Proxmox VE pour écrire les backups
Permissions limitées au datastore ou namespace prévu
Pas de compte humain partagé

Clés de chiffrement
Stockées hors du cluster Proxmox VE
Sauvegardées dans un coffre maîtrisé
Testées lors d'une restauration réelle

Ce point est opérationnel. Une équipe doit savoir où sont les clés, qui peut les utiliser et comment restaurer si le cluster Proxmox VE d’origine n’est plus disponible.

Planifier les jobs par criticité

Les jobs de backup doivent suivre les classes définies. Les VM critiques peuvent avoir une sauvegarde quotidienne avec une rétention plus longue. Les VM standard peuvent suivre une politique plus simple. Les VM reconstruisibles peuvent être exclues ou sauvegardées avec une rétention courte.

Job critical-daily
Cibles: VM critiques
Fréquence: quotidienne
Rétention: 14 daily, 8 weekly, 6 monthly
Vérification: régulière

Job standard-daily
Cibles: VM standard
Fréquence: quotidienne
Rétention: 7 daily, 4 weekly
Vérification: par échantillon

Job rebuildable-short
Cibles: VM reconstruisibles
Fréquence: selon besoin
Rétention: courte
Alternative: reconstruction automatisée

La rétention doit être lisible par l’équipe. Si personne ne peut expliquer pourquoi 14 journaliers et 6 mensuels sont conservés, la politique n’est pas gouvernée. Elle est seulement configurée.

Comprendre pruning et garbage collection

PBS sépare le pruning et le garbage collection. Le pruning applique la politique de rétention en supprimant des références. Le garbage collection libère ensuite les blocs qui ne sont plus utilisés. Cette mécanique surprend souvent lors des premiers nettoyages, car l’espace disque n’est pas toujours libéré immédiatement après un changement de rétention.

Cycle PBS
Backup écrit de nouveaux chunks
Prune supprime les références hors rétention
Garbage collection supprime les chunks non référencés
Verify contrôle la lisibilité des sauvegardes
Restore test prouve que le backup est exploitable

Il faut donc planifier pruning, garbage collection et vérification dans des fenêtres compatibles avec l’activité. Lancer toutes les opérations lourdes en même temps peut dégrader les performances, surtout sur un petit serveur PBS.

Tester une restauration complète

Le test le plus important consiste à restaurer une VM complète dans un environnement isolé. Il ne faut pas attendre l’incident pour découvrir que la restauration est lente, que le réseau restauré n’est pas adapté, que l’adresse IP entre en conflit ou que la VM dépend d’un service externe absent.

Test mensuel recommandé
Sélectionner une VM standard
Restaurer vers un nom différent
Démarrer dans un réseau isolé
Vérifier boot, disque, réseau et service principal
Mesurer le temps de restauration
Supprimer la VM de test après validation

Pour une VM critique, le test doit aussi couvrir les dépendances minimales. Un serveur applicatif restauré peut démarrer mais rester inutilisable si la base, le DNS, le secret applicatif ou la route nécessaire ne sont pas présents. Le test doit donc vérifier le service rendu, pas seulement le boot.

Prévoir le scénario de perte du cluster

Un test local ne suffit pas. Le scénario le plus important est parfois la perte du cluster Proxmox VE d’origine. Dans ce cas, l’équipe doit savoir comment accéder à PBS, retrouver les clés, déclarer le stockage PBS sur un nouveau cluster ou une machine de secours, puis restaurer les VM prioritaires.

Perte du cluster Proxmox VE
1. Accéder à l'interface PBS
2. Vérifier l'état du datastore
3. Récupérer les clés de chiffrement si nécessaires
4. Installer ou utiliser un hôte Proxmox VE de secours
5. Ajouter le stockage PBS
6. Restaurer d'abord les VM critiques
7. Vérifier les services avant les VM secondaires

Cette procédure doit être testée au moins partiellement. Sans cela, PBS protège contre les suppressions accidentelles, mais pas forcément contre une perte plus large.

Conclusion

Proxmox Backup Server devient un vrai socle de restauration quand il est associé à des classes de sauvegarde, une rétention expliquée, un datastore surveillé, des comptes limités, des clés conservées correctement et des tests de restauration réels. La réussite ne se mesure pas au nombre de jobs verts, mais à la capacité de restaurer une VM utile dans un délai connu.

Le bon minimum pour une petite plateforme est simple : trois classes de VM, deux ou trois jobs de backup, une vérification régulière, un garbage collection planifié, un test mensuel de restauration et un runbook de perte du cluster. Avec cela, PBS cesse d’être un dépôt de sauvegardes et devient un outil de reprise exploitable.