La règle est simple et je l’ai apprise à mes dépens avec la VM Gitea de l’article précédent : une donnée sans backup n’existe pas. Corollaire homelab : un backup sur le même disque que les données n’est pas un backup.
PBS est la solution de sauvegarde officielle de l’écosystème Proxmox. Ce n’est pas une fonctionnalité du nœud – c’est un OS séparé, avec son propre dépôt, son propre port (8007), sa propre gestion. Ça se déploie en VM sur le nœud qu’il sauvegarde, ou mieux, sur une machine physique distincte.
PBS vs vzdump : pourquoi changer
Proxmox intègre vzdump nativement – il créé des archives .tar.gz pour les LXC et .vma.zst pour les VMs KVM. C’est fonctionnel, c’est simple, et ça sauvegarde vraiment les données. Mais :
| Critère | vzdump | PBS |
|---|---|---|
| Déduplication | ❌ | ✅ (chunk-based, -60% à -80% d’espace) |
| Sauvegardes incrémentielles | ❌ (toujours complet) | ✅ |
| Vérification d’intégrité | Manuelle | ✅ automatique à chaque sauvegarde |
| Catalogue de restauration | Basique | ✅ (navigation dans les fichiers avant restauration) |
| Chiffrement | Optionnel | ✅ client-side (AES-256-GCM) |
La déduplication est le point décisif. Mon homelab contient 12 machines dont 4 Debian 12 et 3 Ubuntu 24.04. Sans déduplication, chaque snapshot quotidien stocke 4× l’OS complet de Debian en entier. Avec PBS, les blocs communs entre les machines – le kernel, les librairies système, apt cache – ne sont stockés qu’une fois.
Résultat concret sur mon setup : 12 VMs et LXC, backups quotidiens, rétention 7j. Sans PBS : ~180 Go par rotation de 7 jours. Avec PBS : ~28 Go. La déduplication est effective dès la deuxième sauvegarde.
Architecture du déploiement
PBS est déployé en VM Debian sur le nœud (VM 250, IP 192.168.30.50, réseau serveurs VLAN 30). Un disque de données de 500 Go lui est attaché depuis le pool ZFS rpool – ce disque contient le datastore PBS.
MS-01 (Proxmox 192.168.1.10)
│
├── rpool (ZFS mirror NVMe) → disque virtuel 500GB attaché à VM PBS
│
└── VM 250 PBS (192.168.30.50)
└── Datastore /backup/homelab
├── Namespace VMs
│ ├── qemu/200 (nextcloud)
│ ├── qemu/201 (gitea)
│ └── ...
└── Namespace LXC
├── lxc/150 (pihole)
└── ...
Déployer PBS sur le même nœud physique qu’il sauvegarde est un compromis : en cas de panne matérielle du MS-01, les sauvegardes sont perdues avec les données. C’est pourquoi la règle 3-2-1 exige une copie hors-site – voir la section dédiée.
Installer PBS
PBS s’installe sur une VM Debian 12 standard. Créer la VM avec 2 vCPU, 2 Go RAM, 16 Go pour l’OS. Ajouter ensuite un disque de données séparé pour le datastore (ne jamais mélanger OS et données de sauvegarde).
# Dans la VM PBS (Debian 12)
apt update && apt install -y curl
# Ajouter le dépôt PBS no-subscription
echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription"
> /etc/apt/sources.list.d/pbs.list
curl -fsSL https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg
-o /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
apt update && apt install -y proxmox-backup-server
L’interface PBS est accessible sur https://192.168.30.50:8007. Même mécanique que Proxmox : certificat auto-signé, accepter l’exception navigateur.
Configurer le disque de données
Le disque de données attaché à la VM apparaît comme /dev/vdb. Le formater en ext4 et le monter :
# Vérifier que le disque est bien là
lsblk
# vda 16G ← OS PBS
# vdb 500G ← données datastore
# Formater (opération destructive - vérifier le device avant)
mkfs.ext4 -L pbs-data /dev/vdb
# Monter de façon permanente
echo "LABEL=pbs-data /backup ext4 defaults,noatime 0 2" >> /etc/fstab
mkdir -p /backup
mount -a
# Vérifier
df -h /backup
# Filesystem Size Used Avail Use%
# /dev/vdb 492G 28G 464G 6%
Créer le datastore
Depuis l’interface PBS (https://192.168.30.50:8007) :
Datastores > Create: Directory Datastore
Name : homelab-backup
Path : /backup/homelab
GC Schedule : 02:30 (nettoyage garbage après les backups)
Prune Schedule : 03:00 (application des règles de rétention)
Notify : Always
Configurer les règles de rétention :
Keep Last : 3 (3 dernières sauvegardes)
Keep Daily : 7 (1 par jour sur 7 jours)
Keep Weekly : 4 (1 par semaine sur 4 semaines)
Keep Monthly : 3 (1 par mois sur 3 mois)
Ces règles s’appliquent par machine. Une VM avec un backup par nuit conservera 7 backups quotidiens, puis 4 hebdomadaires, puis 3 mensuels. Avec la déduplication, l’espace réel consommé reste raisonnable même avec une rétention longue.
Créer l’utilisateur backup
Ne pas utiliser root@pam pour les backups depuis Proxmox. Créer un utilisateur dédié avec les droits minimaux :
PBS GUI > Configuration > User Management > Add
Username : backup-user
Realm : pbs
Password :
Assigner les droits sur le datastore :
PBS GUI > Configuration > Access Control > Add
Path : /datastore/homelab-backup
User : backup-user@pbs
Role : DatastoreBackup
Connecter Proxmox à PBS
Récupérer le fingerprint TLS de PBS :
# Sur le nœud PBS
openssl x509 -in /etc/proxmox-backup/proxy.pem -noout -fingerprint -sha256
# SHA256 Fingerprint=XX:XX:XX:...
Ou depuis l’interface PBS : Dashboard > Fingerprint.
Dans Proxmox :
Datacenter > Storage > Add > Proxmox Backup Server
ID : pbs-homelab
Server : 192.168.30.50
Username : backup-user@pbs
Password :
Datastore : homelab-backup
Fingerprint : XX:XX:XX:... (copier depuis PBS)
Namespace : (vide = racine du datastore)
PBS apparaît dans la liste des stockages. Les VMs et LXC peuvent maintenant être sauvegardées vers lui.
Créer les jobs de backup
Datacenter > Backup > Add
Storage : pbs-homelab
Schedule : daily 02:00
Selection : All (toutes les VMs et LXC)
Mode : Snapshot ← pour VMs KVM (pas d'arrêt)
Stop ← pour LXC (arrêt propre, plus fiable)
Compression : zstd ← meilleur ratio vitesse/compression
Send email : you@arewel.com
Email on : Always
Le mode Snapshot pour les VMs KVM utilise le mécanisme QEMU de snapshot mémoire – la VM continue de tourner pendant la sauvegarde. Pour les LXC, Stop est plus sûr : il arrête le container, fait le backup, redémarre. L’interruption dure 30 à 90 secondes selon la taille.
Si l’arrêt de nuit est inacceptable pour un LXC, utiliser le mode Suspend – il met la VM en pause, backup, reprend. Plus rapide que Stop, mais laisse le container en état suspendu pendant quelques secondes ce qui peut dérouter des applications avec des connexions TCP longues.
Vérifier et restaurer
PBS vérifie l’intégrité de chaque backup à la création via des checksums. Une vérification complète du datastore peut être lancée manuellement :
# Sur le nœud PBS
proxmox-backup-manager verify-task homelab-backup
# Ou depuis l'interface PBS : Datastore > homelab-backup > Verify
Pour restaurer une VM depuis Proxmox :
VM 201 > Backup > Sélectionner le snapshot PBS
> Restore
Target Storage : local-lvm (ou rpool selon la destination)
Force : ✅ (remplace l'existant)
Ou en CLI depuis le nœud Proxmox :
# Restaurer la VM 201 à partir du backup PBS du 2026-06-01
qmrestore pbs-homelab:backup/qemu/201/2026-06-01T02:00:00Z 201
--storage rpool --force 1
# Pour un LXC
pct restore 150 pbs-homelab:backup/lxc/150/2026-06-01T02:00:00Z
--storage rpool --force 1
Avant de restaurer en production, toujours tester la restauration dans un ID différent pour valider l’intégrité des données sans écraser la machine active.
La règle 3-2-1 appliquée
3 copies :
1. Données actives (VMs sur rpool, ZFS mirror)
2. Backups PBS (VM PBS sur rpool, même nœud)
3. Copie hors-site (Backblaze B2)
2 supports différents :
- NVMe (rpool ZFS mirror)
- Cloud object storage (B2)
1 copie hors-site :
- Backblaze B2 à ~€0.006/Go/mois
Le point 3 – la copie hors-site – est ce qui protège contre un incident physique (incendie, vol, panne électrique destructive). PBS peut synchroniser vers un second PBS distant, ou on peut utiliser rclone pour pousser le datastore vers B2 :
# Installer rclone
curl https://rclone.org/install.sh | bash
# Configurer B2 (interactif)
rclone config
# Choisir : b2, bucket name, application key ID, application key
# Sync nocturne du datastore (ajouter en crontab)
rclone sync /backup/homelab b2:mon-bucket-pbs-homelab
--transfers=4
--b2-chunk-size=128M
--log-file=/var/log/rclone-b2.log
# Taille estimée pour 12 VMs, rétention 1 mois : ~45 Go → ~€0.27/mois
Ce qui a coincé
Le premier job de backup a échoué pour trois LXC en mode Snapshot. Erreur dans le log Proxmox :
backup of CT 150 failed: 100.00% (1.69 GiB of 1.69 GiB)
got lock timeout - no backup was done
La cause : mode Snapshot pour les LXC n’est pas toujours supporté selon la configuration du container. Pi-hole en LXC unprivileged avec nesting=0 ne supporte pas le snapshot à chaud – PBS tente de créer un snapshot du filesystem qui nécessite des droits kernel non disponibles dans un LXC sans nesting.
Correction : passer ces LXC en mode Stop dans le job de backup. L’interruption est de 45 secondes pour Pi-hole – acceptable pour un service DNS qui a un fallback configuré (voir article 5 : DNS secondaire 192.168.1.1 sur le ZenWifi).
Deuxième incident : après 3 semaines, l’alerte e-mail de PBS remontait GC failed sur le datastore. Un backup avait été interrompu en cours de route (coupure de courant de 2 secondes), laissant des chunks orphelins dans le datastore. Le Garbage Collector ne parvenait pas à les supprimer parce qu’un verrou de session était resté bloqué.
# Sur le nœud PBS
proxmox-backup-manager datastore-list
# homelab-backup : gc lock held since 4h ago
# Forcer la suppression du verrou
rm /backup/homelab/.gc.lock
# Relancer le GC manuellement
proxmox-backup-manager garbage-collection start homelab-backup
GC terminé, 3.2 Go d’espace récupéré. Depuis, le nœud est sur un onduleur – les coupures de 2 secondes n’t arrivent plus.
Série « Homelab Proxmox MS-01 » – Article 7/10