Proxmox Backup Server : garbage Collection et Prune

Introduction

Ce tutoriel explique comment configurer la maintenance de Proxmox Backup Server pour le stockage de sauvegardes à long terme à l'aide de tâches de prune et du garbage collection. Vous allez configurer le prune Proxmox, planifier le garbage collection Proxmox et estimer l'utilisation du stockage afin que votre datastore ne grossisse pas jusqu'à consommer tout l'espace disque disponible.

À la fin de ce tutoriel, vous disposerez d'une politique de prune planifiée et d'un calendrier de garbage collection pour un datastore Proxmox Backup Server, avec des exemples pratiques de rétention pour des sauvegardes quotidiennes, hebdomadaires et mensuelles.

Prérequis

Avant de commencer, assurez-vous de disposer de :

• Proxmox Backup Server 4.2.x ou version ultérieure
• Un datastore PBS configuré, avec des sauvegardes existantes ou prévues
• Un accès administrateur à l'interface web de Proxmox Backup Server
• Un accès shell en tant que root ou autre utilisateur disposant de droits d'administration PBS suffisants
• Une compréhension de base des tâches de sauvegarde Proxmox VE et des namespaces PBS
• Environ 30 minutes pour réaliser la configuration

Ce tutoriel s'adresse aux administrateurs système de niveau intermédiaire.

Étape 1 : comprendre comment le prune et le garbage collection fonctionnent ensemble

Dans Proxmox Backup Server, l'élagage (prune) et le garbage collection sont deux opérations de maintenance distinctes. Comprendre comment elles interagissent est essentiel pour une gestion efficace des datastores Proxmox.

Une tâche de prune détermine quels snapshots de sauvegarde conserver et lesquels retirer de l'historique visible des sauvegardes. Lorsque PBS élague un snapshot, il supprime ses métadonnées, ses index, ses journaux et ses notes. Il ne supprime pas immédiatement les chunks de sauvegarde inutilisés. Les chunks référencés par les snapshots élagués sont supprimés plus tard par le garbage collection.

Le garbage collection (GC) libère de l'espace dans le datastore en supprimant les chunks inutilisés du stockage de chunks. PBS utilise des chunks dédupliqués : un même chunk peut donc être référencé par plusieurs snapshots de sauvegarde. Pour cette raison, PBS ne peut pas supprimer les chunks en toute sécurité au moment précis où un snapshot est élagué. Il doit d'abord vérifier qu'aucun snapshot restant ni aucune sauvegarde en cours ne les référence encore.

PBS applique également un délai de grâce (grace period) pour la suppression des chunks. Pendant le GC, les chunks sont marqués puis balayés (mark and sweep), mais ceux qui se trouvent dans le délai de grâce sont signalés comme suppressions en attente (pending removals) et ne sont pas supprimés immédiatement. Cela protège les sauvegardes en cours et tient compte du comportement des horodatages d'accès du système de fichiers, en particulier avec le montage relatime courant.

Étape 2 : examiner la configuration actuelle du datastore

Vous pouvez le faire aussi bien en CLI que via l'interface web.

Listez les datastores disponibles :

proxmox-backup-manager datastore list

Sortie attendue : tableau de la liste des datastores.

Choisissez le datastore qui stocke vos sauvegardes Proxmox VE. Dans les exemples suivants, remplacez <DATASTORE_NAME> par le nom de votre datastore.

Vérifiez l'état actuel du garbage collection :

proxmox-backup-manager garbage-collection status <DATASTORE_NAME>

Vous devriez voir l'état actuel du GC pour le datastore. Si le GC n'a jamais été exécuté, la sortie peut n'indiquer aucune exécution réussie précédente.

Listez les tâches de prune existantes :

proxmox-backup-manager prune-job list

Vous devriez voir les tâches de prune existantes, ou une liste vide si aucune tâche de prune n'a été configurée.

Pour vérifier via l'interface web, accédez à Datastore - <DATASTORE_NAME> - Prune & GC Jobs :

Étape 3 : planifier une politique de rétention des sauvegardes à long terme

Une politique de rétention doit correspondre aux exigences de restauration et à la capacité de stockage. Pour de nombreux plans de rétention de sauvegardes Proxmox, une politique pratique à long terme repose sur le schéma grand-père-père-fils (grandfather-father-son) :

