Sauvegarder un cluster Proxmox avec PBS : déduplication, rétention et protection anti-ransomware

Quand on quitte les GAFAM pour s'auto-héberger, on ne quitte pas seulement leurs services applicatifs : on quitte aussi leur infrastructure de résilience. Plus de réplication multi-zone transparente, plus de versioning gratuit sur 30 jours, plus de bouton « restaurer un état d'il y a deux semaines » à un clic. Tout ça, il faut le reconstruire — et c'est exactement ce que Proxmox Backup Server (PBS) permet de faire avec un niveau d'ingénierie qui n'a rien à envier aux acteurs commerciaux.

Cet article décortique l'architecture de PBS et donne les paramètres exacts pour bâtir une politique de sauvegarde qui résiste aux trois principaux scénarios catastrophe : panne matérielle, corruption applicative et attaque par rançongiciel.

Architecture client/serveur de PBS

PBS n'est pas un simple dump périodique. C'est un serveur dédié (une VM ou un serveur physique séparé) qui parle au cluster Proxmox via un protocole optimisé. Le flux est le suivant : le client PVE découpe les disques des VMs en blocs de taille fixe, calcule un hash de chaque bloc, et n'envoie au serveur PBS que les blocs encore absents du datastore. Les blocs sont compressés avec Zstandard, puis chiffrés côté client si la clé est activée, avant traversée du réseau.

• Côté client (Proxmox VE) — `proxmox-backup-client` intégré nativement à `vzdump` depuis PVE 7. Aucune installation supplémentaire.
• Côté serveur (PBS) — instance Debian dédiée avec un ou plusieurs datastores ZFS ou ext4. Idéalement sur du matériel séparé.
• Protocole — HTTP/2 multiplexé sur TLS, dialogue authentifié par token API ou identifiants utilisateur.
• Datastore — répertoire structuré qui stocke les chunks (blocs dédupliqués) et les index par snapshot. Croissance maîtrisée grâce à la déduplication globale.

Déduplication à la source : pourquoi PBS est imbattable

La déduplication n'est pas une option de compression : c'est ce qui fait que sauvegarder un parc de 20 VMs Debian similaires occupe l'équivalent d'une seule sur le datastore. Concrètement, sur un cluster typique de 10 VMs Linux + 3 Windows, le ratio de déduplication observé en production tourne entre 5× et 12× — c'est-à-dire qu'on stocke 100 Go sur le serveur PBS pour ce qui ferait 600 Go en sauvegarde naïve.

Encore mieux : la déduplication est globale au datastore. Donc une nouvelle VM créée par clone d'une existante n'occupe quasiment rien dans la première sauvegarde — uniquement les blocs réellement modifiés depuis le template.

Compression : zstd contre lzo et gzip

PBS utilise Zstandard par défaut depuis sa première version. Comparé aux options héritées de `vzdump` (lzo, gzip), zstd domine sur les trois axes en même temps.

Zstandard (zstd)

• Vitesse — extrêmement rapide, à débit proche d'une copie disque non compressée.
• Multi-threading — natif. Sature autant de cœurs CPU que disponibles.
• Taux de compression — excellent, supérieur à lzo, proche de gzip à niveau équivalent.

LZO (legacy)

• Vitesse — modérée.
• Multi-threading — non.
• Taux de compression — faible. À éviter sauf cas de très vieux matériel.

GZIP (legacy)

• Vitesse — lente.
• Multi-threading — non.
• Taux de compression — élevé, mais le coût CPU rend les sauvegardes très longues.

Politique de rétention multi-niveaux

PBS implémente une grille de rétention à 5 niveaux qui permet de couvrir n'importe quel besoin de conformité historique sans saturer le stockage. La règle de base : on garde beaucoup de snapshots récents, et de plus en plus rares en remontant dans le temps.

keep-last

• Rôle — protection immédiate avant ou après mises à jour critiques.
• Valeur recommandée — 3 à 5.
• Couverture — quelques heures à quelques jours selon la fréquence de sauvegarde.

keep-daily

• Rôle — fenêtre quotidienne de restauration fine.
• Valeur recommandée — 13.
• Couverture — deux semaines complètes, jour par jour.

keep-weekly

• Rôle — historique hebdomadaire.
• Valeur recommandée — 8.
• Couverture — deux mois calendaires.

