Mode opératoire — Sauvegardes incrémentales avec Proxmox Backup Server (PBS)

Document autonome. Partie théorique, puis mise en œuvre telle qu’elle a été réalisée et vérifiée le 15/10/2026 sur l’hyperviseur Proxmox de l’école (phase 13 du suivi, tâche 13.9). La méthode vaut pour toute infrastructure Proxmox VE qui veut des sauvegardes incrémentales et dédupliquées. Il prend la suite de MO-11-Sauvegarde-Proxmox.md (sauvegarde vzdump vers un NAS), dont il reprend les principes (mode snapshot, sauvegarde par pool, test de restauration). Le contexte de l’infrastructure est dans Documentation-pfSense.md (étape 44) ; la règle de pare-feu est dans Matrice-de-flux.md (§4.5 et §5).

Valeurs masquées. Aucun mot de passe ni secret de jeton n’apparaît ici.

Dernière mise à jour : 06/11/2026 — ajout du §13.4.7 (restaurer depuis la copie S3) ; 05/11/2026 — ajout du §13.4 (copie hors site sur un datastore S3) ; 27/10/2026 — ajout du §13.1 (notifications par mail), du §13.2 (gel des systèmes de fichiers) et du §13.3 (machines Windows)

Sommaire

1 · Le besoin : pourquoi quitter les copies complètes

La première solution (MO-11) envoie chaque nuit une archive complète de chaque VM sur le NAS de l’école. Mesures relevées :

Chaque nuit recopie donc ce qui n’a pas changé. Proxmox Backup Server ne stocke que ce qui est nouveau.

2 · Théorie : blocs, déduplication, incrémental, rétention

2.1 Les blocs et la déduplication

PBS découpe chaque disque en blocs (chunks) de 4 Mio et les range par leur empreinte (un calcul qui donne le même résultat pour un contenu identique). Un bloc déjà présent dans le stockage n’est jamais réécrit : la sauvegarde se contente d’y faire référence.

Conséquences :

• deux sauvegardes d’une même VM partagent tous leurs blocs inchangés ;
• deux VM clonées du même modèle partagent leurs blocs communs ;
• les zones vides d’un disque se résument à un seul bloc « zéro ».

Chaque sauvegarde reste complète : on peut restaurer n’importe laquelle sans « rejouer » les précédentes. Ce n’est pas un enchaînement de différences fragile, c’est un index qui pointe vers des blocs partagés.

2.2 L’incrémental rapide : la carte des blocs modifiés

Pendant que la VM tourne, Proxmox note les zones du disque modifiées depuis la dernière sauvegarde (dirty bitmap). La sauvegarde suivante ne lit que ces zones.

Cette carte est perdue quand la VM s’arrête (arrêt, redémarrage, migration). La sauvegarde suivante relit alors tout le disque : plus longue, mais elle n’écrit toujours que les blocs nouveaux.

2.3 Le vocabulaire de PBS

Prune ne libère pas d’espace, la GC si. Et la GC ne supprime un bloc que s’il n’a pas servi depuis plus de 24 h 05 : l’espace occupé baisse donc avec un jour de décalage.

2.4 Les droits : qui envoie, qui supprime

Proxmox se connecte à PBS avec un jeton d’API (un identifiant + un secret). On lui donne le rôle DatastoreBackup : il peut créer des sauvegardes et lire les siennes, mais pas en supprimer.

Conséquence voulue : si l’hyperviseur était compromis, l’attaquant ne pourrait pas effacer l’historique des sauvegardes. La rétention (la suppression des anciennes) est donc confiée à PBS lui-même (§12).

2.5 Le chiffrement côté client

PBS sait chiffrer les sauvegardes avant leur envoi, avec une clé gardée par le client. Non retenu ici (décision du 15/10) : sans la clé, aucune restauration n’est possible, et la perte de la clé rendrait toutes les sauvegardes inutilisables.