Option de rétention	Valeur d'exemple	Résultat
keep-daily	14	Conserve une sauvegarde par jour pendant 14 jours de sauvegarde
keep-weekly	8	Conserve une sauvegarde par semaine pendant 8 semaines de sauvegarde
keep-monthly	12	Conserve une sauvegarde par mois pendant 12 mois de sauvegarde
keep-yearly	2	Conserve une sauvegarde par an pendant 2 années de sauvegarde

Les options de rétention de PBS sont traitées par intervalles de temps (time buckets). Par exemple, keep-daily conserve la dernière sauvegarde de chaque jour retenu, et les jours sans sauvegarde ne sont pas comptés. keep-weekly conserve la dernière sauvegarde de chaque semaine ISO retenue, et les semaines sans sauvegarde ne sont pas comptées.

Pour un calendrier de sauvegarde quotidien, commencez avec l'une de ces politiques :

Politique	Paramètres de rétention	Cas d'usage
Prudente	keep-daily 7 keep-weekly 4 keep-monthly 6	Petit datastore ou historique de restauration court
Équilibrée	keep-daily 14 keep-weekly 8 keep-monthly 12	Sauvegardes typiques de VM et de conteneurs
Long terme	keep-daily 30 keep-weekly 12 keep-monthly 24 keep-yearly 3	Datastore plus volumineux ou historique imposé par la conformité

Étape 4 : estimer le stockage nécessaire avant d'appliquer la rétention

La planification du stockage pour la conservation de sauvegardes à long terme ne revient pas à multiplier la taille complète de la VM par le nombre de snapshots. Proxmox Backup Server utilise la déduplication : chaque nouvelle sauvegarde ne stocke généralement que les chunks modifiés ainsi que les métadonnées. Vous devez néanmoins calculer une estimation prudente.

Utilisez cette formule :

Stockage estimé = données protégées initiales + données modifiées par jour * équivalent en jours conservés + marge de sécurité

Exemple 1 : rétention équilibrée pour un groupe de VM :

Valeur	Exemple
Données de VM protégées	2 To
Moyenne quotidienne de données modifiées	80 Go
Politique de rétention	14 quotidiennes · 8 hebdomadaires · 12 mensuelles
Marge de sécurité	25 pour cent

Points de modification conservés (approximation) :

14 daily + 8 weekly + 12 monthly = 34 restore points

Données modifiées (approximation) :

80 GB * 34 = 2720 GB

Total approximatif avant marge :

2000 GB + 2720 GB = 4720 GB

Ajoutez une marge de sécurité de 25 pour cent :

4720 GB * 1.25 = 5900 GB

Pour cette charge de travail, prévoyez environ 6 To de capacité utile pour le datastore.

Exemple 2 : politique pour un datastore plus petit :

Valeur	Exemple
Données de VM protégées	1 To
Moyenne quotidienne de données modifiées	30 Go
Politique de rétention	7 quotidiennes · 4 hebdomadaires · 6 mensuelles
Marge de sécurité	25 pour cent

Points de restauration (approximation) :

7 + 4 + 6 = 17 restore points

Stockage (approximation) :

1000 GB + (30 GB * 17) = 1510 GB
1510 GB * 1.25 = 1887.5 GB

Pour cette charge de travail, prévoyez environ 2 To de capacité utile pour le datastore.

Étape 5 : créer une tâche de prune dans l'interface web

1. Ouvrez l'interface web de Proxmox Backup Server.
2. Sélectionnez Datastore.
3. Sélectionnez <DATASTORE_NAME>.
4. Ouvrez l'onglet Prune & GC.
5. Cliquez sur Add Prune Job.
6. Définissez Datastore sur <DATASTORE_NAME>.
7. Définissez Namespace si vous souhaitez n'élaguer qu'un seul namespace.
8. Configurez les valeurs de rétention, par exemple keep-daily à 14, keep-weekly à 8 et keep-monthly à 12.
9. Définissez le calendrier, par exemple 03:00.
10. Enregistrez la tâche de prune.

Résultat attendu : PBS crée une tâche de prune planifiée pour le datastore ou le namespace. Cette tâche supprime périodiquement les snapshots de sauvegarde qui ne sont plus retenus par votre politique de rétention.

Étape 6 : créer une tâche de prune en ligne de commande

Vous pouvez également créer la même tâche de prune depuis le shell PBS.

Pour une tâche de prune portant sur l'ensemble du datastore :

proxmox-backup-manager prune-job create pve-longterm \
  --store <DATASTORE_NAME> \
  --schedule "03:00" \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12 \
  --comment "Long-term Proxmox backup retention"

