Proxmox Backup Server : sauvegarder ses VMs et LXC

Pendant les six premiers mois de mon homelab, je n’avais pas de vraie solution de backup des VMs. Des snapshots ZFS occasionnels, c’est tout. Un jour, j’ai eu besoin de restaurer Home Assistant après une mise à jour catastrophique. Les snapshots étaient là, incomplets et pas assez récents. J’ai passé 4 heures à reconstruire la configuration depuis zéro. Quelques mois plus tard, un NVMe a lâché sur mon noeud principal. Cette fois, PBS était en place. 8 minutes pour restaurer les VMs critiques, zéro donnée perdue. C’est la différence entre une solution de backup sérieuse et des snapshots occasionnels.

En Bref : Proxmox Backup Server sauvegarde toutes mes VMs et LXC chaque nuit avec backup incrémentiel (2-3 minutes après le premier complet). Déduplication entre VMs similaires, vérification d’intégrité, restauration. Un NVMe a lâché sur mon cluster : PBS a pu tout restaurer en moins de 10 minutes. Installez-le dès le début, pas dans 6 mois.

Ce guide explique comment je l’ai configuré, avec les captures de mon infra réelle.

Le dashboard PBS de mon homelab : 2 datastores, longest tasks sur 30 jours, tout vert.

PBS vs snapshots ZFS

Les snapshots ZFS sont excellents pour les rollbacks rapides sur le même serveur. PBS apporte ce que les snapshots ne peuvent pas :

Backup incrémentiel : PBS ne sauvegarde que les blocs modifiés depuis la dernière sauvegarde. Un backup complet prend 20 minutes, les suivants 2-3 minutes.
Déduplication : les blocs identiques entre VMs ne sont stockés qu’une fois. Sur mon cluster, 3 VMs Debian similaires ne triplent pas l’espace de backup.
Stockage distant : PBS peut tourner sur un nœud différent (ou un NAS). Si le nœud principal lâche, les backups sont intacts.
Vérification d’intégrité : PBS vérifie les données sauvegardées via des checksums. Tu sais que le backup est restaurable.

Architecture sur mon homelab

PBS tourne sur une VM dédiée, sur un nœud séparé de celui qui héberge les VMs critiques. Deux datastores en production :

unas : mon NAS UNAS Pro via NFS. Utilisé pour les VMs critiques avec rétention plus longue.
syno-pbs : Synology secondaire via NFS. C’est le datastore principal pour les backups quotidiens.

Point important sur la VM PBS elle-même : la VM PBS est sauvegardée directement sur un stockage NFS via un backup job Proxmox standard, pas via PBS lui-même. Raison : une VM PBS qui se sauvegarde via elle-même peut provoquer des freezes. La règle : PBS sauvegarde tout le monde, mais pas lui-même.

Fréquence : backup quotidien à 2h du matin (creux de charge)
Rétention : keep-daily=10, keep-monthly=1, keep-weekly=4 selon le datastore
VMs sauvegardées : toutes, avec exclusion de la VM PBS et de Xpenology du job PBS principal

Installation de PBS

PBS s’installe comme Proxmox VE : depuis une ISO dédiée disponible sur proxmox.com. Sur une VM de 2 vCPU, 4 Go RAM, 32 Go système :

Télécharge l’ISO PBS depuis proxmox.com
Crée une VM sur un nœud différent de tes VMs critiques
Lance l’installation, configure l’IP fixe
Accède à l’interface : https://<IP>:8007

Configurer le datastore

Un datastore est l’endroit où PBS stocke les backups. Sur mon setup, le datastore pointe vers un répertoire NFS :

Monter le NFS

# Sur la VM PBS :
apt install nfs-common -y
mkdir -p /mnt/nas-backup
echo "192.168.1.30:/volume1/proxmox-backup /mnt/nas-backup nfs defaults,_netdev 0 0" >> /etc/fstab
mount -a

Créer le datastore

Dans PBS : Datastore > Add Datastore :

Name : nas-backup
Backing Path : /mnt/nas-backup
Prune Options : Keep Daily 7, Keep Weekly 4, Keep Monthly 3

Datastore syno-pbs : 15 groupes CT, 5 groupes VM, 275 snapshots au total.

Connecter Proxmox VE à PBS

Dans PVE : Datacenter > Storage > Add > Proxmox Backup Server :

Server : IP de la VM PBS
Username : root@pam
Password : mot de passe PBS
Datastore : nas-backup

PVE va récupérer le fingerprint SSL de PBS automatiquement. Si tu as plusieurs datastores (comme moi avec unas et syno-pbs), ajoute-les chacun comme stockage séparé dans PVE.

Planifier les backups automatiques

Dans PVE : Datacenter > Backup > Add. Sur mon cluster, j’ai 4 jobs configurés :

4 backup jobs en production : job PBS quotidien avec rétention complète, job NFS direct mensuel pour PBS, job PBS secondaire nocturne.

Job PBS principal (NAS via NFS) : toutes les VMs sauf PBS et Xpenology, chaque dimanche à 1h, keep-daily=3, keep-monthly=2, keep-weekly=4, keep-yearly=1
Job PBS secondaire (NAS Synology) : toutes sauf PBS et Xpenology, à 2h du matin, keep-daily=10, keep-monthly=1, keep-weekly=4
Job NFS direct (pour PBS) : la VM PBS et Xpenology (ne passant pas par PBS lui-même), mensuel, keep-last=2
Backup local SSD : tout le cluster, mensuel

Détail du job PBS principal : mode Snapshot, ZSTD, avec exclusion manuelle de la VM PBS et de Xpenology.