3 · L’architecture retenue

   Réseau de l'école (10.1.0.0/16)                        Lab (derrière pfSense)
  ┌────────────────────────────┐                   ┌──────────────────────────────────┐
  │ Hyperviseur pve-01         │   TCP 8007        │ pfSense                          │
  │ 10.1.0.253                 │ ────────────────► │ WAN 10.1.0.197                   │
  │ (lance les sauvegardes)    │  vers 10.1.0.197  │   redirection 8007 ──┐           │
  └────────────────────────────┘                   │                      ▼           │
                                                   │ VLAN 30 ADM   srv-pbs 10.0.30.13 │
                                                   │                PBS 4.2.8         │
                                                   └──────────────────┬───────────────┘
                                                                      │ disque de données
                                                                      ▼ 500 Go (ext4)
                                                              NAS de l'école « Syno »

4 · Créer la VM

Proxmox → Create VM, avec l’ISO proxmox-backup-server_4.2-1.iso (empreinte SHA-256 vérifiée contre celle publiée par l’éditeur avant usage).

« Backup » décoché sur le disque de données. Sans cette case, une sauvegarde de la VM PBS recopierait le datastore dans lui-même.

La VM PBS ne doit pas être dans le pool que la tâche sauvegarde. Laissée dans le pool, elle a fait échouer la tâche de la première nuit : backup connect failed: command error: http upgrade request timed out (cause probable : la tâche veut se connecter à un serveur PBS qui se trouve dans la machine qu’elle est en train de geler). Les 11 autres VM étaient sauvegardées, mais la tâche se terminait en TASK ERROR : une erreur permanente masque les vraies pannes. Parade retenue : retirer la VM du pool (Datacenter → Permissions → Pools → pool → Members → VM → Remove). La sauvegarde de la VM PBS elle-même est d’ailleurs peu utile : son disque de données est exclu, et on la réinstalle en quelques minutes en rattachant le datastore (non testé).

La documentation de PBS recommande 4 Gio de RAM + 1 Gio par To stocké : le minimum de 2 Gio est en dessous, choix assumé (hyperviseur partagé, RAM limitée).

5 · Installer PBS

Démarrer la VM sur l’ISO et suivre l’installateur graphique.

Avant de valider l’adresse : ping 10.0.30.13 depuis une machine du lab ne doit pas répondre (adresse libre).

Après le redémarrage, retirer l’ISO du lecteur (Hardware → CD/DVD → Do not use any media).

Validation : la console affiche l’adresse https://10.0.30.13:8007/.

6 · Préparer le système

Connexion en SSH (le lab est joignable par Tailscale depuis le poste de travail).

6.1 Les dépôts de mises à jour

Sans abonnement, le dépôt « entreprise » configuré par défaut refuse l’accès. On le désactive et on active le dépôt communautaire :

apt update
apt full-upgrade

apt update se termine sans erreur 401. La mise à jour installe un nouveau noyau : un redémarrage est nécessaire (fait au §6.2).

6.2 L’agent invité

apt install qemu-guest-agent

Le message static unit, not starting it est normal. Dans Proxmox : VM → Options → QEMU Guest Agent → Enabled, puis Shutdown et Start de la VM (un simple redémarrage depuis l’intérieur ne suffit pas à brancher le canal).

systemctl status qemu-guest-agent → active (running) ; dans Proxmox, le résumé de la VM affiche son adresse IP.

6.3 Un compte d’administration et la fermeture de root en SSH

1. Créer un compte nominatif, l’ajouter au groupe sudo, y déposer sa clé publique SSH (méthode : MO-4).
2. Vérifier la connexion par clé avec ce compte, dans une nouvelle session (l’appartenance au groupe sudo n’est prise en compte qu’à la connexion suivante).
3. Seulement ensuite, interdire root en SSH :

echo "PermitRootLogin no" | sudo tee /etc/ssh/sshd_config.d/00-no-root.conf
sudo sshd -t && sudo systemctl reload ssh
sudo sshd -T | grep permitrootlogin      # attendu : permitrootlogin no

