Aller au contenu

ProxmoxBackupServer (PBS)

Mise à jour : 2026-10-19 | Non relu

Proxmox Backup Server (PBS) est la solution de sauvegarde dédiée de l'écosystème Proxmox. Installée sur une machine séparée, elle sauvegarde les VM et conteneurs de vos hyperviseurs Proxmox VE, avec trois atouts majeurs : les sauvegardes sont chiffrées, dédupliquées et incrémentales.

Trois mots-clés à comprendre
  • Incrémental : après la première sauvegarde complète, seules les données modifiées sont transférées. Les sauvegardes suivantes sont rapides et légères.
  • Dédupliqué : si un même bloc de données existe dans plusieurs VM (le même système d'exploitation, par exemple), PBS ne le stocke qu'une seule fois. L'espace disque économisé est considérable.
  • Chiffré : les sauvegardes peuvent être chiffrées côté client, avant d'être envoyées. Même quelqu'un qui accède au stockage PBS ne peut rien lire sans la clé.
Versions visées
  • Proxmox Backup Server 4.x, basé sur Debian 13 (Trixie)
  • Compatible avec Proxmox VE 8.x et 9.x
  • PBS 3.x correspondait à Debian 12 (Bookworm)

Le modèle de PBS

Analogie : imaginez une bibliothèque où chaque livre est découpé en pages numérotées. Plutôt que de ranger des livres entiers en double, la bibliothèque ne garde chaque page unique qu'une fois, et chaque sauvegarde n'est qu'une liste de pages à assembler. Ajouter un nouveau livre presque identique ne coûte que les quelques pages qui diffèrent.

En pratique :

  • Un datastore est l'espace de stockage des sauvegardes (un disque, un dossier).
  • À l'intérieur, les données sont découpées en chunks (des blocs). C'est le niveau où opère la déduplication : un chunk identique n'est stocké qu'une fois.
  • Une sauvegarde (snapshot) est essentiellement un index qui référence les chunks nécessaires pour reconstituer la VM à un instant donné.

Cette architecture explique les tâches de maintenance que l'on verra plus bas : comme les chunks sont partagés entre sauvegardes, supprimer une sauvegarde ne libère pas tout de suite l'espace (d'où le garbage collect), et il faut vérifier régulièrement que les chunks ne sont pas corrompus (d'où le verify).

Architecture recommandée

  • Une machine séparée de vos hyperviseurs. Si l'hyperviseur tombe ou est compromis, les sauvegardes restent intactes ailleurs.
  • Un datastore local sur les disques du serveur PBS : il reçoit les sauvegardes des VM, rapidement.
  • Une copie hors site : un second datastore, synchronisé depuis le local, hébergé ailleurs (autre site, NAS distant). C'est la clé de la règle 3-2-1 (3 copies, 2 supports, 1 hors site).
  • Un accès d'administration par VPN : l'interface web de PBS (port 8007) n'a aucune raison d'être exposée sur Internet.

Installer PBS

Comme pour Proxmox VE, deux voies : l'image ISO officielle (installe tout en une fois), ou l'installation sur une Debian 13 existante (fréquent sur un serveur loué). Voici la seconde.

1) Ajouter la clé de signature du dépôt Proxmox :

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg

2) Créer le dépôt sans abonnement dans /etc/apt/sources.list.d/pbs.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

3) Installer :

apt update
apt install -y proxmox-backup-server

4) Accéder à l'interface web : https://adresse-ip:8007, utilisateur root.

Le dépôt enterprise par défaut : erreur 401

Comme Proxmox VE, une installation par ISO active le dépôt enterprise, payant, et apt update échoue alors avec une erreur 401 Unauthorized. PBS est gratuit : utilisez le dépôt no-subscription ci-dessus, et désactivez l'enterprise (ajoutez Enabled: false à son fichier .sources, ou supprimez-le). N'activez jamais les deux en même temps.

L'installation met en place deux services, qui démarrent au boot :

systemctl status proxmox-backup          # l'API
systemctl status proxmox-backup-proxy    # l'interface web (HTTPS)

Créer un datastore

Un datastore a besoin d'un espace de stockage dédié (un disque, une partition, un volume monté). Dans l'interface web : Datastore > Add Datastore, donnez un nom et le chemin du dossier.

Dédier un disque aux sauvegardes

Ne placez pas le datastore sur le disque système. Utilisez un disque ou un volume séparé : cela isole les sauvegardes, facilite leur extension, et évite qu'un datastore qui se remplit ne bloque le système.

Les comptes et les permissions

Utilisateurs d'administration

