Stratégies et cas d’usage #

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

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 clichés par période calendaire.

Pour chaque période, Cybee conserve le cliché le plus récent. Les règles sont cumulatives : un cliché 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 clichés compris dans une durée glissante à partir du cliché 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 clichés #

Le modèle le plus simple : conserver les n clichés 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 clichés est toujours conservé, même en cas de trou de sauvegarde :

Bonnes pratiques dans Cybee #

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 clichés 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.

Limites du modèle : ce que Cybee ne fait pas #

Pas de rétention par fichier #

Toutes les options de rétention présentées ci-dessus opèrent sur l’objet cliché, jamais sur les fichiers individuellement. Il n’est donc pas possible de configurer une règle « conserver les N dernières versions de chaque fichier ».

Cette limite est intrinsèque au modèle basé sur des clichés du moteur : un cliché n’est pas une copie du fichier, c’est un ensemble de références vers des blobs dédupliqués dans le dépôt. La granularité de rétention s’aligne donc sur la cadence de la planification des clichés, pas sur les modifications individuelles des fichiers.

Tableau récapitulatif des modèles #