Pourquoi 00- dans le nom : pour une option donnée, SSH garde la première valeur lue ; les fichiers du dossier sont lus par ordre alphabétique. 00- passe avant tout autre fichier qui dirait le contraire.

ssh [email protected] → Permission denied.

L’interface web, elle, reste accessible avec root@pam : c’est l’accès d’administration de PBS.

7 · Le datastore

Interface web https://10.0.30.13:8007, compte root@pam.

Administration → Storage / Disks : le disque de 500 Go apparaît en unused.

Storage / Disks → Directory → Create: Directory

Validation : sio2527-lab apparaît dans le menu de gauche, sous Datastore, avec ≈ 500 Go disponibles.

8 · Un compte et un jeton dédiés, avec le minimum de droits

Configuration → Access Control.

Les droits sur les deux. Avec la privilege separation, le jeton n’a que l’intersection de ses droits et de ceux de son utilisateur. Un droit posé sur un seul des deux donne un refus d’accès.

Le secret du jeton ne se réaffiche jamais. Perdu, il faut le régénérer (Regenerate Secret) et le ressaisir dans Proxmox.

L’empreinte du certificat : Dashboard → Show Fingerprint. PBS utilise un certificat auto-signé ; Proxmox vérifiera cette empreinte à chaque connexion. Elle n’est pas secrète, on la copie pour le §10.

9 · Ouvrir le chemin dans pfSense

L’hyperviseur (10.1.0.253) est côté WAN : il doit viser l’adresse WAN de pfSense, qui redirige vers PBS.

9.1 Trois alias (un alias = un usage)

9.2 La redirection de port

Firewall → NAT → Port Forward → Add

Save puis Apply Changes.

La source restreinte est l’essentiel. Sans elle, toute machine du réseau de l’école pourrait joindre l’interface de PBS. C’est la seule règle entrante du WAN : elle se justifie ligne par ligne.

Validation, depuis le shell de l’hyperviseur :

curl -k -s -o /dev/null -w "%{http_code}\n" https://10.1.0.197:8007/

Résultat obtenu : 200.

10 · Déclarer PBS dans Proxmox, puis une première sauvegarde

10.1 Le stockage

Proxmox → Datacenter → Storage → Add → Proxmox Backup Server

Validation : pbs-lab-axel apparaît dans l’arbre, statut actif, avec la place du datastore.

10.2 Première sauvegarde d’une VM, puis une seconde

VM → Backup → Backup now, stockage pbs-lab-axel, mode Snapshot. Puis, aussitôt après, une deuxième fois.

Pour comparaison, la même VM en archive complète vzdump vers le NAS : 10 min 58 s.

La ligne skip unused drive … (not included into backup) concerne un ancien disque détaché : il n’est pas sauvegardé, c’est voulu.

11 · Le test de restauration

Stockage pbs-lab-axel → Backups → la sauvegarde → Restore.

Le piège : « restore image complete » n’est pas la fin. Après cette ligne, la tâche attend que le stockage ait réellement écrit les données sur les disques, puis écrit la configuration de la VM. Sur des disques mécaniques chargés, cela peut durer plusieurs minutes sans aucune ligne nouvelle. Ne pas cliquer sur « Stop » : la VM resterait verrouillée (lock: create), incomplète, et serait à supprimer (§14). Attendre TASK OK.

Ensuite, comme au MO-11 §5.4 et §6 : démarrer la copie réseau débranché, vérifier qu’elle est exploitable, puis la supprimer (More → Remove, disques compris).

12 · La rétention côté PBS, et la tâche planifiée

12.1 La rétention (Prune)

Datastore sio2527-lab → Prune & GC Jobs → Prune Jobs → Add

Résultat : 7 jours maximum, une sauvegarde par jour (la plus récente de chaque jour).

Prévisualiser sans rien supprimer : Content → le groupe d’une VM → icône ciseaux (Prune group). Saisir Keep Daily = 7 : la colonne de droite indique, pour chaque sauvegarde, keep ou remove. Champs vides, tout s’affiche keep-all. Fermer la fenêtre par la croix : le bouton Prune supprime pour de vrai.

