Rétention : prune, garbage collection, verify, ordre des jobs¶

Day 1 · DéployerNiveau 2 · OpérerCoursRédigé · à valider en lab

Sur PBS, l'espace disque se gère en trois temps : le prune décide quelles sauvegardes supprimer, la garbage collection (GC) libère réellement les blocs devenus inutiles, le verify prouve que ce qui reste est lisible. Ces jobs doivent tourner dans le bon ordre et en dehors de la fenêtre de sauvegarde. Si l'un d'eux manque, le datastore se remplit ou des sauvegardes corrompues passent inaperçues.

Les trois tâches¶

Tâche	Ce qu'elle fait	Ce qu'elle ne fait pas	Fréquence conseillée
Prune	Supprime les métadonnées (manifeste, index) des snapshots hors rétention	Ne libère presque pas d'espace	Quotidienne, après la sauvegarde
Garbage collection	Phase 1 : marque (atime) chaque chunk encore référencé. Phase 2 : supprime les chunks non marqués plus vieux que le délai de grâce	Ne supprime pas un chunk non référencé depuis moins d'environ 24 h	Quotidienne ou au moins hebdomadaire
Verify	Relit chaque chunk et contrôle sa somme ; marque le snapshot ok ou failed	Ne répare pas (la copie MSP ou `resync-corrupt` le peuvent)	Quotidienne sur les nouveaux snapshots, re-vérification complète au moins mensuelle

Comment le prune choisit¶

Les options s'appliquent dans cet ordre : keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. Chaque option garde la sauvegarde la plus récente de chaque période, et l'option suivante ne considère que les sauvegardes plus anciennes que celles déjà retenues. Les semaines commencent le lundi (semaines ISO).

Exemple avec une sauvegarde par nuit et keep-last 3, keep-daily 14, keep-weekly 8, keep-monthly 12 : les 3 dernières, puis une par jour sur les 14 jours précédents, puis une par semaine sur 8 semaines, puis une par mois sur 12 mois. Environ 37 points de restauration couvrant un an.

Testez votre politique avant de l'appliquer avec le simulateur de prune ou un dry run : proxmox-backup-client prune vm/101 --dry-run --keep-daily 14 --keep-weekly 8 --repository ….

Les snapshots marqués Protected sont ignorés par le prune et ne comptent pas dans la rétention.

Le délai de grâce de la GC¶

flowchart LR
    P["J 06:00<br/>prune : snapshot hors<br/>rétention supprimé"] --> G1["J 07:00<br/>GC : chunks orphelins<br/>atime de moins de 24 h 05<br/>= Pending removals"]
    G1 --> G2["J+1 07:00<br/>GC suivante : atime<br/>de plus de 24 h 05<br/>= chunks supprimés"]

La phase 2 ne supprime que les chunks dont l'atime est plus vieux que 24 h 05 min avant le début de la GC (ou que le plus ancien job de sauvegarde encore en cours). Cette marge vient de relatime, qui ne met à jour l'atime qu'une fois par 24 h. Conséquence : l'espace libéré par un prune n'apparaît qu'à la GC du lendemain. Le résumé de la tâche affiche Pending removals pour ce qui sera libéré au prochain passage.

Ordre recommandé des jobs (PBS local)¶

Heure	Job	Où le configurer
21:00 → 05:00	Sauvegardes PVE	PVE : Datacenter → Backup
05:30	Sync vers le MSP (push) ou fenêtre de pull MSP	PBS : Datastore → Sync Jobs
06:00	Prune job	PBS : Datastore → Prune & GC → Prune Jobs
07:00	Garbage collection	PBS : Datastore → Prune & GC (GC Schedule)
08:00	Verify des nouveaux snapshots (Skip verified coché, Re-Verify After 30 jours)	PBS : Datastore → Verify Jobs
1er samedi du mois	Re-vérification complète (rien d'ignoré)	PBS : Datastore → Verify Jobs

Synchroniser avant le prune donne au MSP la dernière sauvegarde même si la rétention locale est courte. Vérifier avant la sync permet l'option verified-only, au prix d'un décalage d'une nuit.

proxmox-backup-manager prune-job create quotidien --store pbs01 --schedule '06:00' \
  --keep-last 3 --keep-daily 14 --keep-weekly 8 --keep-monthly 12
proxmox-backup-manager datastore update pbs01 --gc-schedule '07:00'
proxmox-backup-manager garbage-collection start pbs01
proxmox-backup-manager garbage-collection status pbs01
proxmox-backup-manager verify pbs01 --ignore-verified true   # verify manuel

Recommandations MSP¶

Rétention configurée uniquement côté PBS (prune jobs), Keep all backups côté stockage PVE.
Rétention MSP plus longue que la rétention locale : c'est elle qui permet de remonter avant une attaque passée inaperçue plusieurs jours.
Notifications PBS actives pour GC, verify et sync en échec.
Un verify failed déclenche un ticket : la copie MSP peut fournir un snapshot sain.

Pièges vus en support

Pas de GC planifiée : le prune tourne, le datastore se remplit quand même.
GC lancée juste après un prune « pour libérer de la place » : rien ne se libère avant 24 h. C'est normal (RB-14).
Verify complet quotidien sur un gros datastore HDD : il ne finit jamais avant les sauvegardes suivantes.
Datastore monté avec noatime, ou système de fichiers qui ne met pas à jour l'atime : la GC peut supprimer des chunks encore utilisés. PBS 4 contrôle l'atime à la création et à la GC (option gc-atime-safety-check) : ne la désactivez pas.
Rétention à la fois dans le job PVE et dans le PBS.

Testez-vous¶

Vous lancez un prune à 10:00 puis une GC à 10:05. Combien d'espace est libéré ?

Réponse

Presque rien : les chunks devenus orphelins ont un atime récent, inférieur au délai de grâce de 24 h 05. Ils sont listés en Pending removals et supprimés par la GC du lendemain.
Que se passe-t-il pour une sauvegarde marquée Protected lors du prune ?

Réponse

Elle est ignorée et ne compte pas dans la rétention : elle reste jusqu'à ce que la protection soit retirée.
Pourquoi un verify ne remplace-t-il pas un test de restauration ?

Réponse

Il prouve que les chunks sont intacts, pas que la VM démarre ni que l'application est cohérente. Le test mensuel avec PV reste nécessaire.
Avec keep-last 3, keep-daily 7 et une sauvegarde par nuit, combien de snapshots restent ?

Réponse

10 : les 3 derniers, puis 7 sauvegardes quotidiennes plus anciennes.