Proxmox Backup Server : Stratégie de Sauvegarde et Restauration Sécurisée

1. Introduction : pourquoi PBS change la donne

Dans un contexte où les attaques par ransomware ciblent de plus en plus les infrastructures de virtualisation -- comme l'ont démontré les campagnes ESXiArgs et les variantes de LockBit adaptées aux hyperviseurs -- la stratégie de sauvegarde n'est plus un luxe mais une nécessité vitale. Les vulnérabilités des hyperviseurs VMware ESXi ont montré que le durcissement seul ne suffit pas : il faut un filet de sécurité capable de restaurer l'intégralité de l'infrastructure en quelques heures.

Proxmox Backup Server (PBS) est la réponse open source de Proxmox à cette problématique. Lancé en version 1.0 en novembre 2020, PBS a été conçu dès le départ avec la sécurité comme priorité. Contrairement aux solutions de sauvegarde traditionnelles qui ont ajouté le chiffrement et la déduplication comme des fonctionnalités secondaires, PBS intègre ces mécanismes au coeur de son architecture.

Les avantages fondamentaux de PBS par rapport aux alternatives commerciales :

Open source et auditable : code source disponible sur le dépôt Proxmox, permettant une revue de sécurité indépendante -- un atout majeur dans une solution qui gère vos données les plus critiques
Déduplication native au niveau des blocs : réduction drastique de l'espace de stockage avec un algorithme de chunking à taille variable
Chiffrement côté client AES-256-GCM : les données sont chiffrées avant de quitter le serveur source, garantissant la confidentialité même en cas de compromission du serveur de sauvegarde
Intégration native Proxmox VE : sauvegarde agentless des VMs QEMU et conteneurs LXC avec support des snapshots live
Licence gratuite : aucune licence par socket, par VM ou par To -- PBS est entièrement gratuit avec support communautaire

Comme nous l'avons analysé dans notre comparatif de sécurité Proxmox vs VMware vs Hyper-V, l'écosystème Proxmox offre un niveau de contrôle et de transparence que les solutions propriétaires ne peuvent égaler. PBS en est l'illustration parfaite.

Figure 1 -- Architecture Proxmox Backup Server avec stratégie 3-2-1-1

2. Architecture Proxmox Backup Server

2.1 Composants principaux

PBS repose sur une architecture client-serveur efficace, développée en Rust pour des performances maximales et une sécurité mémoire garantie par le compilateur. Les composants principaux sont :

proxmox-backup-server : le démon principal qui expose l'API REST sur le port 8007 en HTTPS. Il gère l'authentification, les datastores, les tâches de vérification et la garbage collection
proxmox-backup-client : l'outil en ligne de commande installé sur les nœuds Proxmox VE (ou tout serveur Linux). Il gère le chunking, la déduplication côté client, le chiffrement et le transfert des données
proxmox-backup-manager : l'outil d'administration pour la configuration des datastores, la gestion des utilisateurs, les tâches planifiées et le monitoring
Web UI : interface web complète basée sur ExtJS, accessible sur https://<pbs-host>:8007, offrant une vue d'ensemble des tâches, datastores et statistiques

2.2 Communication et protocole

Toute communication entre le client et le serveur se fait via HTTPS (TLS 1.3) sur le port 8007. Le protocole HTTP/2 est utilisé pour le multiplexage des flux, ce qui permet de transférer simultanément plusieurs chunks sans overhead de connexion TCP. L'authentification est gérée par des API tokens (recommandé pour l'automatisation) ou des comptes utilisateur PAM/PBS avec support TOTP pour le MFA.

Le flux de sauvegarde suit ce processus optimisé :

Snapshot : Proxmox VE crée un snapshot QEMU (pour les VMs) ou un snapshot ZFS/LVM (pour les conteneurs LXC)
Chunking : le client découpe les données en chunks de taille variable (64 KiB à 4 MiB) via l'algorithme de content-defined chunking (CDC)
Déduplication : chaque chunk est identifié par son hash SHA-256. Seuls les chunks nouveaux (non déjà présents sur le serveur) sont transférés
Chiffrement (optionnel) : si activé, chaque chunk est chiffré côté client avec AES-256-GCM avant le transfert
Transfert : les chunks sont envoyés via HTTPS/HTTP2 et écrits dans le datastore
Manifest : un fichier manifest signé répertorie tous les chunks composant cette sauvegarde, permettant une vérification d'intégrité

2.3 Prérequis matériels et dimensionnement

Le dimensionnement d'un serveur PBS dépend du volume de données à sauvegarder, du taux de changement quotidien (change rate) et de la profondeur de rétention souhaitée. Voici les recommandations basées sur notre expérience en production :

