Mise en œuvre pragmatique des plans de rétention : GFS, intervalles incrémentiels et exigences légales

Les plans de rétention sont une exigence opérationnelle : ils définissent de manière contraignante quelles sauvegardes sont conservées, pendant combien de temps, où et sous quelle forme. Le mot‑clé focal « Plans de rétention » apparaît dès le début, car la bonne planification de ces règles de conservation a des répercussions directes sur le budget de stockage, la capacité de RESTauration et la conformité. Cet article s’adresse aux administrateurs, System Engineers, opérateurs et pRESTataires techniques et explique la rotation GFS, les intervalles incrémentiels, les spécificités MariaDB ainsi que des stratégies pratiques de vérification et de repli.

Pourquoi un plan de rétention est plus que « supprimer les anciennes sauvegardes »

Un plan de rétention est une règle opérationnelle contraignante reposant sur RTO (Recovery Time Objective) et RPO (Recovery Point Objective). Le RTO décrit la durée d’indisponibilité maximale tolérable, le RPO la fenêtre maximale de perte de données acceptable. Ces deux indicateurs gouvernent le choix entre sauvegardes complètes et incrémentielles, les durées de conservation, les intervalles de vérification et les routines de reporting.

Pour l’exploitation, cela signifie : planification de stockage contraignante, exécutions automatisées de suppression avec mode Dry‑Run, responsabilités documentées et trajectoires de repli testées au cas où des suppressions ou des tests de RESTauration échoueraient. Sans ces accords opérationnels, des erreurs de suppression non détectées, des lacunes de conformité ou des durées de RESTauration imprévues sont à craindre.

Operationaliser les plans de rétention: rôles, processus, gouvernance

Un plan de rétention n’est robuste que si, au‑delà de la technique, les processus et responsabilités sont définis. Operationaliser signifie concrètement :

• Définir les responsabilités : qui autorise les exceptions de conservation ? Qui valide les tests de RESTauration ?
• Gestion des changements : toute modification du plan de rétention passe par une revue, un test en staging et une validation (Change‑Ticket).
• Piste d’audit : chaque suppression, déplacement en quarantaine ou RESTauration est journalisée et traçable.

Pourquoi c’est important : la technique seule peut appliquer des règles de suppression erronées sans contrôle humain. La gouvernance empêche que des durées formelles de conservation soient techniquement contournées.

Stratégie GFS (Grandfather‑Father‑Son) en pratique

GFS est un schéma de rotation établi avec des niveaux annuel, mensuel et hebdomadaire. Objectif : archivage long terme tout en conservant un accès rapide pour des RESTaurations à court terme. Les niveaux (Grandfather=annuel, Father=mensuel, Son=hebdomadaire/journalier) se distinguent par la fréquence d’accès et la durée de conservation.

Conseils pratiques :

• Utilisez des conventions de nommage explicites (p. ex. /backup/{env}/{year}/{month}/{week}) et des fichiers de métadonnées contenant UUID, horodatage de création, Checksums et version de l’outil.
• Dimensionnez la capacité avec des hypothèses de croissance conservatrices et des pools de réserve.
• Documentez le parcours de RESTauration par niveau GFS : nombre d’étapes, durée prévue et dépendances (p. ex. Binlogs pour la RESTauration).

Intervalles incrémentiels: longueur de chaîne, RPO et intégrité

Les sauvegardes incrémentielles économisent de l’espace, mais augmentent la complexité de RESTauration. La longueur de la chaîne (nombre d’étapes incrémentielles consécutives) est un paramètre central : plus la chaîne est longue, plus elle est vulnérable aux étapes intermédiaires défaillantes.

Recommandation : limitez la longueur des chaînes (p. ex. maximum 7–14 étapes) et imposez ensuite une sauvegarde complète. Complétez cela par des vérifications d’intégrité immédiates (Checksums, xtrabackup_info contrôle) après chaque sauvegarde. Une chaîne trop longue augmente la probabilité qu’une erreur isolée rende la chaîne entière inutilisable.

Planifier concrètement les intervalles

Un exemple robuste pour des taux de changement moyens :

• Sauvegardes incrémentielles quotidiennes, conservation 14 jours (RESTauration rapide pour les données récentes).
• Sauvegarde complète hebdomadaire ou sauvegarde différentielle, conservation 4 semaines.
• Sauvegarde complète mensuelle (Father), conservation 12 mois.
• Sauvegarde complète annuelle (Grandfather), conservation 7–10 ans pour les données soumises à des obligations légales.