12.2 Garbage Collection et vérification

12.3 La tâche planifiée dans Proxmox

Datacenter → Backup → Add (ou Edit de la tâche existante) :

78-proxmox-tache-sauvegarde-pbs.png — la colonne Retention affiche keep-all=1.

« Keep all backups » côté Proxmox. La rétention est faite par PBS (§12.1). Si Proxmox gardait sa propre rétention, il essaierait de supprimer d’anciennes sauvegardes avec un jeton qui n’en a pas le droit (§2.4) : la tâche se terminerait en erreur.

La chaîne d’une nuit :

13 · Contrôler chaque matin

La première nuit après la bascule est plus longue : chaque VM est lue en entier (aucune carte des blocs modifiés n’existe encore vers ce stockage). Relevé du 16/10 : 11 VM sauvegardées en 36 min (02:00 → 02:36), contre 2 h 25 en archives complètes ; la plus longue est le poste Windows (13 min, disque de 100 Gio). Les suivantes ne lisent que les changements, sauf pour les VM redémarrées entre-temps (§2.2) : la VM web, qui n’avait pas redémarré, n’a pris que 25 s (364 Mio lus).

Espace relevé après cette première nuit (Datastore → Summary) : 75,95 Go sur 500 (15 %), facteur de déduplication 11,75 pour 795 Gio de disques provisionnés. L’indication « Estimated Full » de PBS prolonge la croissance de la première copie complète : elle est trompeuse les premiers jours ; l’augmentation quotidienne réelle se lit après 2 ou 3 nuits.

Deuxième nuit (17/10) : 11 VM en 16 min 37 s, toutes incrémentales : ≈ 31 Gio modifiés au total, dont 23,2 Gio pour le poste Windows (les autres machines : moins de 0,6 Gio chacune, 5,1 Gio pour le contrôleur de domaine) ; le datastore a pris +29 Go. Un poste Windows peut donc à lui seul dominer la croissance : c’est la machine à surveiller. Premier Verify (samedi) réussi en 54 min 52 s.

Troisième nuit (18/10) : 11 min 16 s, TASK OK, ≈ 17,9 Gio modifiés au total (poste Windows : 9,5 Gio après 23,2 la veille ; contrôleur de domaine : 5,7 Gio ; les 9 autres : moins de 0,9 Gio chacune). La durée et le volume baissent : la première nuit (copie complète) est passée.

Une VM arrêtée est sauvegardée quand même (20/10) : le journal indique status = stopped puis backup mode: stop ; Proxmox démarre une machine virtuelle temporaire pour lire le disque. La carte des blocs modifiés est recréée (created new), donc le disque est relu en entier (4 à 8 min pour 64 et 100 Gio), mais ce qui est envoyé reste minime : 0 Gio pour le contrôleur de domaine (arrêté depuis la veille) et 1,8 Gio pour le poste Windows. Une machine éteinte n’écrit plus : la croissance observée vient bien de l’intérieur des machines Windows. Les deux nouvelles VM de la supervision (139 et 140, dans le pool) ont été prises automatiquement : 32 Gio lus en moins d’une minute chacune, disques à 91-92 % vides.

13.1 Être prévenu par mail

Le besoin : ne pas avoir à ouvrir PBS chaque matin pour savoir si le nettoyage et la vérification ont tourné.

Où configurer : sur PBS, pas sur l’hyperviseur. Dans ce lab, l’hyperviseur est partagé avec d’autres élèves : on n’y dépose ni adresse mail ni webhook. Les sauvegardes elles-mêmes sont lancées par l’hyperviseur : PBS ne prévient pas pour elles (leur suivi passera par une alerte de supervision, « VM non sauvegardée depuis 26 h »).

Théorie en deux mots : PBS (depuis la version 3.2) sépare les cibles (targets : où envoyer) des règles de tri (matchers : quoi envoyer, et vers quelle cible). Par défaut, la cible mail-to-root confie le message au serveur de messagerie local, qui essaie de le livrer lui-même sur le port 25 : presque partout, ce port est bloqué en sortie. On passe donc par un relais SMTP authentifié.