Composant	Minimum	Recommandé (prod)	Notes
CPU	4 cores	8-16 cores	SHA-NI accélère le hashing, AES-NI le chiffrement
RAM	4 GiB	16-32 GiB	~1 GiB par To de données dédupliquées pour le cache d'index
Stockage OS	32 GiB SSD	64 GiB SSD	ZFS mirror pour l'OS, RAID-1 minimum
Stockage Datastore	1 To HDD	RAID-Z2 / RAID-10	ZFS fortement recommandé pour l'intégrité (checksums)
Réseau	1 Gbps	10 Gbps	Réseau dédié backup recommandé

Attention au choix du filesystem

PBS est optimisé pour ZFS ou ext4. N'utilisez jamais XFS ou Btrfs comme filesystem pour un datastore PBS. ZFS est le choix idéal car il offre des checksums au niveau des blocs (protection contre le bit rot), la compression transparente (lz4/zstd), et les snapshots atomiques. Si vous utilisez ext4, vous perdez la protection contre la corruption silencieuse des données.

3. Datastores : organisation et dimensionnement

3.1 Qu'est-ce qu'un datastore PBS ?

Un datastore est le concept fondamental de PBS. C'est un répertoire sur le filesystem qui contient toutes les données sauvegardées, organisées en une structure optimisée pour la déduplication. Chaque datastore possède sa propre configuration de rétention, ses ACL (Access Control Lists) et son propre pool de chunks dédupliqués.

La structure interne d'un datastore est la suivante :

/mnt/datastore/production/
├── .chunks/                    # Pool de chunks dédupliqués
│   ├── 0000/                   # Répertoires de sharding (4096 dirs)
│   │   ├── chunk_hash1.blob    # Chunks individuels
│   │   └── chunk_hash2.blob
│   └── ffff/
├── ct/                         # Sauvegardes de conteneurs LXC
│   └── 100/
│       └── 2026-03-01T02:00:00Z/
│           ├── index.json.blob # Manifest signé
│           └── archive.pxar.didx  # Index de déduplication
├── vm/                         # Sauvegardes de VMs QEMU
│   └── 200/
│       └── 2026-03-01T02:00:00Z/
│           ├── index.json.blob
│           ├── qemu-server.conf.blob  # Config VM
│           └── drive-scsi0.img.fidx   # Index fixe (image disque)
└── host/                       # Sauvegardes de serveurs physiques
    └── webserver/
        └── 2026-03-01T02:00:00Z/

3.2 Stratégie multi-datastores

Pour une infrastructure de production, nous recommandons une séparation logique des datastores selon la criticité et le type de données :

Datastore "production" : sauvegardes quotidiennes des VMs et conteneurs critiques. Stockage sur disques rapides (SSD/NVMe) pour des restaurations rapides. Rétention courte (7-30 jours)
Datastore "archive" : sauvegardes hebdomadaires et mensuelles avec rétention longue (6-12 mois). Stockage sur HDD de grande capacité. Idéal pour la conformité réglementaire
Datastore "compliance" : pour les secteurs réglementés (santé, finance), un datastore dédié avec rétention de plusieurs années et chiffrement obligatoire

# Création d'un datastore avec PBS CLI
proxmox-backup-manager datastore create production \
    --path /mnt/zfs-pool/production \
    --comment "Sauvegardes quotidiennes production"

proxmox-backup-manager datastore create archive \
    --path /mnt/zfs-pool/archive \
    --comment "Archives hebdomadaires et mensuelles"

# Configuration de la rétention
proxmox-backup-manager datastore update production \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 3

proxmox-backup-manager datastore update archive \
    --keep-weekly 8 \
    --keep-monthly 12 \
    --keep-yearly 3

3.3 Contrôle d'accès granulaire (ACL)

PBS implémente un modèle de contrôle d'accès basé sur les rôles (RBAC) avec des ACL hiérarchiques. Ce modèle est essentiel pour la sécurité, car il permet de respecter le principe du moindre privilège -- un concept fondamental aussi en sécurité Active Directory. Les rôles prédéfinis sont :

Rôle	Permissions	Usage recommandé
Admin	Toutes les permissions	Administrateurs PBS uniquement (limiter au strict minimum)
DatastoreAdmin	Gérer un datastore spécifique	Responsables de la sauvegarde par périmètre
DatastoreBackup	Créer des sauvegardes et lire les siennes	Comptes de service Proxmox VE (proxmox-backup-client)
DatastoreReader	Lecture seule sur les sauvegardes	Monitoring, audit, restauration par un tiers
DatastoreAudit	Voir les logs et statistiques	Équipe de supervision (SOC)

