Rétention Proxmox Backup Server : comment fonctionnent vraiment keep-last, keep-daily et keep-weekly

La plupart des gens lisent keep-daily 7 comme « garder sept jours de sauvegardes ». Ce n’est pas ce que ça fait, et l’écart entre ce que vous croyez avoir configuré et ce que Proxmox Backup Server garde réellement, c’est là qu’on gaspille du stockage ou, pire, qu’on découvre qu’un snapshot dont on avait besoin a été pruné. Les règles de rétention sont simples une fois qu’on voit le modèle derrière, alors posons-le, puis déroulons un planning réel dedans.

La rétention, ce sont des paniers de temps, pas un décompte

La rétention PBS s’exprime avec une famille d’options keep-* : keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly et keep-yearly. Chacune est un compteur, et chacune opère sur un panier de temps.

Prenez keep-daily 7. PBS ne garde pas tous les snapshots des sept derniers jours. Il parcourt vos snapshots du plus récent au plus ancien, les regroupe par jour calendaire, et garde le snapshot le plus récent de chacun des sept derniers jours qui ont un snapshot. Si un jour donné a six snapshots, cinq sont candidats à la suppression et un survit pour représenter ce jour. Si vous avez sauté un jour, ce jour ne compte simplement pas dans les sept. Donc keep-daily 7 signifie « un snapshot pour chacun des sept derniers jours qui en ont un », pas « tout ce qui date de la dernière semaine ».

La même logique remonte l’échelle. keep-weekly 4 garde le snapshot le plus récent de chacune des quatre dernières semaines calendaires. keep-monthly 6 en garde un par mois pendant six mois. keep-yearly fait de même par année. Chaque règle est un panier plus grossier que celle du dessous.

Les règles se chevauchent, et c’est tout l’intérêt

L’erreur qui suit consiste à additionner les nombres. keep-daily 7 plus keep-weekly 4 plus keep-monthly 6, ça ne fait pas dix-sept snapshots. Les règles se chevauchent, et un même snapshot peut en satisfaire plusieurs à la fois.

Le snapshot d’aujourd’hui est le plus récent du jour (daily), le plus récent de la semaine (weekly) et le plus récent du mois (monthly) : il est donc gardé par trois règles mais stocké une seule fois. Ce que vous retenez réellement, c’est l’union des choix de chaque règle, dédoublonnée. Avec ce planning vous obtenez environ sept dailies, plus les représentants hebdomadaires plus anciens que les dailies ne couvrent pas déjà, plus les mensuels plus anciens, en se raréfiant à mesure qu’on recule. La forme obtenue, c’est un historique récent dense et un historique ancien clairsemé, exactement ce à quoi ressemble une politique de rétention saine.

keep-last est votre plancher

keep-last N est l’intrus : il ignore complètement les paniers calendaires et garde les N snapshots les plus récents, quelle que soit leur date. C’est votre plancher de sécurité. Si une VM est sauvegardée toutes les heures et que vous ne réglez que keep-daily 7, un incident étalé sur quelques heures pourrait ne vous laisser qu’un seul snapshot d’aujourd’hui. keep-last 3 garantit que vous avez toujours les trois derniers, quoi que décide la règle daily. Sur un datastore qui reçoit des sauvegardes fréquentes, mettez toujours un keep-last.

Un exemple concret

Disons que srv-db01 est sauvegardé chaque nuit, et que vous réglez keep-daily 7, keep-weekly 4, keep-monthly 6. Après quelques mois de runs nocturnes, vous retenez :

• les 7 derniers snapshots nocturnes, un par jour,
• 4 snapshots hebdomadaires, un par semaine, pour les semaines non déjà couvertes par ces 7 dailies,
• 6 snapshots mensuels, un par mois, pour les mois non déjà couverts au-dessus.

On est de l’ordre de 15 à 16 snapshots distincts couvrant six mois, pas 180. Si vous aviez raisonné en jours bruts, vous auriez provisionné un ordre de grandeur de trop en stockage. C’est aussi pourquoi déduplication et rétention doivent être pensées ensemble, ce qu’on décompose dans ce que coûte vraiment une sauvegarde 3-2-1 sur PBS.

Pruner n’est pas récupérer de l’espace

Encore un point qui surprend : lancer un prune ne libère pas immédiatement du disque. Le prune retire seulement le snapshot de l’index. Les chunks sous-jacents restent sur le disque jusqu’à ce que le garbage collection passe, constate qu’ils ne sont plus référencés par aucun snapshot, et les supprime après un délai de grâce. Le graphe de stockage ne chute donc pas à l’instant où vous prunez. Pour ajuster l’agressivité de tout ça, la documentation sur l’intervalle de prune et GC couvre le planning, et la question distincte du moment où tournent vos jobs de sauvegarde est dans le guide de planification des sauvegardes Proxmox VE.

Ne devinez pas les chiffres, simulez-les

Si la rétention piège autant, c’est que le résultat d’un jeu de règles keep-* face à une cadence de sauvegarde réelle est vraiment difficile à calculer de tête. Plutôt que de déployer une politique et de découvrir des mois plus tard qu’elle a gardé trop peu ou trop, mettez votre planning et vos règles dans le simulateur de rétention PBS et voyez exactement quels snapshots survivent et combien vous finissez par stocker. Il transforme les règles abstraites ci-dessus en la liste concrète de ce que vous auriez réellement sur le disque.

Côté Cloud-PBS managé

Sur un serveur de sauvegarde cloud managé, les plannings de prune et de garbage collection tournent pour vous, réglés pour que l’espace soit récupéré à une cadence sensée sans que vous ayez à surveiller un cron. Vous restez maître de la politique de rétention, car vous seul connaissez vos exigences de reprise, mais la mécanique qui l’applique, pruner à l’heure dite et collecter les déchets sans impacter les sauvegardes live, c’est à nous de la faire tourner. Si vous dimensionnez une politique, décidez d’abord votre fenêtre de reprise, exprimez-la en règles keep-*, et simulez avant de vous engager.