1. La cible. Configuration → Notifications → Notification Targets → Add → SMTP :

Bouton Test → un mail « Test notification » arrive.

587 = STARTTLS, 465 = TLS direct. Le mélange donne SSL routines:…:wrong version number (incident H-43).

2. La règle de tri. Notification Matchers → Add : nom vers-assistant, Match all, cible mail-assistant.

3. Couper l’ancienne voie. Dans Notification Matchers, double-clic sur default-matcher → décocher Enable → OK. La colonne Enable affiche alors un tiret, et Origin « Built-In (modified) ». On ne supprime rien : on désactive.

Les messages envoyés avant ce réglage par l’ancienne voie restent en file d’attente sur PBS et reviennent en erreur (« Undelivered Mail Returned to Sender ») 5 jours plus tard, un par message : c’est normal et ça s’arrête seul (incident H-44).

Validation — le lendemain matin, dans la boîte de destination :

« Pruning datastore ‘sio2527-lab’ successful » (vers 05:00) et « Garbage Collect Datastore ‘sio2527-lab’ successful » (vers 06:00, avec la ligne On-Disk usage : la place occupée) ; le samedi, « Verify Datastore … successful ». Les messages de sécurité du système (par exemple un sudo refusé) arrivent aussi par cette voie.

13.2 Le gel des systèmes de fichiers

Avant de sauvegarder une VM allumée, Proxmox peut demander à son agent invité de geler les écritures, pour une copie aussi propre qu’après un arrêt (Options → QEMU Guest Agent → Freeze/thaw guest filesystems on backup). Sous Windows, ce gel passe par un instantané VSS, qui met en pause les services (base de l’annuaire…).

Un agent « Running » dans la VM peut être figé : on le vérifie depuis l’hyperviseur avec qm guest cmd <id> ping (aucune sortie = il répond).

13.3 Les machines Windows : le poste à surveiller

Les VM Windows modifient chaque jour bien plus de blocs que les Linux. Relevés du lab (blocs de 4 Mio modifiés en 24 h) :

Les réglages qui comptent (Hardware → disque) : SSD emulation (sinon Windows croit avoir un disque dur et le défragmente chaque semaine, ce qui « modifie » des dizaines de Gio) et Discard (l’espace libéré est rendu au stockage). Ils ne s’appliquent qu’après un arrêt puis un démarrage depuis Proxmox. Le reste (antivirus, journaux, et l’effet des blocs : une petite écriture salit un bloc entier de 4 Mio) est un fond normal, absorbé par la déduplication. Détail du diagnostic : Documentation-pfSense.md, étape 49.1.

Après tout redémarrage complet d’une VM (arrêt et démarrage de son processus), la carte des blocs modifiés est perdue : la sauvegarde suivante relit tout le disque (dirty-bitmap status: created new), mais n’envoie presque rien de plus. Pour mesurer ce qu’une VM écrit, il faut une nuit sans redémarrage la veille.

13.4 Une copie hors site : un datastore S3 sur un autre site (règle 3-2-1)

Contexte — Tout est sauvegardé sur un PBS, dans le même bâtiment que les VM. Un sinistre, une erreur ou une panne du serveur, et il ne reste rien. La règle 3-2-1 demande 3 copies, sur 2 supports, dont 1 hors du site.

Objectif — Une seconde copie, chaque nuit, sur un stockage S3 situé ailleurs (ici, un NAS personnel qui fait tourner SeaweedFS), relisible et surveillée. Réalisé et vérifié le 05/11/2026 (Documentation, étape 65).

Le principe

Depuis PBS 4.2 (avril 2026), un datastore peut être rangé dans un stockage objet S3 (Amazon S3 ou tout serveur compatible : Ceph, SeaweedFS…). PBS garde un cache local et envoie les morceaux de sauvegarde comme objets. Une synchronisation locale recopie chaque nuit le datastore principal vers ce datastore S3.