# Créer un utilisateur de service pour chaque nœud PVE
proxmox-backup-manager user create pve-node1@pbs \
    --comment "Service account for PVE Node 1"

# Assigner le rôle DatastoreBackup uniquement sur le datastore production
proxmox-backup-manager acl update /datastore/production \
    --auth-id pve-node1@pbs \
    --role DatastoreBackup

# Créer un API token pour l'automatisation (évite de stocker le mot de passe)
proxmox-backup-manager user generate-token pve-node1@pbs backup-token

Séparation des privilèges anti-ransomware

Le compte utilisé par les nœuds Proxmox VE pour envoyer les sauvegardes (DatastoreBackup) ne doit jamais avoir le droit de supprimer des sauvegardes existantes. Ainsi, même si un nœud PVE est compromis par un ransomware, l'attaquant ne peut pas purger les sauvegardes sur PBS. Seul le rôle DatastoreAdmin ou Admin peut supprimer des snapshots, et ces comptes ne doivent jamais être configurés sur les nœuds PVE.

4. Déduplication et compression

4.1 Content-Defined Chunking (CDC)

La déduplication est la fonctionnalité phare de PBS. Contrairement aux solutions traditionnelles qui sauvegardent des fichiers complets à chaque itération, PBS utilise le Content-Defined Chunking (CDC), un algorithme de découpage intelligent qui divise les données en blocs de taille variable basés sur le contenu lui-même.

Le principe est le suivant : une fenêtre glissante analyse le flux de données et identifie les frontières de chunks en fonction d'un motif mathématique (Rabin fingerprint). Cela signifie que même si un fichier est déplacé dans l'arborescence ou qu'un bloc de données est inséré au milieu d'un fichier, les chunks adjacents restent identiques et ne sont pas re-transférés. C'est un avantage considérable par rapport au fixed-size chunking utilisé par certains concurrents.

Les paramètres de chunking dans PBS :

Taille minimale des chunks : 64 KiB -- empêche la fragmentation excessive
Taille moyenne des chunks : 256 KiB (par défaut) -- bon compromis entre déduplication et overhead d'index
Taille maximale des chunks : 4 MiB -- garantit qu'aucun chunk ne sera trop volumineux
Hash : SHA-256 pour l'identification unique de chaque chunk

4.2 Impact réel sur l'espace de stockage

Les résultats de la déduplication PBS sont spectaculaires en environnement réel. Voici un exemple concret issu d'un de nos déploiements en production :

Métrique	Sans déduplication	Avec PBS	Économie
30 VMs Linux (similaires)	3 To x 30 jours = 90 To	4.2 To total	95.3 %
15 VMs Windows Server	7.5 To x 30 jours = 225 To	18 To total	92 %
50 conteneurs LXC	500 GiB x 30 jours = 15 To	680 GiB total	95.5 %
Serveurs de bases de données	2 To x 30 jours = 60 To	8.5 To total	85.8 %

Les conteneurs LXC offrent les meilleurs ratios de déduplication car ils partagent souvent la même image de base (Debian, Ubuntu). Les VMs Windows ont un ratio légèrement inférieur en raison des mises à jour Windows Update qui modifient de larges portions du système de fichiers.

4.3 Compression : zstd comme standard

En complément de la déduplication, PBS applique une compression zstd (Zstandard) à chaque chunk individuellement. Développé par Facebook/Meta, zstd offre un excellent compromis entre ratio de compression et performance. PBS supporte également lzo et aucun compression, mais zstd est le choix par défaut et recommandé.

# Backup avec compression zstd (niveau 1, rapide)
proxmox-backup-client backup \
    root.pxar:/ \
    --repository pbs.example.com:production \
    --compress zstd

# Vérification de l'espace utilisé par le datastore
proxmox-backup-manager datastore status production

# Exemple de sortie :
# Datastore: production
# Total: 10.0 TiB
# Used: 4.2 TiB (42%)
# Deduplication Factor: 5.83x
# Chunk Count: 14,235,892
# Compression Ratio: 1.65x

4.4 Garbage Collection

Lorsque des snapshots sont supprimés (via la politique de rétention), les chunks qui ne sont plus référencés par aucun snapshot deviennent orphelins. La Garbage Collection (GC) est le processus qui identifie et supprime ces chunks orphelins pour récupérer l'espace disque.

La GC fonctionne en deux phases :

Phase 1 -- Mark : parcourt tous les index de tous les snapshots et marque chaque chunk référencé comme "actif". Cette phase est read-only et safe
Phase 2 -- Sweep : supprime tous les chunks non marqués. Un chunk n'est supprimé que s'il est orphelin depuis au moins 24 heures (safety delay) pour éviter les race conditions avec des sauvegardes en cours

