Tutoriel : mise en place d’une rotation de sauvegardes GFS pour débutants en entreprise
Commentaires fermés sur Tutoriel : mise en place d’une rotation de sauvegardes GFS pour débutants en entreprise Mettre en place une rotation de sauvegardes de type GFS (Grandfather-Father-Son) permet de concilier deux besoins souvent en tension en entreprise : conserver suffisamment d’historique pour revenir en arrière après une erreur humaine, une corruption ou une attaque par ransomware, tout en maîtrisant l’espace disque, la charge réseau et les coûts. L’approche est simple, mais elle n’a de valeur que si elle s’inscrit dans une stratégie globale de sauvegarde, avec des objectifs de reprise clairs, une copie réellement isolée et des restaurations régulièrement testées.
1) Comprendre la logique GFS (Grandfather-Father-Son)
La méthode GFS organise les points de restauration selon trois niveaux d’ancienneté : des sauvegardes quotidiennes (« fils ») pour les retours rapides, des sauvegardes hebdomadaires (« pères ») pour remonter plus loin sans conserver chaque jour, et des sauvegardes mensuelles (« grands-pères ») pour une conservation longue. L’idée centrale n’est pas de tout garder, mais de conserver des jalons utiles et lisibles dans le temps.
Dans la pratique, certains points sont « promus » selon un calendrier. Selon les outils, cette promotion correspond soit à un marquage de points existants (tags GFS), soit à la création d’un point dédié. Dans les deux cas, l’objectif est identique : disposer d’un historique structuré, avec des points quotidiens, hebdomadaires et mensuels clairement identifiables, et une suppression automatique des points devenus inutiles selon la politique de rétention.
Il faut toutefois garder une nuance essentielle : GFS décrit une logique de conservation, pas une garantie de récupérabilité. La récupération dépend aussi du type de sauvegarde (image, fichier, applicative), de l’intégrité du dépôt, de l’isolation face au ransomware et de la capacité réelle à restaurer dans les délais attendus.
2) Définir votre politique de rétention (un exemple prêt à l’emploi)
Avant de configurer un outil, formalisez une politique de rétention simple et validée à la fois par l’IT et les métiers, car ce sont les exigences opérationnelles et légales qui dictent la durée de conservation. Un schéma courant pour une PME consiste à conserver 7 sauvegardes quotidiennes, 4 sauvegardes hebdomadaires et 12 sauvegardes mensuelles. Ce compromis est souvent suffisant pour couvrir les incidents du quotidien et les retours arrière à moyen terme sans exploser le stockage.
Ce modèle doit cependant être ajusté au contexte. Des contraintes réglementaires ou contractuelles peuvent imposer des durées plus longues, et il est fréquent d’ajouter un niveau annuel lorsque l’objectif devient de l’archivage. Il est aussi important de distinguer rétention et archivage : l’archivage vise souvent l’inaltérabilité, la traçabilité et parfois des formats pérennes, alors que la rétention de sauvegarde vise avant tout la restauration opérationnelle.
Pour optimiser la capacité, les sauvegardes incrémentales avec synthèse et la déduplication sont pertinentes, mais elles augmentent la sensibilité à l’intégrité du dépôt : si le stockage ou les métadonnées sont corrompus, l’impact peut être plus large qu’avec des sauvegardes pleinement indépendantes. Cela renforce la nécessité de vérifications d’intégrité régulières et d’une copie secondaire séparée.
3) Choisir le support et l’emplacement (local, NAS, cloud)
GFS n’est qu’une rotation ; il faut l’inscrire dans une stratégie de résilience. Un minimum réaliste en entreprise consiste à viser l’esprit du 3-2-1 : plusieurs copies, sur des supports ou emplacements distincts, dont au moins une copie hors site ou réellement isolée. Concrètement, une copie locale permet des restaurations rapides, tandis qu’une copie séparée protège contre les scénarios graves comme le ransomware, le vol, l’incendie ou une compromission des comptes.
Un NAS peut constituer un premier palier simple et efficace pour une copie locale, mais il ne doit pas être confondu avec une sauvegarde. Le RAID protège contre la panne d’un disque, pas contre la suppression, la corruption logique, la compromission d’identifiants ou le chiffrement par ransomware. Dès que l’enjeu devient sérieux, la seconde copie doit être conçue pour résister à l’attaquant : stockage immuable (WORM/object lock), bandes correctement gérées, ou réplication vers un site secondaire ou du cloud avec séparation stricte des droits et des identités.
Pour comprendre les usages et limites d’un NAS, vous pouvez consulter cet article : Comment marche un serveur NAS : fonctionnalités et usages.
4) Planification : à quels moments créer les « sons », « fathers » et « grandfathers »
Une planification simple consiste à produire une sauvegarde quotidienne les soirs ouvrés, à marquer une sauvegarde de fin de semaine comme point hebdomadaire, puis à marquer une sauvegarde hebdomadaire comme point mensuel sur la dernière semaine du mois. Cette logique fonctionne bien tant que le créneau choisi capture un état cohérent des données et ne perturbe pas l’activité.
Le point déterminant n’est pas le jour exact, mais l’alignement avec vos traitements métiers. Si des clôtures, importations ou batch critiques se déroulent le vendredi soir, déplacez le jalon hebdomadaire. Une sauvegarde planifiée au mauvais moment peut être « réussie » techniquement tout en étant inexploitable fonctionnellement, parce qu’elle capture des bases en cours de traitement ou des données partiellement mises à jour.
Selon les outils, cette planification se fait via des tâches distinctes (quotidienne/hebdomadaire/mensuelle) sur un même dépôt, ou via une politique GFS intégrée. Dans tous les cas, vérifiez précisément la sémantique de l’outil : certains produits « taguent » des points existants, d’autres créent des points supplémentaires, ce qui change l’impact sur la capacité et la fenêtre de sauvegarde.
5) Configuration avec des outils « simples » (principe générique)
Les interfaces diffèrent selon les solutions, mais les principes restent constants. Définissez d’abord le périmètre en identifiant les systèmes critiques et leurs dépendances : application, base de données, fichiers et configuration. Choisissez ensuite le bon type de sauvegarde. Pour des serveurs et des VM, une sauvegarde image est utile pour redémarrer vite, mais elle doit être cohérente applicativement : la prise en compte de VSS, du quiescing ou de mécanismes applicatifs dédiés est préférable à un simple snapshot si vous voulez garantir une restauration fiable.
Le chiffrement au repos est indispensable dès qu’un dépôt peut être exposé (NAS accessible, cloud, site secondaire). La sécurité ne se limite pas à cocher une option : la gestion des clés, la restriction des accès et la séparation des rôles comptent autant que l’algorithme. Côté optimisation, la compression est généralement peu risquée, tandis que la déduplication doit être évaluée selon le profil de données et la criticité du dépôt.
Activez ensuite la rétention GFS en définissant clairement le nombre de points quotidiens, hebdomadaires et mensuels, puis vérifiez le comportement réel de purge et de conservation. Enfin, concevez la cible de sauvegarde avec une logique de moindre privilège : dépôt dédié, comptes distincts, ACL strictes et, si possible, un mode empêchant la modification ou la suppression des points de sauvegarde par un compte compromis.
Face au ransomware, le piège classique est de laisser les serveurs de production écrire librement sur le dépôt avec des droits de suppression. Le dépôt doit être protégé contre la production autant que contre l’extérieur. Quand c’est possible, une approche de type « écriture autorisée, suppression interdite » côté production, et suppression réservée à un compte d’administration séparé, réduit fortement le risque qu’un attaquant efface vos sauvegardes après avoir chiffré vos données.
6) Automatiser la supervision : ne pas « croire », vérifier
Une rotation GFS ne sert à rien si elle n’est pas suivie. La supervision doit couvrir les échecs, mais aussi les succès, car un job peut se terminer « correctement » tout en sauvegardant un périmètre incomplet, en sautant une VM, en tronquant des fichiers ou en s’appuyant sur un dépôt dégradé. Des notifications vers email ou messagerie d’équipe, associées à une revue régulière, évitent que les dérives s’installent.
Un tableau de bord simple, revu chaque semaine, permet de piloter la capacité, la tendance de croissance, la durée des jobs et l’état de la copie secondaire. Conservez également des journaux suffisamment longtemps pour diagnostiquer, et corrélez les incidents avec les changements d’environnement : patchs, modifications réseau, changements d’ACL, renouvellement de certificats ou rotation de mots de passe.
Pour structurer vos contrôles et vos exigences internes, les publications du NIST offrent des repères solides en cybersécurité, continuité et gestion des risques, sans imposer un outil particulier.
7) Vérifier l’intégrité et tester la restauration (l’étape que beaucoup oublient)
Une sauvegarde non restaurée n’est pas une preuve, c’est une hypothèse. Pour sécuriser réellement une rotation GFS, activez les mécanismes de vérification d’intégrité disponibles : health checks, vérification de hash, validation de dépôt, contrôles de cohérence applicative. Ces contrôles ne remplacent pas une restauration, mais ils réduisent le risque de découvrir un dépôt corrompu le jour d’un incident.
Planifiez des tests réguliers. Une restauration mensuelle d’un fichier puis d’une VM ou d’un serveur en environnement de test permet de mesurer le temps réel, de valider les procédures et de vérifier que les accès, clés et dépendances sont bien maîtrisés. Des exercices plus complets, par exemple trimestriels, gagnent à simuler des scénarios réalistes comme une suppression massive ou un chiffrement, en vérifiant explicitement la capacité à restaurer un point quotidien, hebdomadaire et mensuel, car les besoins ne sont pas les mêmes selon la date de l’incident.
Documentez des objectifs simples de RPO (perte de données acceptable) et de RTO (temps de reprise). Ces deux notions donnent du sens à la fréquence des sauvegardes, au niveau d’isolation et au budget stockage, et elles évitent de surdimensionner à l’aveugle ou, au contraire, de découvrir trop tard que l’organisation ne peut pas reprendre dans les délais attendus.
8) Mémo opérationnel (à intégrer à votre procédure)
Votre procédure doit formaliser une politique GFS validée et comprise, cohérente avec vos objectifs RPO et RTO. Le dépôt doit être dédié, chiffré et protégé par des droits minimaux, et une copie secondaire réellement séparée doit exister, idéalement avec immutabilité. La supervision doit être active et revue, les vérifications d’intégrité planifiées, et les restaurations testées et documentées de façon régulière, en incluant des scénarios proches du réel.
En résumé, GFS donne une structure claire à l’historique de sauvegarde, mais sa valeur se joue ailleurs : dans une rétention alignée sur le métier, un dépôt protégé contre la production et le ransomware, une copie isolée qui résiste à la compromission, et des restaurations prouvées par des tests. Si vous ne deviez retenir qu’une action clé, ce serait celle-ci : concevoir la sauvegarde en pensant d’abord à la restauration, puis vérifier systématiquement que vous savez réellement restaurer quand tout va mal.