Spécificités MariaDB : Binlogs, XtraBackup, LVM‑snapshots et PITR

Pour MariaDB, les Binlogs (Binary Logs) sont centraux : ils enregistrent toutes les commandes de modification et permettent le Point‑In‑Time Recovery (PITR) ainsi que la réplication. Percona XtraBackup est un outil courant pour les sauvegardes à chaud des bases de données basées sur InnoDB. Les LVM‑snapshots peuvent servir de base à des sauvegardes cohérentes sur de grands systèmes de fichiers, car ils capturent brièvement un état cohérent du système de fichiers.

Binlog‑Management: commandes pratiques, configuration et pièges

Vérifications SQL importantes pour les Binlogs :

# Liste der vorhandenen Binlog‑Dateien und Größen
mysql -e "SHOW BINARY LOGS;"
# Aktuelle Position und Dateiname
mysql -e "SHOW MASTER STATUS;"
# Prüfen, wie weit Replikate sind
mysql -e "SHOW SLAVE STATUSG"

Recommandation de configuration pour my.cnf (exemple) :

# /etc/my.cnf.d/backup.cnf
[mysqld]
log_bin = /var/lib/mysql/mysql-bin
binlog_format = ROW
server_id = 42
# Automatisches Ablaufen von Binlogs nach 30 Tagen
binlog_expire_logs_seconds = 2592000

Quand cela échoue : un réglage agressif de binlog_expire_logs_seconds peut rendre le PITR impossible si vous devez RESTaurer au-delà de la durée configurée. De même, des slaves de réplication asynchrones avec un fort retard peuvent entraîner la suppression des Binlogs nécessaires. Il est donc indispensable d’aligner la politique des Binlogs avec l’architecture de réplication et les scénarios de RESTauration.

XtraBackup : procédure, vérifications et erreurs typiques

XtraBackup produit une sauvegarde incrémentale/complète incluant les métadonnées. Les vérifications essentielles sont :

• Vérifier les métadonnées : xtrabackup_info et xtrabackup_checkpoints doivent être présents et logiquement cohérents.
• Vérifier l’intégrité : xtrabackup –check et un test de RESTauration isolé sont la norme.
• Vérifier la couche de transport : des erreurs lors de la copie (p. ex. rsync, scp, object upload) entraînent des sauvegardes incohérentes.

Exemple : créer une sauvegarde complète et y ajouter des incréments (simplifié) :

# Vollbackup
xtrabackup --backup --target-dir=/backup/full/2026-07-01 --user=backup --password=secret
# Inkrementelles Backup
xtrabackup --backup --target-dir=/backup/inc/2026-07-02 --incremental-basedir=/backup/full/2026-07-01 --user=backup --password=secret

Préparation (prepare) et RESTauration (étapes simplifiées) :

# Prepare (apply logs)
xtrabackup --prepare --target-dir=/backup/full/2026-07-01
# Kopieren/RESTore in Data‑Directory (in Wartungsfenster)
systemctl stop mariadb
rsync -a /backup/full/2026-07-01/ /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
systemctl start mariadb

Si le prepare échoue (par ex. à cause de parties incrémentales manquantes), la RESTauration n’est possible que jusqu’au dernier point intact. Planifiez donc des sauvegardes complètes régulières et des tests de RESTauration supplémentaires dans un environnement isolé.

Relecture des Binlogs avec mysqlbinlog

Pour le PITR, vous rejouez les Binlogs jusqu’au point souhaité. Remarque importante : mysqlbinlog génère des instructions SQL qu’il convient de vérifier dans un environnement de test.

# Générer le binlog jusqu'à un instant donné
mysqlbinlog --stop-datetime="2026-07-02 14:30:00" /var/lib/mysql/mysql-bin.000123 | mysql -u root -p
# En alternative : depuis plusieurs fichiers
mysqlbinlog --stop-datetime="2026-07-02 14:30:00" /var/lib/mysql/mysql-bin.00012* | mysql -u root -p

Il est dangereux d’appliquer automatiquement sans vérification : des transactions volumineuses ou des DDL peuvent modifier l’état de production. Exécutez mysqlbinlog de préférence dans une instance de base de données isolée en préambule et évaluez la taille et le temps d’exécution attendu.

Automatisation : planificateur, validation et exécution à blanc