Résultat attendu : PBS crée une tâche de prune nommée pve-longterm.

Pour une tâche de prune propre à un namespace :

proxmox-backup-manager prune-job create pve-namespace-longterm \
  --store <DATASTORE_NAME> \
  --ns <NAMESPACE> \
  --schedule "03:00" \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12 \
  --comment "Long-term retention for namespace"

Résultat attendu : PBS n'élague que le namespace sélectionné. C'est utile lorsque des clusters, des locataires (tenants) ou des environnements différents exigent des politiques de rétention distinctes.

Listez la tâche de prune :

proxmox-backup-manager prune-job list

Sortie attendue : tableau de la liste des tâches de nettoyage des sauvegardes Proxmox.

Étape 7 : configurer la planification du garbage collection

Une fois que le prune a supprimé les métadonnées des anciens snapshots, le GC doit s'exécuter pour récupérer l'espace des chunks inutilisés. Une planification hebdomadaire du GC est un bon point de départ pour la plupart des installations.

Définissez une planification hebdomadaire du GC :

proxmox-backup-manager datastore update <DATASTORE_NAME> \
  --gc-schedule "Sun 04:00"

Vous pouvez la configurer via l'interface web en accédant à Datastore - <DATASTORE_NAME> - Prune & GC Jobs → Garbage Collection Jobs → Edit :

Résultat attendu : PBS planifie le garbage collection du datastore tous les dimanches à 04:00.

Vérifiez l'état du GC :

proxmox-backup-manager garbage-collection status <DATASTORE_NAME>

La sortie attendue inclut le nom du datastore ainsi que des informations sur la dernière exécution du GC ou sur la prochaine.

Vous pouvez également lancer le GC manuellement :

proxmox-backup-manager garbage-collection start <DATASTORE_NAME>

Résultat attendu : PBS démarre une tâche de GC pour le datastore.

Étape 8 : choisir un calendrier sûr pour le prune et le GC

Un calendrier pratique est le suivant :

Tâche	Calendrier d'exemple	Justification
Tâche de sauvegarde Proxmox VE	Tous les jours à 01:00	Crée d'abord les nouvelles sauvegardes
Tâche de prune PBS	Tous les jours à 03:00	Supprime les snapshots hors rétention
Tâche de GC PBS	Chaque semaine, le dimanche à 04:00	Récupère les chunks inutilisés après le prune

Cet ordre garantit que les nouvelles sauvegardes sont disponibles avant la suppression des anciens snapshots. Il laisse aussi à PBS le temps de terminer les écritures de sauvegarde avant le démarrage des tâches de prune et de GC.

Dans les environnements très sollicités, évitez d'exécuter en même temps les tâches de sauvegarde, de vérification, de prune, de synchronisation et de GC. Échelonnez les tâches de maintenance pour réduire la contention d'E/S.

Étape 9 : vérifier la configuration

Listez les tâches de prune :

proxmox-backup-manager prune-job list

Vérifiez que la tâche possède le datastore, le namespace, le calendrier et les valeurs keep attendus.

Affichez une tâche de prune :

proxmox-backup-manager prune-job show pve-longterm

Résultat attendu : PBS affiche les options de rétention configurées.

Vérifiez la configuration du GC :

proxmox-backup-manager garbage-collection list

Résultat attendu : PBS liste l'état du garbage collection de tous les datastores, y compris ceux qui n'ont pas de tâche de GC.

Vérifiez l'utilisation du datastore depuis l'interface web :

• Ouvrez Datastore.
• Sélectionnez <DATASTORE_NAME>.
• Examinez l'utilisation du datastore et l'historique des tâches.
• Ouvrez Tasks et vérifiez que les tâches de prune et de GC se terminent avec succès.

Résultat attendu : le datastore affiche une activité de maintenance planifiée et les anciens snapshots sont supprimés conformément à la configuration du prune Proxmox.

Étape 10 : surveiller la croissance du stockage dans le temps

Après avoir configuré les tâches de prune dans PBS, surveillez l'utilisation du stockage pendant au moins un cycle complet de rétention. Par exemple, si vous configurez keep-monthly 12, il vous faut plusieurs mois de données avant que la tendance à long terme ne devienne claire.

Examinez ces métriques :

Métrique	Ce qu'il faut vérifier
Espace utilisé du datastore	Confirme que l'optimisation du stockage des sauvegardes fonctionne
Journaux des tâches de prune	Confirment que les snapshots sont supprimés
Journaux des tâches de GC	Confirment que les chunks inutilisés sont supprimés
Suppressions en attente (pending removals)	Indiquent les chunks qui attendent la fin du délai de grâce du GC
Tendance de la taille des tâches de sauvegarde	Montre si le volume de données modifiées augmente