# Lancer la GC manuellement
proxmox-backup-manager garbage-collection start production

# Planifier la GC (recommandé : quotidien à 3h du matin)
proxmox-backup-manager garbage-collection scheduling update production \
    --schedule "daily 03:00"

5. Chiffrement côté client

5.1 Pourquoi le chiffrement côté client est essentiel

Le chiffrement côté client (client-side encryption) est un pilier de sécurité souvent négligé dans les architectures de sauvegarde. Avec le chiffrement côté serveur, l'administrateur du serveur de backup a accès aux données en clair. En cas de compromission du serveur PBS (via une attaque d'infrastructure), toutes les données sauvegardées sont exposées.

Le chiffrement côté client de PBS résout ce problème fondamental : les données sont chiffrées avant de quitter le nœud source, et le serveur PBS ne possède jamais la clé de déchiffrement. Même un administrateur malveillant du serveur PBS ne peut pas lire les données.

5.2 Mécanisme cryptographique

PBS utilise un schéma de chiffrement hybride robuste :

Algorithme symétrique : AES-256-GCM (Galois/Counter Mode) -- chiffrement authentifié qui garantit à la fois la confidentialité et l'intégrité des données
Gestion des clés : une clé symétrique aléatoire est générée pour chaque session de sauvegarde. Cette clé est elle-même chiffrée avec une clé maître RSA (2048 bits minimum) ou une passphrase via PBKDF2
Granularité : chaque chunk est chiffré individuellement, ce qui permet de conserver les bénéfices de la déduplication -- deux chunks identiques chiffrés avec la même clé produiront le même ciphertext

# Générer une clé de chiffrement
proxmox-backup-client key create /etc/pbs-encryption-key.json
# Le système vous demande une passphrase pour protéger la clé

# Voir les informations de la clé
proxmox-backup-client key show /etc/pbs-encryption-key.json

# Backup chiffré
proxmox-backup-client backup \
    root.pxar:/ \
    --repository pbs.example.com:production \
    --keyfile /etc/pbs-encryption-key.json

# Créer un paper key (backup papier de la clé)
proxmox-backup-client key paperkey /etc/pbs-encryption-key.json \
    --output-format text > /secure-location/paperkey.txt

Perte de la clé = perte des données

Si vous perdez la clé de chiffrement et sa passphrase, les données sauvegardées sont définitivement irrécupérables. Il n'existe aucune porte dérobée, aucun mécanisme de récupération. C'est par conception. Vous devez impérativement sauvegarder la clé de chiffrement dans au moins 3 emplacements sécurisés distincts : un coffre-fort physique (paper key), un gestionnaire de secrets (HashiCorp Vault, KeePass), et un emplacement hors site. Traitez cette clé avec le même niveau de protection que vos secrets cloud les plus critiques.

5.3 Chiffrement et déduplication : le compromis

Une question fréquente : le chiffrement côté client détruit-il les bénéfices de la déduplication ? La réponse courte est : partiellement, mais c'est maîtrisé.

PBS utilise une approche ingénieuse : la déduplication est basée sur le hash SHA-256 du contenu en clair (avant chiffrement), et le chiffrement est déterministe pour une même clé. Cela signifie que deux chunks identiques chiffrés avec la même clé produiront le même résultat, et la déduplication fonctionnera normalement au sein d'un même utilisateur/clé. En revanche, la déduplication cross-utilisateur est perdue si les utilisateurs utilisent des clés différentes -- ce qui est le comportement attendu en termes de sécurité.

Figure 2 -- Flux de chiffrement côté client dans Proxmox Backup Server

6. Snapshots incrémentaux et politiques de rétention

6.1 Sauvegardes incrémentales nativement

Contrairement aux solutions qui distinguent sauvegardes complètes, incrémentales et différentielles, PBS simplifie radicalement le modèle : chaque sauvegarde est un snapshot complet d'un point de vue logique, mais incrémental d'un point de vue stockage. Grâce à la déduplication, seuls les chunks modifiés depuis la dernière sauvegarde sont réellement transférés et stockés. Le résultat est spectaculaire :

Pas de chaînes de dépendance : contrairement aux sauvegardes incrémentales classiques qui nécessitent toute la chaîne (full + inc1 + inc2 + ... + incN), chaque snapshot PBS est indépendant. La suppression d'un snapshot intermédiaire n'affecte pas les autres
Restauration rapide : pas besoin de reconstruire une chaîne d'incréments. Chaque snapshot peut être restauré directement
Deuxième sauvegarde quasi instantanée : la première sauvegarde d'une VM de 100 GiB peut prendre 30 minutes. La deuxième sauvegarde, si seulement 2 GiB ont changé, prendra moins de 2 minutes