Les jobs automatisés doivent être idempotents, traçables et sûrs. Cron est largement répandu ; les timers systemd offrent une meilleure visibilité et une politique de redémarrage. Un exemple de timer systemd et de service pour la validation quotidienne :

# /etc/systemd/system/backup-validate.service
[Unit]
Description=Backup Validation Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/validate-backup.sh

# /etc/systemd/system/backup-validate.timer
[Unit]
Description=Run backup validation daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Le script de validation doit définir des codes de sortie (0=OK, 1=Avertissement, 2=Erreur) et écrire des logs structurés en JSON, afin que les systèmes de supervision (p. ex. Prometheus Pushgateway, ELK) puissent générer des alertes.

Stockage d’objets et règles de cycle de vie (compatible S3)

Pour la conservation à long terme, le stockage d’objets présente des avantages de coût. Utilisez des règles de cycle de vie pour déplacer les objets vers des niveaux similaires à Glacier. Exemple d’une règle de cycle de vie (JSON) pour des buckets compatibles S3 :

{
  "Rules": [
    {
      "ID": "move-to-cold",
      "Filter": {"Prefix": "backup/old/"},
      "Status": "Enabled",
      "Transitions": [{"Days": 30, "StorageClass": "GLACIER"}],
      "Expiration": {"Days": 3650}
    }
  ]
}

Important : n’activez Object Lock (WORM) que pour les données qui doivent être irrévocablement conservées pour des raisons légales. Les règles de cycle de vie ne doivent pas supprimer automatiquement des copies juridiquement pertinentes sans validation humaine.

Analyse des risques : ransomware, corruption de données et erreurs d’opérateur

Les plans de rétention doivent anticiper les scénarios de risque. Les ransomwares tentent souvent de chiffrer ou de supprimer toutes les copies. Mesures :

• Stockage immuable ou Object Lock pour les sauvegardes critiques.
• Comptes admin séparés pour les systèmes de sauvegarde, MFA, et réseaux RESTreints pour les accès aux sauvegardes.
• Buckets de quarantaine et suppression différée (p. ex. 7–14 jours) pour pouvoir rattraper les suppressions accidentelles ou malveillantes.

En cas de corruption de données, les sommes de contrôle, une alerte immédiate et la possibilité d’accéder à des niveaux GFS plus anciens sont utiles.

Stratégie de rollback et runbook de récupération

Un runbook solide liste des étapes concrètes et testées pour une RESTauration et un éventuel rollback. Éléments importants :

1. Évaluation initiale de la situation : systèmes affectés, RTO/RPO, classes de données concernées.
2. Choix de la source de RESTauration : sauvegarde complète, réplicat ou copie hors site.
3. RESTauration de test en isolation et vérification de l’intégrité (sommes de contrôle, tests smoke applicatifs).
4. RESTauration en production pendant la fenêtre de maintenance avec plan de communication (notification des parties prenantes, informations aux utilisateurs).
5. Audit post‑RESTauration : comparaison des jeux de données, contrôles de cohérence et documentation des leçons tirées.

Définissez des niveaux de décision clairs : qui décide en cas d’échec des RESTaurations ? Quand bascule-t-on vers des sources alternatives (p. ex. réplicat) ?

Tests et audit : à quelle fréquence et avec quels critères d’acceptation ?

Fréquence des tests : échantillons rapides de RESTauration (hebdomadaire), RESTaurations complètes (mensuelle) et simulations de sinistre (annuelle). Les critères d’acceptation doivent être mesurables, p. ex. « RESTauration complète d’un schéma de base de données en < 4 heures » ou « PITR avec un RPO maximal de 15 minutes ». Documentez les écarts et leurs causes.

Pièges typiques et comment les éviter

• Métadonnées manquantes : conservez xtrabackup_info et checksums avec les données.
• Règles de suppression automatiques sans Dry‑Run : introduire systématiquement un Dry‑Run et une phase de quarantaine.
• Politiques de cycle de vie non testées : testez les migrations dans un environnement de bucket de staging.
• Suppression des binlogs sans rapprochement avec les réplicas : vérifiez le lag de réplication et les SLA avant d’effacer des binlogs.
• Pas de réserve de capacité : prévoyez pour les pics, pas seulement pour les moyennes.

Liste de contrôle pour la mise en place d’un plan de rétention (pratique)

