Rétention & pruning gfs Décidé
Une grille GFS par machine, plafonnée par le plan — 90 jours inclus, 1 an en option — appliquée exclusivement côté serveur, avec préavis sur les raccourcissements et plancher d'immuabilité en option. Le client n'a pas la gomme.
La rétention n’est pas une durée, c’est une grille
C’est le schéma standard du métier, dit GFS (grand-père / père / fils) : garder les N derniers + 1/jour × D + 1/semaine × W + 1/mois × M. La politique s’exprime en grille ; les offres commerciales sont des préréglages nommés de cette grille.
Le compromis assumé — « et le mardi d’il y a trois semaines ? »
L’objection légitime : sous une grille dégressive, à trois semaines en arrière il ne reste qu’un snapshot par semaine — le mardi précis a disparu, il ne reste que les dimanches qui l’encadrent. Trois réponses :
- La courbe réelle des restaurations est brutalement asymétrique — l'écrasante majorité, c'est « hier » (la suppression accidentelle, remarquée vite). Les demandes lointaines sont presque toujours « avant la corruption », où un point d'ancrage approximatif suffit.
- Le préréglage de base pousse les quotidiens à un mois plein — le « mardi d'il y a trois semaines » reste donc disponible dans l'offre incluse (voir la table).
- La grille n'interdit rien, elle tarife. « Chaque jour pendant 90 jours » est une grille valide (
quotidiens × 90) — et grâce à la dédup, pas si chère pour des données calmes : chunks et nœuds d'arbre inchangés sont partagés entre snapshots par référence. Là où ça pique : le churn — le client qui dump sa base de 10 Go chaque nuit garderait 900 Go en intégral contre ~300 en grille. D'où : la grille dégressive en défaut, l'intégral en réglage (voire en cran d'offre) — son coût dépend du churn du client.
Les préréglages
| Préréglage | Grille | ~Snapshots | Ce que le client retrouve |
|---|---|---|---|
| Inclus — 90 jours | 7 derniers + 1/jour × 30 + 1/sem × 9 | ~42 | n’importe quel jour du dernier mois, n’importe quelle semaine des 2 mois d’avant |
| Option — 1 an | idem + 1/mois × 12 | ~54 | + n’importe quel mois de l’année |
| Réglable | chaque paramètre, sous le plafond du plan | — | jusqu’à l’intégral quotidien si le client y tient |
Le pitch au client final, honnête et lisible : « chaque jour du dernier mois, chaque semaine du dernier trimestre, chaque mois de l’année ».
Le tout par machine, via la config à trois étages : le plan fixe le plafond (l’horizon maximal — c’est l’attribut commercial, section G), le revendeur règle et peut verrouiller, la machine ajuste sous le plafond. Et un argument de vente que la dédup offre gratuitement : allonger la rétention ne coûte que ce qui change — les données statiques coûtent quasi pareil à garder un an ou 90 jours.
Le serveur tient la gomme, jamais le client
Les garde-fous anti-sabotage
Le ransomware sophistiqué ne supprime pas les backups : il raccourcit la rétention — vole les credentials admin du dashboard, passe la rétention à 1 jour, attend le prune. Parades :
- Préavis de destruction — tout raccourcissement de rétention s'applique avec un délai (72 h), notifié, annulable, audité. L'allongement, lui, est immédiat — il ne détruit rien.
- Plancher d'immuabilité (option par client) — les X derniers jours sont WORM : même un admin ne peut pas les pruner. C'est le sujet « anti-ransomware » de la section M — et un argument de vente majeur.
- Legal hold — suspend le pruning d'un client, point. Prioritaire sur toute grille.
Politique vs mécanisme
Pruner = retirer des refs de snapshots ; c’est le GC (le nœud dur restant, section C) qui fait le vrai travail de récupération — mark-and-sweep depuis les racines survivantes. La rétention est la politique, le GC est le mécanisme : les concevoir séparément garde les deux simples. Et les sessions de l’API d’existence protègent déjà les backups en cours pendant qu’un prune tourne.