6.2 Politiques de rétention (Prune)

Les politiques de rétention PBS sont exprimées via les paramètres keep-* qui définissent combien de snapshots conserver pour chaque période. PBS utilise un algorithme de prune sophistiqué qui sélectionne les meilleurs snapshots à conserver :

# Politique de rétention recommandée pour la production
# Conserve :
#   - 1 sauvegarde par heure des 24 dernières heures
#   - 1 sauvegarde par jour des 7 derniers jours
#   - 1 sauvegarde par semaine des 4 dernières semaines
#   - 1 sauvegarde par mois des 6 derniers mois
#   - 1 sauvegarde par an des 2 dernières années

proxmox-backup-manager prune-job create production-prune \
    --store production \
    --keep-hourly 24 \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 6 \
    --keep-yearly 2 \
    --schedule "daily 04:00"

# Simulation de prune (dry-run) pour vérifier avant exécution
proxmox-backup-client prune \
    --repository pbs.example.com:production \
    --keep-daily 7 --keep-weekly 4 --keep-monthly 6 \
    --dry-run

L'algorithme de prune fonctionne par catégorie de granularité. Pour keep-daily 7, PBS conserve le dernier snapshot de chaque jour pour les 7 derniers jours qui possèdent au moins un snapshot. Cela signifie que si aucune sauvegarde n'a été réalisée un dimanche, ce jour est simplement ignoré sans affecter le compteur.

Combiner rétention et vérification

Les snapshots ne valent rien s'ils sont corrompus. Configurez un job de vérification qui vérifie l'intégrité des chunks après chaque prune. PBS peut vérifier les checksums SHA-256 de chaque chunk et détecter toute corruption (bit rot, problème disque). Planifiez la vérification complète au moins une fois par semaine, et une vérification des sauvegardes récentes quotidiennement.

# Créer un job de vérification
proxmox-backup-manager verify-job create daily-verify \
    --store production \
    --schedule "daily 05:00" \
    --ignore-verified \
    --outdated-after 7d

# Vérification manuelle d'un snapshot spécifique
proxmox-backup-client verify \
    --repository pbs.example.com:production \
    vm/200/2026-03-01T02:00:00Z

7. Synchronisation remote et réplication

7.1 Architecture de réplication PBS-to-PBS

La stratégie 3-2-1 exige au minimum une copie hors site. PBS intègre nativement la synchronisation remote, permettant de répliquer automatiquement les sauvegardes vers un second serveur PBS distant. Ce mécanisme est optimisé pour le WAN : seuls les chunks manquants sur le serveur distant sont transférés, grâce à la déduplication cross-serveur.

Deux modes de synchronisation sont disponibles :

Pull mode : le serveur PBS distant tire les sauvegardes depuis le serveur primaire. C'est le mode recommandé car il permet au serveur distant de contrôler le processus et de ne pas exposer d'accès en écriture au serveur primaire
Push mode : le serveur primaire pousse les sauvegardes vers le serveur distant. Plus simple à configurer mais expose un accès en écriture au serveur distant depuis le réseau primaire

# Configuration du remote sur le PBS primaire
proxmox-backup-manager remote create offsite-pbs \
    --host pbs-offsite.example.com \
    --port 8007 \
    --auth-id sync-user@pbs \
    --fingerprint "XX:XX:XX:..."

# Créer un job de synchronisation (pull depuis le remote)
proxmox-backup-manager sync-job create offsite-sync \
    --store production \
    --remote offsite-pbs \
    --remote-store production-mirror \
    --schedule "daily 06:00" \
    --remove-vanished true

# Surveiller le statut de synchronisation
proxmox-backup-manager sync-job status offsite-sync

7.2 Optimisation bande passante WAN

Pour les liaisons WAN à bande passante limitée, PBS offre plusieurs mécanismes d'optimisation :

Déduplication cross-site : seuls les chunks réellement nouveaux sont transférés. Pour un change rate quotidien de 3 %, un datastore de 10 To ne génère que ~300 GiB de transfert par jour
Compression réseau : la compression zstd est appliquée avant le transfert, réduisant encore le volume
Rate limiting : possibilité de limiter la bande passante utilisée par la synchronisation pour ne pas impacter les applications métier
Planification intelligente : programmer la synchronisation en heures creuses (nuit, week-end)

Cette architecture de réplication est un composant essentiel d'un Plan de Reprise d'Activité (PRA). En cas de sinistre sur le site primaire (incendie, inondation, ransomware), le serveur PBS distant contient une copie complète des sauvegardes, prête à être restaurée sur un nouveau cluster Proxmox VE. Le RTO (Recovery Time Objective) dépend principalement de la bande passante disponible pour le rapatriement des données et du temps de restauration des VMs.