1. Recenser : quelles classes de données sont pertinentes et quels délais légaux s’appliquent ?
2. Classer : définir et documenter RTO/RPO par classe de données.
3. Conception : définir le schéma GFS, les intervalles incrémentiels, les niveaux de stockage, l’Object Lock et la quarantaine.
4. Automatisation : mettre en place des scripts idempotents, des Dry‑Run, des timers systemd, des logs structurés et des alarmes.
5. Validation : instaurer des tests de RESTauration réguliers, des contrôles d’intégrité et du reporting.
6. Documentation : la Retention‑Policy en tant que document contraignant incluant les rôles et l’audit trail.
7. Revue : vérification périodique (p. ex. semestrielle) et mise à jour en cas d’évolution des exigences légales.

Conclusion : assurer la robustesse opérationnelle

Les plans de rétention relient conformité, rentabilité et sécurité opérationnelle. Concrètement cela signifie : GFS pour les besoins à long terme, chaînes incrémentielles limitées pour l’efficacité, contrôles d’intégrité automatisés et échantillons de RESTauration documentés pour la fiabilité. Pour MariaDB, la gestion des binlogs, l’intégrité des chaînes XtraBackup et des tests PITR réguliers sont des sujets clés. Testez les modifications en staging, conservez les opérations de suppression réversibles jusqu’à la vérification finale et mettez en place un monitoring avec des alertes claires.

Si vous respectez ces étapes, votre Retention‑Plan ne sera pas un document ponctuel mais un processus opérationnel vivant : automatisé, vérifiable et juridiquement sûr. Vous protégez ainsi vos données tout en assurant une conservation économiquement viable.

Ressources complémentaires

Des liens internes vers des articles approfondis (p. ex. tests de sauvegarde avec Ansible, résilience face aux ransomwares, MariaDB PITR) doivent être intégrés ici pour que les runbooks, playbooks et checklists d’audit soient directement accessibles.

Gestion de la rétention : métadonnées, Legal‑Hold et monitoring

Une partie souvent sous-estimée de la rétention est le catalogue des métadonnées : il documente quels lots de sauvegarde appartiennent à quelles classes de données, quels délais légaux, quels résultats de vérification et quelles clés de chiffrement. Sans un catalogue fiable, l’automatisation des suppressions devient dangereuse — car le système ne peut pas distinguer de manière sûre quelle copie est toujours sous Legal‑Hold ou pertinente pour un contrôle en cours.

Remarque d’architecture : séparez le repository de métadonnées des object stores. Utilisez une petite base de données hautement disponible (p. ex. un seul schéma MariaDB sécurisé au niveau du schéma ou un store orienté document) avec des entrées versionnées. Chaque lot de sauvegarde reçoit une UUID, un statut (available, quarantined, deleting, deleted), un owner et un legal_hold_flag. Ces informations pilotent la pipeline de suppression.

La suppression en deux phases réduit le risque : 1) marquer par un Tombstone et mettre en quarantaine (p. ex. 7–14 jours), 2) supprimer définitivement après réconciliation et audit réussis. Cela permet des Dry‑Runs, des interventions manuelles et des restaurations automatisées en cas d’erreur.

La surveillance opérationnelle doit fournir des indicateurs mesurables :

• Taux de conformité de rétention (objectif vs. constaté selon les délais)
• Nombre de Tombstones et ancienneté des Tombstones
• Erreurs de suppression par jour et délai jusqu’à résolution manuelle
• Discordance entre les métadonnées et le stockage réel (taux de réconciliation)

Exemple de requête (table des métadonnées backups):

-- Backups, die laut Policy bereits gelöscht sein sollten
SELECT id, uuid, created_at, retention_until, status
FROM backups
WHERE retention_until < NOW() AND status != 'deleted';
-- Tombstones älter als 14 Tage
SELECT COUNT(*) FROM backups WHERE status = 'quarantined' AND updated_at < NOW() - INTERVAL 14 DAY;

Autres points : gérer séparément la gestion des clés (KMS) pour les sauvegardes chiffrées et sous RBAC ; introduire des numéros de version pour les outils de sauvegarde et effectuer des vérifications de compatibilité lors des migrations. Enfin : intégrez les jobs de réconciliation dans votre runbook d’incident — notification automatique et procédure d’escalade par pager si le taux de réconciliation passe sous un seuil critique.

Pour ce sujet, les Mariadb Backups et la Binlog Retention sont également importants. Cet article replace ces aspects de manière claire et montre ce qui compte dans la pratique quotidienne.