Principe à retenir — Un datastore S3 n’appartient à aucun serveur : si le PBS principal disparaît, n’importe quel PBS neuf peut rattacher le bucket et restaurer (datastore create … --reuse-datastore true).

Prérequis côté stockage S3

Créer l’utilisateur S3 avant d’exposer le service. SeaweedFS, tant qu’aucun utilisateur n’existe, accepte tout le monde sans clé. Vérification : une requête anonyme doit répondre AccessDenied.

SeaweedFS : régler Volume Size Limit avant de créer des buckets. Avec 30 000 Mo sur 200 Gio, il n’avait que 6 emplacements de volume, tous pris : le datastore était refusé (failed to upload in-use marker … 500, H-85). Avec 1 000 Mo, 197 emplacements.

13.4.1 Un disque de cache dédié

La documentation de PBS demande un cache local sur un disque dédié, de 64 à 128 Gio. Dans Proxmox : VM du PBS → Hardware → Add → Hard Disk, 64 Gio, Backup décoché (un cache ne se sauvegarde pas). Puis, sur le PBS, en root :

lsblk -dno NAME,SIZE,TYPE

Le nouveau disque apparaît (ici sdc, 64G) sans partition. Vérifier deux fois le nom avant de formater.

mkfs.ext4 -L s3-cache /dev/sdc
mkdir -p /mnt/datastore/s3-cache
echo "UUID=$(blkid -s UUID -o value /dev/sdc) /mnt/datastore/s3-cache ext4 defaults,nofail 0 2" >> /etc/fstab
systemctl daemon-reload && mount /mnt/datastore/s3-cache && chown backup:backup /mnt/datastore/s3-cache

nofail : si ce disque manque un jour, PBS démarre quand même (le datastore S3 sera simplement indisponible).

13.4.2 Déclarer le S3 (interface web : les clés ne passent par personne)

Configuration → Remotes → onglet S3 Endpoints → Add :

Vérification, sur le PBS :

proxmox-backup-manager s3 check seaweedfs-maison pbs-lab

Aucune erreur, code de retour 0.

13.4.3 Le datastore S3

proxmox-backup-manager datastore create s3-maison /mnt/datastore/s3-cache/s3-maison --backend type=s3,client=seaweedfs-maison,bucket=pbs-lab

TASK OK. Le dossier de cache est un sous-dossier du disque (le disque lui-même contient lost+found).

13.4.4 Essayer sur une seule VM, puis vérifier

proxmox-backup-manager sync-job create s3-essai --store s3-maison --remote-store sio2527-lab --group-filter group:vm/105 --transfer-last 1
proxmox-backup-manager sync-job run s3-essai
proxmox-backup-manager verify s3-maison

Sans --remote, la synchronisation est locale (d’un datastore à l’autre du même PBS). transfer-last 1 : seule la dernière sauvegarde de chaque VM part. Le 05/11 : 630 Mio en 483 morceaux à 25 Mio/s, puis 0 erreur à la vérification, qui relit chaque morceau depuis le S3. Supprimer ensuite la tâche d’essai : proxmox-backup-manager sync-job remove s3-essai.

13.4.5 L’automatisme de chaque nuit

proxmox-backup-manager sync-job create s3-nuit --store s3-maison --remote-store sio2527-lab --schedule '04:00' --transfer-last 1
proxmox-backup-manager prune-job create s3-garder-3 --store s3-maison --schedule '05:00' --keep-last 3
proxmox-backup-manager datastore update s3-maison --gc-schedule '05:30'

13.4.6 Être prévenu si la copie ne se fait plus

L’exporteur PBS publie les mesures de tous les datastores, dont le nouveau. Dans Grafana : (time() - pbs_snapshot_vm_last_timestamp{datastore="s3-maison"}) / 3600 donne l’âge de la dernière copie de chaque VM (alerte au-delà de 30 h : sauvegarde vers 02:15, copie à 04:00). Penser à filtrer les panneaux et règles existants sur le datastore principal (datastore="sio2527-lab"), sinon chaque VM apparaît en double. Pour un datastore S3, pbs_used et pbs_size décrivent le disque de cache local, pas le bucket (constaté le 05/11 : 5,1 Gio affichés pour ≈ 75 Gio copiés). La place réelle se lit côté stockage S3.