8. Restauration granulaire

8.1 Types de restauration supportés

PBS offre une flexibilité de restauration qui dépasse largement le simple "restore full VM". La granularité de restauration est un facteur décisif en situation de crise, car dans 80 % des cas, il n'est pas nécessaire de restaurer une VM entière -- un fichier supprimé, une base de données corrompue ou un répertoire de configuration suffit.

Restauration complète de VM : restaurer l'intégralité d'une VM QEMU (disques + configuration). Disponible directement depuis l'interface Proxmox VE
Restauration complète de conteneur : restaurer un conteneur LXC avec toute son arborescence
Restauration de fichiers individuels : naviguer dans l'arborescence d'un snapshot et extraire des fichiers ou répertoires spécifiques sans restaurer toute la VM
Restauration de disques individuels : pour les VMs multi-disques, restaurer uniquement le disque concerné
Live-restore : démarrer une VM avant que la restauration complète ne soit terminée -- les données sont streamées à la demande depuis PBS

8.2 Restauration de fichiers via le navigateur web

L'une des fonctionnalités les plus pratiques de PBS est le File Restore via l'interface web de Proxmox VE. Sans avoir à restaurer la VM entière, l'administrateur peut parcourir le système de fichiers du snapshot directement dans le navigateur :

Depuis l'interface PVE, sélectionnez la VM/CT concerné(e)
Allez dans l'onglet Backup
Sélectionnez le snapshot souhaité et cliquez sur File Restore
PBS lance un micro-conteneur temporaire qui monte le snapshot en lecture seule
Naviguez dans l'arborescence et téléchargez les fichiers nécessaires

# Restauration de fichiers via CLI
# Lister le contenu d'un snapshot
proxmox-backup-client catalog dump \
    --repository pbs.example.com:production \
    vm/200/2026-03-01T02:00:00Z \
    --path /etc/

# Extraire un fichier spécifique
proxmox-backup-client restore \
    --repository pbs.example.com:production \
    vm/200/2026-03-01T02:00:00Z \
    drive-scsi0.img.fidx \
    --target /tmp/restore/ \
    --include /etc/nginx/nginx.conf

# Restauration complète d'une VM via CLI
qmrestore pbs:production:vm/200/2026-03-01T02:00:00Z 200 \
    --storage local-zfs

# Live-restore (la VM démarre immédiatement)
qmrestore pbs:production:vm/200/2026-03-01T02:00:00Z 200 \
    --storage local-zfs \
    --live-restore

8.3 Tests de restauration : la pratique oubliée

Une sauvegarde qui n'a jamais été testée n'est pas une sauvegarde, c'est un espoir. Les tests de restauration réguliers sont le seul moyen de garantir que votre stratégie fonctionne réellement. Nous recommandons de formaliser un calendrier de tests de restauration :

Type de test	Fréquence	Description
Restauration de fichiers	Hebdomadaire	Restaurer 5-10 fichiers aléatoires et vérifier leur intégrité
Restauration de VM	Mensuelle	Restaurer une VM critique sur un réseau isolé, vérifier le démarrage
DR complet	Trimestrielle	Simuler un sinistre complet : restaurer depuis le site distant sur un cluster de secours
Test de chiffrement	Semestrielle	Vérifier que les clés de chiffrement sont valides et accessibles

9. Intégration Proxmox VE

9.1 Configuration du storage PBS dans Proxmox VE

L'intégration entre Proxmox VE et PBS est native et se configure en quelques minutes. PBS apparaît comme un storage de type "pbs" dans la configuration PVE, au même titre qu'un NFS, un Ceph ou un stockage local.

# Ajouter PBS comme storage dans Proxmox VE
# Via pvesm (PVE Storage Manager)
pvesm add pbs pbs-production \
    --server pbs.example.com \
    --port 8007 \
    --datastore production \
    --username backup-user@pbs!backup-token \
    --password "TOKEN_SECRET" \
    --fingerprint "XX:XX:XX:..." \
    --encryption-key /etc/pbs-encryption-key.json

# Fichier de configuration résultant : /etc/pve/storage.cfg
# pbs: pbs-production
#     datastore production
#     server pbs.example.com
#     port 8007
#     username backup-user@pbs!backup-token
#     encryption-key /etc/pbs-encryption-key.json
#     fingerprint XX:XX:XX:...
#     content backup

9.2 Jobs de sauvegarde automatisés

Proxmox VE permet de configurer des backup jobs qui automatisent les sauvegardes à intervalles réguliers. Ces jobs sont configurables par nœud, par pool de ressources ou par VM/CT individuel.

