Tutoriel complet : mise en place d’une rotation de sauvegardes GFS en entreprise

Mettre en place une rotation de sauvegardes GFS (Grandfather-Father-Son) permet de concilier deux exigences souvent contradictoires en entreprise : disposer d’un historique suffisant pour se protéger des erreurs humaines, des incidents techniques et des attaques (dont le ransomware), tout en maîtrisant les coûts de stockage, les fenêtres de sauvegarde et les temps de restauration. L’objectif n’est pas d’appliquer une recette universelle, mais de déployer une stratégie compréhensible, testable et alignée sur vos priorités métier.

1) Comprendre la méthode GFS (Grandfather-Father-Son)

La rotation GFS organise les sauvegardes par niveaux de rétention. Les sauvegardes quotidiennes, dites “Son”, couvrent le besoin le plus fréquent : revenir rapidement sur une suppression ou une modification récente. Les sauvegardes hebdomadaires, dites “Father”, servent de points de restauration plus stables et utiles dès que l’on doit remonter au-delà de quelques jours. Les sauvegardes mensuelles, voire annuelles, dites “Grandfather”, répondent aux besoins de conservation long terme, d’audit, de preuves ou d’obligations contractuelles et réglementaires.

Le principe essentiel est de ne pas conserver la même granularité sur toute la durée. On multiplie les points proches dans le temps, puis on espace progressivement pour limiter la volumétrie sans perdre la capacité à remonter loin. GFS décrit une logique de conservation et s’applique aussi bien à des sauvegardes de fichiers qu’à des images de VM, des exports applicatifs, des sauvegardes de bases de données ou des copies sur stockage objet et sur bande.

2) Étape préalable : définir vos objectifs (RPO/RTO) et le périmètre

Avant toute configuration, il faut clarifier ce que l’on cherche à protéger et dans quels délais on doit être capable de revenir en arrière. Le RPO (Recovery Point Objective) correspond à la quantité maximale de données que l’entreprise accepte de perdre. Un RPO de vingt-quatre heures implique au minimum une sauvegarde quotidienne, mais un service critique peut imposer des sauvegardes plus fréquentes, notamment via des sauvegardes applicatives transactionnelles ou des mécanismes de journalisation. Le RTO (Recovery Time Objective) correspond au temps maximal acceptable pour remettre le service en état de fonctionnement. Il dépend de la méthode choisie, de l’architecture de restauration, des débits, de la performance du dépôt et de l’automatisation des procédures.

Le périmètre doit être explicitement défini : serveurs de fichiers, VM, bases de données, applications métiers, postes stratégiques, mais aussi services SaaS (Microsoft 365, Google Workspace, CRM). Une idée importante, souvent sous-estimée, est que le SaaS ne dispense pas de sauvegarde : la haute disponibilité n’est pas une stratégie de restauration granulaire, et la rétention native ne couvre pas toujours vos obligations ni vos scénarios de suppression ou de compromission.

Enfin, les exigences de conformité doivent être intégrées dès le départ : durées de conservation, localisation des données, chiffrement, preuve de restauration et exigences d’immutabilité. Pour un cadre de référence reconnu en continuité d’activité et reprise après sinistre, vous pouvez vous appuyer sur le guide NIST SP 800-34 Rev.1.

3) Choisir le schéma GFS : un exemple simple et efficace

Un modèle GFS classique et généralement efficace pour de nombreuses organisations est le schéma “7/4/12” : sept points quotidiens, quatre points hebdomadaires et douze points mensuels. Cette structure donne un bon équilibre entre capacité d’investigation, simplicité d’exploitation et coût de stockage. Elle sert de base saine, à ajuster ensuite selon la volumétrie, le taux de changement des données, les besoins réels de restauration et les contraintes métier.

Si votre contexte impose des obligations de conservation sur plusieurs années ou des besoins d’investigation longs, il est préférable d’ajouter un palier annuel explicite plutôt que d’étendre artificiellement le mensuel. Cela clarifie la politique, facilite l’audit et évite les incompréhensions lors d’un changement d’équipe ou d’outil.

4) Sauvegarde complète vs incrémentale : comment l’intégrer à GFS

GFS décrit la rétention, pas la technique de sauvegarde. Dans la pratique, la sauvegarde complète simplifie les restaurations mais consomme davantage de temps et d’espace. L’incrémentale réduit la fenêtre de sauvegarde et la volumétrie, mais introduit une dépendance à une chaîne ou à un mécanisme équivalent, ce qui exige une bonne maîtrise des vérifications et des réparations. La différentielle offre un compromis en restaurant plus simplement qu’une chaîne d’incrémentales tout en limitant le coût quotidien.

Une approche courante consiste à effectuer des sauvegardes quotidiennes incrémentales, à produire un point hebdomadaire complet ou un “synthetic full” si votre outil le supporte, puis à conserver un point mensuel complet, idéalement sur un stockage plus économique ou conçu pour l’archivage. Le point décisif n’est pas le vocabulaire, mais la capacité à restaurer dans votre RTO, y compris lorsque le dépôt est sous charge ou qu’un incident impose une restauration massive.

Il est également indispensable d’assurer la cohérence applicative. Une sauvegarde “réussie” n’est pas forcément exploitable : bases de données, annuaires, systèmes transactionnels et applications avec caches exigent VSS, quiescing, hooks applicatifs et gestion correcte des journaux de transactions selon les technologies utilisées.

5) Planifier concrètement : calendrier de rotation (exemple)