keep-monthly

• Rôle — couverture annuelle pour les besoins de conformité.
• Valeur recommandée — 11.
• Couverture — une année complète, mois par mois.

keep-yearly

• Rôle — archive longue durée.
• Valeur recommandée — 9.
• Couverture — jusqu'à 10 ans, pour conformité légale ou archivage froid.

Protection contre la suppression

Les rançongiciels modernes ne se contentent plus de chiffrer les données productives : ils cherchent activement les serveurs de sauvegarde sur le réseau pour effacer les snapshots avant de réclamer une rançon. PBS dispose de deux mécanismes empilables pour bloquer ce scénario.

Le premier est le fichier sentinelle `.protected` posé dans un groupe de sauvegarde : tant qu'il existe, PBS refuse toute opération de suppression sur les snapshots du groupe, y compris depuis l'interface admin. Le second est la gestion fine des permissions par token API — un client PVE ne dispose que du droit `Backup`, jamais du droit `Datastore.Modify`.

# Protéger un groupe de sauvegarde contre toute suppression
touch /mnt/datastore/backups/vm/100/.protected

# Vérifier les permissions du token utilisé par le client PVE
proxmox-backup-manager user list-tokens backup@pbs
# Le token doit avoir uniquement le rôle Datastore.Backup

Audit automatique des VMs non sauvegardées

Le risque principal d'une politique de sauvegarde n'est pas le bug du logiciel — c'est la VM créée à 23h un mardi soir qui n'est jamais ajoutée au pool de sauvegarde et qu'on découvre trois mois plus tard, en pleine panne. L'API de Proxmox expose un point de terminaison dédié à ce contrôle.

# Lister toutes les VMs et CTs sans sauvegarde planifiee
pvesh get /cluster/backup-info/not-backed-up --output-format json

# Resultat type :
# [{"vmid":"105","type":"qemu","name":"web-staging"},
#  {"vmid":"203","type":"lxc","name":"redis-cache"}]

Cette commande s'intègre dans un cron quotidien qui parse la sortie JSON et ajoute automatiquement les machines détectées à un job de sauvegarde dédié nommé `NewVMs`. Aucune VM ne tombe entre les mailles.

#!/bin/bash
# /usr/local/sbin/audit-backups.sh - a placer en cron quotidien
ORPHANS=$(pvesh get /cluster/backup-info/not-backed-up --output-format json)
COUNT=$(echo "$ORPHANS" | jq 'length')
if [ "$COUNT" -gt 0 ]; then
  echo "$COUNT VM/CT sans sauvegarde detectees" | mail -s "[PVE] Audit backup" [email protected]
  echo "$ORPHANS" | jq -r '.[].vmid' | while read VMID; do
    pvesh set /cluster/backup/NewVMs --vmid "+$VMID"
  done
fi

Stratégie 3-2-1 appliquée à PBS

La règle universelle de la sauvegarde reste valable : 3 copies des données, sur 2 supports différents, dont 1 hors site. Avec PBS, elle se traduit ainsi.

• Copie 1 — la donnée productive sur les disques des VMs.
• Copie 2 — le datastore PBS local sur ZFS avec snapshots quotidiens (premier niveau de défense contre la corruption).
• Copie 3 — un second PBS distant (VPS chez un hébergeur souverain) qui tire les sauvegardes en `pull` chaque nuit via le mode sync-job de PBS.
• Bonus offline — un disque externe USB chiffré rotation mensuelle, placé physiquement hors-ligne dans un autre lieu. Immunisé à 100 % aux attaques réseau.

Conclusion

PBS n'est pas un module optionnel : c'est la pièce qui rend la souveraineté infrastructure réellement comparable aux promesses des GAFAM. Sans lui, on a un cloud privé fragile. Avec lui, on a un cloud privé qui survit aux pannes, aux erreurs et aux attaques.

L'investissement en temps de mise en place est d'une journée pour un setup propre, et il est rentabilisé dès le premier incident — qui arrive toujours plus tôt qu'on ne le pense. Pour aller plus loin sur l'infrastructure sous-jacente, le guide LVM vers ZFS permet d'activer la réplication entre nœuds et de combiner ainsi la résilience par sauvegarde et la résilience par redondance.