Si le datastore continue de croître plus vite que prévu, réduisez la rétention ou ajoutez du stockage avant que le système de fichiers ne soit plein.

Ajustements courants :

Problème	Ajustement
Le datastore se remplit trop vite	Réduire keep-daily, keep-weekly ou keep-monthly
Trop peu de points de restauration récents	Augmenter keep-daily
L'historique mensuel est trop court	Augmenter keep-monthly
Les sauvegardes chevauchent la maintenance	Décaler le prune ou le GC à un horaire plus tardif
Le GC libère peu d'espace	Vérifier que les tâches de prune suppriment réellement les anciens snapshots

Annulation des modifications

Pour supprimer une tâche de prune :

proxmox-backup-manager prune-job remove pve-longterm

Résultat attendu : PBS supprime la configuration de la tâche de prune.

Pour désactiver la planification du GC sans supprimer le datastore :

proxmox-backup-manager datastore update <DATASTORE_NAME> \
  --delete gc-schedule

Résultat attendu : PBS efface la planification automatique du GC pour le datastore.

Pour modifier la rétention plutôt que de supprimer la tâche de prune :

proxmox-backup-manager prune-job update pve-longterm \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6

Résultat attendu : PBS conserve la tâche de prune mais applique la nouvelle politique de rétention lors des prochaines exécutions.

Dépannage

Le GC ne libère pas d'espace immédiatement

Cause : le prune a supprimé les métadonnées des snapshots, mais les chunks sont encore référencés par d'autres snapshots ou se trouvent dans le délai de grâce du GC.
Solution : attendez la fin du délai de grâce et relancez le GC plus tard. Consultez les journaux de tâches pour repérer les suppressions en attente (pending removals).

Le prune conserve plus de sauvegardes que prévu

Cause : keep-daily, keep-weekly et keep-monthly fonctionnent par intervalles de temps. Les jours, semaines ou mois sans sauvegarde ne sont pas comptés. Les règles de rétention se chevauchent également.
Solution : utilisez le simulateur de prune de PBS avant de modifier la rétention en production. Cela vous permet de prévisualiser le comportement de la rétention avant d'appliquer les modifications.

Le datastore continue de croître après le prune et le GC

Cause : le volume de données modifiées par jour peut être supérieur à l'estimation, les sauvegardes peuvent inclure de nouveaux disques, ou la rétention peut être trop importante pour le datastore.
Solution : recalculez l'estimation de volume avec les données réellement modifiées. Réduisez la rétention ou étendez le stockage.

La tâche de prune n'affecte pas un namespace

Cause : la tâche de prune est peut-être configurée pour le mauvais namespace ou la mauvaise profondeur de namespace.
Solution : vérifiez les paramètres de la tâche de prune et confirmez la valeur de --ns. Si vous voulez que la tâche s'applique à un seul namespace, définissez-le explicitement.

Les clients de sauvegarde peuvent encore supprimer des sauvegardes

Cause : les identifiants de sauvegarde peuvent disposer de droits de suppression, ou la rétention est configurée en dehors de PBS.
Solution : appliquez le principe du moindre privilège aux clients de sauvegarde. Pour la résistance aux rançongiciels, privilégiez les tâches de prune côté PBS plutôt que d'accorder des droits de suppression aux clients de sauvegarde.

Conclusion

Vous avez configuré la maintenance de Proxmox Backup Server pour la rétention à long terme en créant une tâche de prune et en planifiant le garbage collection. Vous avez également appris pourquoi les chunks ne sont pas supprimés immédiatement, comment le GC achève le nettoyage du datastore et comment estimer les besoins de stockage avant d'appliquer une rétention à long terme. Ces pratiques favorisent l'optimisation des sauvegardes Proxmox en améliorant l'efficacité du stockage et en garantissant une rétention des sauvegardes prévisible et maîtrisable.

Pour la suite, ajoutez des tâches de vérification, configurez des notifications en cas d'échec des tâches de prune et de GC, et examinez chaque mois la croissance du datastore. Ainsi, l'optimisation du stockage des sauvegardes reste prévisible et les paramètres de rétention ne consomment pas silencieusement toute la capacité disponible.

Version du document : 1.0
Dernière mise à jour : juin 2026
Responsable : Équipe de documentation technique