Validation — s3 check sans erreur ; datastore créé ; synchronisation d’essai TASK OK ; verify 0 erreur ; côté stockage, les objets arrivés dans le bucket ; le lendemain, toutes les VM présentes sur le datastore S3. Une copie de chaque VM hors du site, relisible, renouvelée chaque nuit, et une alerte si elle vieillit.

13.4.7 Restaurer depuis la copie

Proxmox ne voit d’abord que le datastore principal. Pour restaurer depuis le S3 : sur PBS, donner au compte de Proxmox la lecture seule sur le datastore S3, puis déclarer un second stockage dans Proxmox.

proxmox-backup-manager acl update /datastore/s3-maison DatastoreReader --auth-id 'backup-pve01@pbs!pve01'

Proxmox → Datacenter → Storage → Add → Proxmox Backup Server : mêmes serveur, compte (jeton), mot de passe (secret du jeton) et empreinte que le stockage principal, Datastore = s3-maison. Puis restaurer dans une VM neuve, carte réseau débranchée :

qmrestore <stockage-s3>:backup/vm/<id>/<date> <nouvel-id> --storage storage-images --unique 1

qm set <nouvel-id> --net0 "<net0 d'origine>,link_down=1"

401 Unauthorized à l’ajout du stockage : le mot de passe n’est pas le secret du jeton (journal de PBS : invalid credentials).

Validation — la VM démarre, son nom et ses services sont ceux de l’originale ; puis elle est supprimée. Au lab : srv-web-02 restaurée en 125 s le 06/11 (Documentation, étape 65.3).

14 · Pièges et checklist

Supprimer une VM restée verrouillée par une restauration interrompue (shell de l’hyperviseur, VM de test uniquement, en vérifiant l’identifiant deux fois) :

qm unlock 139
qm destroy 139 --purge --destroy-unreferenced-disks 1
pvesm list storage-images | grep vm-139      # s'il reste un disque :
pvesm free storage-images:vm-139-disk-0

 VM PBS : système sur 32 Gio, données 500 Gio « Backup » décoché, VLAN 30, IP fixe libre, hors du pool sauvegardé
 Dépôts corrigés, système à jour, redémarré ; agent invité actif
 Compte nominatif par clé SSH ; root interdit en SSH
 Datastore ext4 créé
 Utilisateur + jeton, rôle DatastoreBackup sur les deux ; secret conservé
 Alias + redirection WAN restreinte à l'hyperviseur ; curl → 200
 Stockage PBS ajouté dans Proxmox (adresse WAN de pfSense, empreinte)
 Deux sauvegardes d'une VM : la seconde est incrémentale
 Restauration sous un nouvel identifiant jusqu'à TASK OK, puis copie supprimée
 Prune (Keep Daily 7), GC, Verify planifiés dans PBS
 Copie hors site : disque de cache dédié, endpoint S3 (s3 check OK), datastore S3, essai + verify, sync 04:00, prune, GC, alerte Grafana
 Tâche planifiée vers PBS, « Keep all backups », Pool based, Repeat missed
 Première nuit contrôlée (§13)
 Cible SMTP 587/STARTTLS + matcher « tout » ; default-matcher désactivé ; mail de test reçu (§13.1)
 Gel : actif sur Linux et le contrôleur de domaine, désactivé sur pfSense et le poste (§13.2)
 VM Windows : SSD emulation + Discard, arrêt/démarrage depuis Proxmox (§13.3)

La règle à retenir en une phrase

PBS n’écrit que les blocs nouveaux, donc chaque nuit coûte peu ; Proxmox envoie avec un jeton qui ne peut pas supprimer, et c’est PBS qui fait le ménage : Prune pour décider, Garbage Collection pour libérer.