Le mode Snapshot est indispensable : il sauvegarde la VM sans l’arrêter. Le mode Stop existe mais interrompt le service ; à réserver aux VMs qui ne supportent pas les snapshots.

Restauration : quand un NVMe lâche

C’est la partie qui compte. Dans PVE : clic droit sur une VM > Restore. Sélectionne le point de restauration PBS, choisis le stockage destination, confirme. Sur mon cluster, j’ai vécu la situation réelle : un NVMe a lâché sur le noeud principal. Toutes les VMs hébergées dessus étaient inaccessibles. Avec PBS en place, la procédure a été simple :

Ajout d’un nouveau disque de remplacement sur le nœud
Restauration des VMs critiques depuis PBS en priorité : Home Assistant, bases de données, services réseau
Chaque VM restaurée en 8 à 15 minutes selon sa taille
Retour à un état fonctionnel en moins d’une heure

Sans PBS, j’aurais passé plusieurs jours à tout reconstruire. Installez PBS dès le début, pas après le premier incident.

Monitoring des backups

PBS envoie des emails de résumé après chaque job. Je complète ça avec un heartbeat Uptime Kuma : un script pingue Uptime Kuma après chaque backup réussi. Si le heartbeat n’arrive pas dans les 26 heures, alerte Telegram.

Task Summary sur 30 jours : 575 backups, 609 prunes, 510 vérifications. 4 warnings à investiguer, 0 erreur.

Les 4 warnings visibles sur le Task Summary correspondent à des snapshots en cours lors du déclenchement du job (VM en état transitoire). PBS les ignore proprement et relance au prochain cycle.

PBS 4.2 : les nouveautés du 29 avril 2026

Proxmox vient de sortir PBS 4.2 le 29 avril 2026 (veille de la publication de cet article). Les points notables pour un homelab :

Chiffrement côté serveur pour les sync jobs push

Les push sync jobs peuvent maintenant chiffrer les snapshots avant de les envoyer vers un datastore distant. Utile si tu synchronises vers un stockage offsite moins maîtrisé (cloud, chez un ami, serveur distant). Les pull sync jobs peuvent inversement déchiffrer les snapshots chiffrés à la source.

Traitement parallèle des groupes (sync jobs)

Nouvelle propriété worker-threads sur les sync jobs : plusieurs groupes peuvent être synchronisés en parallèle. Impact direct sur les sync vers des stockages à haute latence (cloud, liaison ADSL). Sur un homelab standard avec NAS local, le gain sera limité.

Déplacement de groupes et namespaces

Les groupes de backup et namespaces peuvent être déplacés vers d’autres emplacements dans le même datastore. Pratique pour réorganiser les backups sans perte de données ni recréation complète.

S3 officiellement supporté

Le backend S3-compatible sort du mode « technology preview » et devient officiel. PBS peut maintenant stocker ses backups directement dans un bucket S3 (Backblaze B2, Wasabi, AWS S3, MinIO…) avec statistiques de requêtes et seuils d’alerte. Une option intéressante pour un stockage offsite automatique à faible coût. Base : Debian Trixie 13.4, kernel 7.0 en défaut stable, ZFS 2.4.1.

💡 Le petit truc en plus

Utilise le Verify Job dans PBS (Datastore > Verify Jobs > Add). Ce job vérifie régulièrement l’intégrité des backups stockés en recalculant et comparant les checksums. Configure un verify job hebdomadaire sur ton datastore : un backup corrompu, c’est comme pas de backup. Sur mes 30 derniers jours : 510 vérifications, zéro erreur.

Pour aller plus loin : créer ses premières VMs sur Proxmox, le setup homelab complet, Uptime Kuma pour monitorer les backups et ZFS et ses snapshots pour une deuxième couche de protection.

PBS : dormez tranquille

PBS est l’un des rares outils dont on espère ne jamais avoir besoin, et dont on est soulagé d’avoir quand ça arrive. Installez-le, configurez vos jobs, testez une restauration, puis oubliez-le. J’insiste sur le test de restauration : ne comptez pas sur vos backups sans avoir validé qu’ils fonctionnent. Cassez volontairement une VM de test, restaurez depuis PBS, chronométrez. Cette heure investie vous évitera plusieurs jours de reconstruction en cas d’incident réel.

FAQ

PBS ou snapshots ZFS, lequel choisir ?

Les deux sont complémentaires. Les snapshots ZFS servent au rollback rapide sur le même serveur. PBS apporte le backup distant, incrémentiel avec déduplication. Sur mon cluster, j’utilise les deux : snapshots ZFS pour les rollbacks rapides, PBS pour les sauvegardes nocturnes vers un autre nœud.

Combien d’espace disque faut-il pour PBS ?

Grâce à la déduplication et à la compression, PBS utilise beaucoup moins que la somme brute de toutes les VMs. Sur mon cluster avec 15 LXC et 5 VMs, le datastore syno-pbs occupe 3.53 TB avec 7 jours de rétention pour les VMs critiques.

PBS peut-il se sauvegarder lui-même ?

Non, et il ne faut pas le faire via PBS. La VM PBS doit être sauvegardée par un job Proxmox VE classique vers un stockage NFS ou local, indépendamment de PBS. Cela évite les dépendances circulaires et les freezes potentiels.

PBS peut-il sauvegarder sur un NAS distant ?

Oui, PBS supporte les datastores sur NFS et CIFS. Tu peux monter un partage NAS comme datastore PBS pour externaliser les backups. Depuis PBS 4.2, le backend S3 est officiellement supporté pour aller encore plus loin dans l’offsite.

Proxmox Backup Server : sauvegarder ses VMs et LXC automatiquement

PBS vs snapshots ZFS

Architecture sur mon homelab

Installation de PBS