PBS gère ses propres comptes, dans des "realms" (domaines d'authentification). Le realm PAM correspond aux comptes Linux du système, ce qui unifie les identités système, SSH et PBS.

# Créer un compte d'administration lié au compte Linux "devrig"
proxmox-backup-manager user create devrig@pam
# Lui donner les droits d'administration des datastores
proxmox-backup-manager acl update / DatastoreAdmin --auth-id devrig@pam

Compte de service pour les sauvegardes

Pour la connexion entre vos hyperviseurs et PBS, créez un compte de service dédié (dans le realm PBS), avec les seules permissions nécessaires. On ne se sert jamais du compte root pour cela.

Ne pas confondre les comptes PBS et l'utilisateur Unix

Les comptes applicatifs de PBS (devrig@pam, svc@pbs...) servent à l'authentification sur l'API et au contrôle d'accès aux datastores. Ils n'ont rien à voir avec l'utilisateur Unix backup (uid 34), sous l'identité duquel PBS écrit réellement les fichiers sur le disque. Cette distinction devient cruciale si vous placez un datastore sur un partage réseau (NFS...) : c'est l'utilisateur backup qui doit avoir les droits d'écriture, pas vos comptes PBS.

Connecter un hyperviseur Proxmox VE

Côté Proxmox VE, on ajoute le PBS comme stockage de sauvegarde : Datacenter > Storage > Add > Proxmox Backup Server. Renseignez l'adresse du PBS, le datastore, le compte de service, et l'empreinte (fingerprint) du certificat PBS (affichée dans l'interface de PBS).

La clé de chiffrement : à sauvegarder absolument

Si vous activez le chiffrement, PVE génère une clé de chiffrement. Sans cette clé, vos sauvegardes sont définitivement illisibles, même par vous. Sauvegardez-la séparément (gestionnaire de mots de passe, coffre hors ligne). Lors d'une restauration sur un PVE réinstallé, il faudra charger cette clé pour accéder aux sauvegardes chiffrées.

Planifier les sauvegardes

La planification se fait côté Proxmox VE : Datacenter > Backup > Add. On choisit les VM, l'horaire, et le stockage PBS comme destination. C'est PVE qui déclenche l'envoi vers PBS.

Prérequis de cohérence : le QEMU Guest Agent doit être actif dans chaque VM. Il gèle le système de fichiers au moment de la sauvegarde, garantissant une image cohérente plutôt qu'une photo prise "en plein mouvement".

Les quatre tâches de maintenance du datastore

Ces tâches se configurent côté PBS, par datastore. Elles sont le cœur d'une sauvegarde saine.

1. Prune (rétention) : décider quoi garder

Le prune applique la politique de rétention en supprimant les sauvegardes qu'aucun critère ne retient.

Analogie : chaque critère est un tamis à une maille différente. On garde les N dernières, une par semaine, une par mois, une par an. Une sauvegarde survit dès qu'au moins un tamis la retient. On obtient ainsi une granularité fine sur le court terme, et un historique clairsemé sur le long terme.

Exemple de rétention (Datastore > Prune & GC) :

keep-last     : 14    (les 14 dernières)
keep-weekly   : 8
keep-monthly  : 12
keep-yearly   : 5

keep-last compte des sauvegardes, pas des jours

Avec une sauvegarde par jour, keep-last 14 couvre 14 jours. Si vous passez à deux sauvegardes par jour, cela ne couvre plus que 7 jours. Pour raisonner en jours quelle que soit la fréquence, utilisez plutôt keep-daily.

2. Verify (vérification) : s'assurer que c'est restaurable

Le verify relit les chunks et contrôle leur empreinte. C'est ce qui garantit qu'une sauvegarde est réellement restaurable, et non silencieusement corrompue.

Réglages recommandés : activez Skip Verified et Re-Verify After 30 days. Ainsi, seules les sauvegardes jamais vérifiées, ou vérifiées il y a plus de 30 jours, sont relues. Sans cela, chaque passage relirait l'intégralité du datastore, ce qui peut représenter plusieurs téraoctets.

3. Garbage Collect : libérer réellement l'espace

Le prune retire les références à une sauvegarde, mais les chunks, partagés entre sauvegardes, restent tant qu'ils servent encore. Le garbage collect (GC) supprime les chunks qui ne sont plus référencés par aucune sauvegarde. C'est lui qui libère vraiment l'espace disque après un prune.

Planifiez-le régulièrement (une fois par semaine convient souvent), après les prunes.

4. Sync : la copie hors site

Un sync job copie le contenu d'un datastore vers un autre. C'est ainsi qu'on alimente la copie hors site de la règle 3-2-1 : le datastore local reçoit les sauvegardes rapidement, puis un sync job les recopie vers un datastore distant, en ne transférant que les nouveaux chunks (grâce à la déduplication).

Réglages utiles d'un sync job :

  • Direction : pull (le PBS de destination va chercher les données) ou push. Le pull est souvent préféré pour la sécurité : la machine qui détient la copie hors site n'a pas besoin d'accès en écriture sur la source.
  • Remove vanished : désactivé, en général, pour la copie hors site. Ainsi, une sauvegarde supprimée côté local (par un prune) n'est pas supprimée de la copie distante. La copie hors site peut alors garder un historique plus profond, piloté par son propre prune, et résiste à une purge accidentelle côté local.
Un enchaînement cohérent dans la nuit

L'ordre des tâches compte. Un enchaînement type sur une nuit :

  1. Sauvegarde des VM (déclenchée par PVE) vers le datastore local.
  2. Sync du local vers la copie hors site.
  3. Prune des deux datastores (avec des rétentions distinctes).
  4. Verify puis Garbage Collect en fin de semaine.

Le principe : rien n'est purgé en local avant d'avoir été copié hors site.

Copie hors site : points de vigilance

Si votre copie hors site passe par un partage réseau (NFS sur un NAS, par exemple), voici les pièges les plus fréquents, tirés de l'expérience :

  • Le montage doit être prêt avant que PBS n'écrive. Si le partage n'est pas monté au démarrage (réseau ou VPN pas encore établi), PBS risque d'écrire sur un dossier vide du disque système et de le saturer. Dans /etc/fstab, les options nofail et une dépendance explicite au service réseau/VPN (x-systemd.requires=...) sont essentielles.
  • Les permissions Unix. Le datastore distant doit appartenir à l'utilisateur backup (uid 34). Sur certains NAS, les ACL propriétaires peuvent bloquer l'écriture à la racine d'un partage : créer le datastore dans un sous-dossier contourne souvent le problème.
  • Une protection anti-rançongiciel réellement hors de portée. La rétention PBS (prune) reste pilotable depuis le PBS : un attaquant qui le compromet pourrait l'effacer. Des instantanés (snapshots) pris par le NAS lui-même, inaccessibles depuis PBS, offrent une protection que la seule rétention PBS ne peut pas garantir.

Restaurer

La restauration se fait depuis Proxmox VE, connecté au datastore PBS :

  • restauration complète d'une VM à une date choisie;
  • restauration de fichiers (File Restore) pour récupérer un élément isolé sans restaurer toute la VM.

Pour les sauvegardes chiffrées, la clé doit être chargée sur le PVE.

Testez une restauration au moins une fois par an

Déroulez une vraie restauration sur une VM jetable. Une sauvegarde jamais restaurée n'est pas une sauvegarde : c'est le seul test qui valide toute la chaîne, y compris le déchiffrement.

Surveiller

  • Notifications mail : PBS peut alerter sur l'échec d'une tâche (sauvegarde, sync, verify, GC). Configurez-les et vérifiez que les mails arrivent.
  • Ressources : comme PBS est une machine externe aux hyperviseurs, supervisez-la avec votre outil habituel (Beszel, Zabbix...) pour l'espace disque, le CPU et la mémoire.

Le point le plus important à surveiller est l'espace disque du datastore : un datastore plein fait échouer les sauvegardes suivantes.

Mettre à jour

full-upgrade, jamais upgrade

Comme Proxmox VE, PBS exige apt full-upgrade, jamais apt upgrade, pour gérer correctement les dépendances de ses paquets.

apt update
apt full-upgrade
proxmox-backup-manager version    # vérifier la version

Avant la mise à jour : vérifiez qu'aucune tâche (sauvegarde, prune, GC, sync) n'est en cours. Redémarrez si le noyau a été mis à jour, puis contrôlez les services :

systemctl status proxmox-backup proxmox-backup-proxy

Si votre copie hors site dépend d'un VPN, vérifiez après la mise à jour que le tunnel et le montage réseau sont bien revenus : une mise à jour du paquet VPN peut couper brièvement la connexion.

Montée de version majeure (ex. 3 vers 4) : suivez le guide officiel de migration, avec sauvegarde préalable.

Diagnostic

proxmox-backup-manager version              # version de PBS
proxmox-backup-manager datastore list       # lister les datastores
proxmox-backup-manager task list            # tâches récentes et leur état
systemctl status proxmox-backup-proxy       # service web
journalctl -u proxmox-backup-proxy -n 50    # journaux
df -h /chemin/du/datastore                  # espace disque du datastore

Problèmes fréquents :

  • apt update renvoie 401 : le dépôt enterprise est encore actif (voir l'encadré sur les dépôts).
  • unable to open chunk store ... Permission denied : sur un datastore distant, les permissions ne sont pas à backup (uid 34), ou le partage n'est pas monté.
  • Les sauvegardes échouent soudainement : vérifiez l'espace disque du datastore en premier.

Références