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.
Ce guide explique comment je l’ai configuré, avec les captures de mon infra réelle.
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 -aCré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
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 :
- 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
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.
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.
