Stratégies et cas d’usage #

Dans Cybee, la rétention des sauvegardes détermine combien de temps les snapshots sont conservés dans le dépôt et lesquels sont supprimés. Elle repose sur les mécanismes forget et prune, orchestrés automatiquement par le Backup Manager.

Une politique de rétention bien calibrée est aussi importante que la planification elle-même : elle conditionne la capacité à remonter dans le temps, l’espace de stockage consommé et la conformité aux exigences réglementaires (NIS2, ISO 27001, etc.).

Les deux opérations : Forget et Prune #

La rétention dans Cybee repose sur deux opérations complémentaires :

Les trois modèles de rétention #

Cybee supporte trois modèles de rétention, que l’on peut combiner entre eux pour construire une stratégie sur mesure.

Modèle 1 — GFS (Grandfather-Father-Son) #

Le modèle GFS est la stratégie de référence en sauvegarde d’entreprise. Il conserve un nombre fixe de snapshots par période calendaire.

Pour chaque période, Cybee conserve le snapshot le plus récent. Les règles sont cumulatives : un snapshot peut être retenu par plusieurs règles simultanément.

Exemple standard — Serveur applicatif en production

Objectif : 2 semaines de granularité fine, 2 mois de granularité hebdomadaire, 1 an de mensuel, 5 ans d’archivage annuel.

Exemple léger — Poste de travail développeur (sauvegardes horaires)

Modèle 2 — Fenêtre temporelle glissante  #

Ce modèle conserve tous les snapshots compris dans une durée glissante à partir du snapshot le plus récent. Il est particulièrement adapté aux environnements à fréquence de sauvegarde variable ou aux périodes d’activité intense.

La durée s’exprime avec les unités : h (heures), d (jours), m (mois), y (années).

Des variantes permettent de combiner fenêtre temporelle et logique GFS à l’intérieur de la fenêtre :

Exemple — Granularité fine récente, allégement au-delà

Contexte : on souhaite pouvoir faire un rollback précis sur les 48 dernières heures, puis revenir à une rétention journalière pendant 2 semaines, puis mensuelle sur 12 mois.

Exemple — Mode « burst » post-incident dans Cybee

Suite à un incident, des sauvegardes rapprochées (toutes les 15 min) ont été lancées sur 48h. La rétention conserve cette granularité de crise, puis revient au rythme standard.

Modèle 3 — Conservation des N derniers snapshots #

Le modèle le plus simple : conserver les n snapshots les plus récents, sans considération de période calendaire.

Cas d’usage typiques :

• Pipeline CI/CD : ne garder que les 10 derniers builds valides (--keep-last 10)

• Sauvegarde de configurations réseau : garder les 20 dernières versions (--keep-last 20)

• Sauvegardes de migration one-shot : nettoyer le dépôt en ne conservant que l’essentiel (--keep-last 3)

Combinaison avec GFS (usage avancé)

--keep-last peut compléter une règle GFS pour garantir qu’un minimum de snapshots est toujours conservé, même en cas de trou de sauvegarde :

Bonnes pratiques dans Cybee #

Simuler avant d’appliquer #

Avant d’appliquer une nouvelle politique de rétention en production, toujours utiliser le mode simulation (--dry-run) qui affiche les snapshots qui seraient supprimés sans les supprimer réellement. Cette étape est obligatoire sur tout dépôt contenant des données de production.

Aligner rétention et planification #

Une politique de rétention doit être cohérente avec la politique de planification (Schedule). Quelques exemples d’alignement :

Configurer une sauvegarde horaire sans rétention horaire revient à consommer de l’espace inutilement sans bénéficier de la granularité fine attendue.

Utiliser --group-by en environnement multi-tenant #

Sans groupement, les règles de rétention s’appliquent à tous les snapshots du dépôt confondus, ce qui peut provoquer des suppressions inattendues dans un contexte multi-client. La recommandation Cybee est :

--group-by host,paths,tags

Cela isole les règles de rétention par source (hôte + chemin + tag), garantissant une application indépendante par client ou par type de données.

Tableau récapitulatif des modèles #