# Créer un job de sauvegarde via l'interface PVE
# Ou via CLI sur le nœud PVE :
pvesh create /cluster/backup \
    --id daily-production \
    --schedule "02:00" \
    --storage pbs-production \
    --mode snapshot \
    --compress zstd \
    --pool production-vms \
    --mailnotification always \
    --mailto admin@example.com \
    --notes-template "{{guestname}} - Auto backup"

# Vérifier les jobs configurés
pvesh get /cluster/backup

# Lancer un job manuellement
pvesh create /cluster/backup/{id}/run

Les modes de sauvegarde disponibles pour les VMs QEMU sont :

Snapshot (recommandé) : utilise le dirty bitmap QEMU pour capturer l'état du disque sans interrompre la VM. Cohérence garantie par les guest agents (QEMU Guest Agent pour Linux, VSS pour Windows)
Suspend : suspend la VM en RAM pendant la copie du disque. Downtime minimal mais existant. Utile pour les VMs sans guest agent
Stop : arrête la VM pendant la sauvegarde. Garantit une cohérence parfaite mais provoque un downtime. Réservé aux VMs non critiques ou aux fenêtres de maintenance

QEMU Guest Agent : indispensable

Installez et activez le QEMU Guest Agent sur toutes les VMs Linux et Windows. Sans le guest agent, les sauvegardes en mode snapshot ne peuvent pas faire de filesystem freeze (fsfreeze), ce qui peut entraîner des incohérences dans les bases de données ou les fichiers ouverts. Pour Windows, le guest agent déclenche le Volume Shadow Copy Service (VSS), garantissant la cohérence des applications compatibles (SQL Server, Exchange, etc.). C'est un point souvent négligé qui peut rendre une restauration inutile si les données sont inconsistantes.

10. Protection anti-ransomware et immutabilité

10.1 Le ransomware cible les sauvegardes

Les groupes de ransomware modernes ont compris que la sauvegarde est le dernier rempart des organisations. Avant de chiffrer les systèmes de production, les attaquants sophistiqués effectuent une reconnaissance des solutions de backup et tentent de les neutraliser. Les tactiques observées incluent :

Suppression des sauvegardes : utilisation des credentials volés pour se connecter au serveur de backup et purger les snapshots
Chiffrement du serveur de backup : le serveur PBS lui-même est chiffré par le ransomware
Corruption silencieuse : modification subtile des sauvegardes pour les rendre inutilisables, découvert seulement au moment de la restauration
Exfiltration préalable : les données sont exfiltrées avant le chiffrement pour du double extortion

La protection anti-ransomware des sauvegardes repose sur une défense en profondeur que PBS permet d'implémenter à plusieurs niveaux. Ce concept rejoint les principes fondamentaux du respect des normes de conformité en cybersécurité.

10.2 Stratégies d'immutabilité avec PBS

Bien que PBS n'offre pas encore de fonction d'immutabilité native de type WORM (Write Once Read Many) intégrée à l'interface, plusieurs stratégies peuvent être combinées pour atteindre un niveau de protection équivalent :

Stratégie 1 : Séparation des privilèges stricte

Comme détaillé en section 3.3, le compte de sauvegarde PVE (DatastoreBackup) ne doit jamais pouvoir supprimer des snapshots. Cette séparation est la première ligne de défense : même avec un accès root sur un nœud PVE compromis, l'attaquant ne peut que créer de nouvelles sauvegardes, pas détruire les existantes.

Stratégie 2 : PBS sur un réseau isolé

Le serveur PBS ne doit pas être sur le même réseau que les postes de travail ou les serveurs applicatifs. Idéalement, PBS est sur un VLAN de sauvegarde dédié avec des règles de firewall restrictives :

# Règles iptables / nftables sur le serveur PBS
# N'autoriser que les nœuds PVE connus sur le port 8007
nft add rule inet filter input ip saddr { 10.0.1.10, 10.0.1.11, 10.0.1.12 } tcp dport 8007 accept
nft add rule inet filter input ip saddr 10.0.2.0/24 tcp dport 8007 drop
nft add rule inet filter input tcp dport 8007 drop

# Accès admin PBS uniquement depuis un bastion / jump host
nft add rule inet filter input ip saddr 10.0.100.5 tcp dport { 8007, 22 } accept

Stratégie 3 : Copie air-gapped

La protection ultime contre le ransomware est la copie air-gapped : un support physiquement déconnecté du réseau. Avec PBS, cela peut prendre plusieurs formes :