Un calendrier simple, compréhensible et durable est un atout opérationnel. Un exemple classique consiste à conserver un point quotidien les soirs de semaine, à promouvoir un point hebdomadaire en fin de semaine et à promouvoir un point mensuel sur la dernière exécution du mois. Il faut toutefois veiller à la logique réelle de votre outil : beaucoup de solutions ne nécessitent pas plusieurs tâches distinctes et gèrent la promotion hebdomadaire et mensuelle via une seule règle de rétention, ce qui réduit les erreurs de configuration.

En environnement 24/7, les sauvegardes lourdes en pleine journée doivent être évitées. Les snapshots, les mécanismes transactionnels, la limitation de bande passante et une orchestration adaptée permettent de réduire l’impact sur la production. L’essentiel est que le calendrier serve vos objectifs, et non l’inverse.

6) Mise en œuvre avec des outils courants (approche générique)

Quel que soit l’outil, la mise en œuvre robuste repose sur les mêmes principes. Il faut d’abord choisir et sécuriser le dépôt, puis définir une architecture cohérente avec le risque : un dépôt local pour la vitesse de restauration et une copie secondaire pour la résilience, en veillant à ce que le dépôt ne soit pas administrable avec les mêmes identifiants que la production. La configuration du job doit expliciter les sources, la fenêtre, la méthode de sauvegarde, la compression et le chiffrement, puis appliquer une politique de rétention GFS claire et vérifiable.

La copie secondaire ne doit pas être une simple option “au cas où”. Elle fait partie intégrante du design. La règle 3-2-1 reste une base solide, mais elle gagne à être complétée par une exigence désormais centrale : rendre au moins une copie difficile à altérer, via l’immutabilité (WORM, object lock) ou un isolement réel (air gap). Enfin, la restauration doit être testée dès le début, sur des scénarios représentatifs : fichier isolé, service applicatif, VM complète, base de données, et, si votre analyse de risque l’exige, un exercice de PRA incluant les dépendances critiques comme l’AD, le DNS ou les systèmes d’authentification.

7) Automatiser sans se faire piéger : notifications, accès, quotas, et nettoyage

L’automatisation est indispensable, mais une sauvegarde automatisée non surveillée est une sauvegarde “inconnue”. Les alertes doivent couvrir les échecs, les avertissements et les dérives de durée, car une sauvegarde qui dépasse sa fenêtre finit souvent par compromettre la suivante. La capacité doit être suivie avec des seuils et une projection de croissance, en tenant compte des pics liés aux points complets et à la rétention long terme.

Le nettoyage effectif est un sujet récurrent : il ne suffit pas d’afficher une rétention, il faut s’assurer que les points expirés sont réellement purgés, que les fichiers orphelins sont traités et que les chaînes restent cohérentes. La sécurité doit être traitée comme une composante structurelle : chiffrement en transit et au repos, gestion rigoureuse des clés, comptes dédiés, moindre privilège, MFA lorsque possible et séparation des rôles afin de réduire l’impact d’une compromission. La documentation, enfin, n’est pas un luxe : une politique de sauvegarde n’a de valeur opérationnelle que si l’équipe peut comprendre rapidement quoi restaurer, où et comment, y compris en situation d’urgence.

8) Vérifier l’intégrité : la partie souvent oubliée

Une sauvegarde n’a de valeur que si elle est restaurable dans les délais attendus. Les contrôles d’intégrité doivent être systématiques : checksums, health checks du dépôt, validation des chaînes et détection de corruption. Les tests de restauration doivent être planifiés et tracés, car une preuve de restauration est souvent plus utile qu’un rapport de “job success”. Il est pertinent de varier les scénarios et de mesurer les temps réels, puis de comparer aux RTO/RPO, afin d’identifier les écarts et d’appliquer des actions correctives.

Face au risque ransomware, la stratégie doit intégrer une copie immuable ou isolée et une gouvernance des identifiants empêchant la suppression ou l’altération des sauvegardes par un compte compromis. Sans cette couche, une rotation GFS peut parfaitement conserver un historique… tout en étant effaçable en quelques minutes.

9) Check-list de déploiement rapide (à copier-coller)

Validez des RPO/RTO réalistes avec le métier et alignez-les sur vos capacités techniques et votre budget. Définissez un périmètre exhaustif et priorisé, incluant les services SaaS et les dépendances critiques. Choisissez un schéma GFS clair, documentez les exceptions et ajoutez un palier annuel si vos obligations l’exigent. Assurez la cohérence applicative et la gestion des journaux pour les workloads transactionnels. Dimensionnez et sécurisez le dépôt avec chiffrement, moindre privilège, MFA lorsque possible et séparation des rôles. Mettez en place une copie hors site selon 3-2-1, idéalement avec immutabilité ou air gap. Activez et testez les alertes, la supervision de capacité et la purge effective des rétentions. Documentez la procédure de restauration et planifiez des tests réguliers avec journal de preuve et mesures de temps.

En définitive, une rotation GFS n’est pas seulement une règle de rétention : c’est un dispositif de résilience qui n’a de valeur que s’il est aligné sur des objectifs RPO/RTO validés, protégé contre l’altération, et démontré par des restaurations testées. Les actions clés sont simples à formuler et exigeantes à tenir : définir des objectifs réalistes, réduire le risque de compromission du dépôt, garantir une copie immuable ou isolée, et transformer la sauvegarde en capacité prouvée de restauration. C’est cette discipline, plus que le schéma lui-même, qui fait la différence le jour où l’incident survient.