Disques USB rotatifs : brancher un disque USB, déclencher une synchronisation, débrancher et stocker dans un coffre-fort. Rotation sur 5-7 jours
NAS hors réseau : un NAS connecté uniquement pendant la fenêtre de synchronisation, puis éteint et déconnecté
Tape LTO : exportation des sauvegardes vers des bandes LTO via proxmox-tape-backup (intégré depuis PBS 2.x). Les bandes sont stockées hors site

Stratégie 4 : Snapshots ZFS immutables

Si le datastore PBS est hébergé sur ZFS, les snapshots ZFS offrent une couche d'immutabilité au niveau du filesystem. Un snapshot ZFS est read-only par nature et ne peut être supprimé que par l'administrateur root du serveur PBS :

# Créer des snapshots ZFS automatiques du datastore
# Script cron sur le serveur PBS
#!/bin/bash
DATASET="zfs-pool/production"
DATE=$(date +%Y-%m-%d_%H%M)
RETENTION_DAYS=30

# Créer le snapshot
zfs snapshot ${DATASET}@backup-${DATE}

# Supprimer les snapshots de plus de 30 jours
zfs list -t snapshot -o name -H ${DATASET} | while read snap; do
    SNAP_DATE=$(echo $snap | grep -oP '\d{4}-\d{2}-\d{2}')
    if [ $(( ($(date +%s) - $(date -d "$SNAP_DATE" +%s)) / 86400 )) -gt $RETENTION_DAYS ]; then
        zfs destroy $snap
    fi
done

Figure 3 -- Défense en profondeur anti-ransomware pour Proxmox Backup Server

10.3 Durcissement du serveur PBS

Le serveur PBS lui-même doit être durci comme n'importe quelle infrastructure critique. Les mesures essentielles rejoignent les bonnes pratiques de durcissement des hyperviseurs :

Accès SSH restreint : clés SSH uniquement, port non standard, fail2ban activé, accès uniquement depuis le bastion
Mises à jour automatiques de sécurité : unattended-upgrades pour les patches de sécurité Debian
Pas de services inutiles : PBS doit être une appliance dédiée, sans services web, sans agents tiers non nécessaires
Monitoring des accès : centralisation des logs PBS vers un SIEM externe pour détecter toute activité suspecte
MFA sur l'interface web : activation du TOTP (Google Authenticator / FreeOTP) pour tous les comptes administrateur

11. Monitoring et alerting

11.1 Notifications intégrées

PBS intègre un système de notification configurable qui peut alerter par email en cas d'événements importants. Les notifications sont essentielles pour détecter rapidement les problèmes avant qu'ils ne deviennent critiques :

# Configuration des notifications email
# /etc/proxmox-backup/notifications.cfg
sendmail: default
    mailto admin@example.com
    mailto-user root@pam
    from-address pbs@example.com
    comment "Notifications PBS"

# Types de notifications :
# - Sauvegarde échouée
# - Garbage Collection terminée (avec statistiques)
# - Vérification échouée (chunks corrompus)
# - Synchronisation remote échouée
# - Espace disque faible

11.2 Métriques et intégration Prometheus/Grafana

Pour un monitoring avancé, PBS expose des métriques via son API REST, ce qui permet l'intégration avec des solutions comme Prometheus + Grafana. Les métriques clés à surveiller pour un centre opérationnel de sécurité (SOC) :

Taux de réussite des sauvegardes : objectif 100 %. Toute sauvegarde échouée doit générer une alerte immédiate
Durée des sauvegardes : une augmentation soudaine peut indiquer un problème de performance réseau ou disque
Taux de déduplication : une baisse soudaine peut indiquer un changement massif (mise à jour OS, migration, ou chiffrement par ransomware)
Espace disque : alerte à 80 %, critique à 90 %. Prévoir la croissance sur 6 mois minimum
Intégrité des chunks : résultats des jobs de vérification. Zéro erreur est la seule valeur acceptable
Statut de la synchronisation remote : la copie offsite doit être à jour (delta < 24h)

# Récupérer les métriques via l'API PBS
# Status du datastore
curl -s -k -H "Authorization: PBSAPIToken=user@pbs!token:SECRET" \
    "https://pbs.example.com:8007/api2/json/admin/datastore/production/status" | jq

# Liste des tâches récentes
curl -s -k -H "Authorization: PBSAPIToken=user@pbs!token:SECRET" \
    "https://pbs.example.com:8007/api2/json/nodes/localhost/tasks?limit=50" | jq

# Métriques de déduplication
curl -s -k -H "Authorization: PBSAPIToken=user@pbs!token:SECRET" \
    "https://pbs.example.com:8007/api2/json/admin/datastore/production/status" | \
    jq '.data | {total: .total, used: .used, avail: .avail, dedup: .["dedup-factor"]}'