Mise en place d’une rotation de sauvegardes GFS en entreprise – tutoriel simple et efficace

La rotation de sauvegardes GFS (Grandfather-Father-Son) est une méthode simple à comprendre et très efficace pour conserver des points de restauration sur plusieurs horizons (jours, semaines, mois) tout en maîtrisant la consommation de stockage. Elle ne remplace pas une stratégie de sauvegarde complète, mais structure intelligemment la rétention. L’objectif de ce guide est de vous aider à la déployer en PME avec un planning concret, des principes d’automatisation, et surtout les bonnes pratiques de contrôle et de test de restauration, souvent négligées alors qu’elles déterminent la réussite réelle d’un plan de reprise.

1) Comprendre la méthode GFS (en clair)

GFS repose sur trois niveaux de conservation, associés à des horizons de restauration différents. Le niveau “Son” correspond aux sauvegardes quotidiennes, utiles pour revenir sur un incident récent comme une suppression de fichier, une modification accidentelle ou un chiffrement détecté rapidement. Le niveau “Father” correspond aux sauvegardes hebdomadaires, pertinentes quand un problème se révèle après plusieurs jours, par exemple une corruption silencieuse, une erreur de paramétrage ou une altération non détectée immédiatement. Le niveau “Grandfather” correspond aux sauvegardes mensuelles, conçues pour les retours en arrière “historiques” nécessaires en cas d’audit, de litige, d’erreur identifiée tardivement ou d’exigence de traçabilité.

Le principe consiste à réutiliser des emplacements de sauvegarde selon une rotation : on conserve un nombre défini de points par niveau, puis on remplace les plus anciens. On obtient ainsi une profondeur d’historique cohérente, sans accumulation infinie.

Selon les outils, une sauvegarde hebdomadaire ou mensuelle peut être une exécution dédiée, souvent plus robuste pour le long terme, ou une “promotion” d’un point existant via un marquage, une copie ou un verrouillage. Les deux approches sont valides si elles garantissent une restauration fiable et si la politique de rétention ne casse pas les dépendances techniques (chaînes incrémentales, catalogues, métadonnées). Le point clé n’est pas le vocabulaire, mais la stabilité des points de restauration et la capacité à les récupérer dans le temps.

2) Définir un objectif réaliste : RPO, RTO et périmètre

Avant d’écrire un planning, il faut clarifier les objectifs, car GFS n’a de sens que s’il sert un besoin métier. Le RPO fixe la perte de données maximale acceptable : si une perte de 24 heures est tolérable, une sauvegarde quotidienne peut suffire ; si la perte doit être limitée à quelques heures, il faudra ajouter des sauvegardes intra-journalières ou des mécanismes applicatifs. Le RTO définit le délai de remise en service : restaurer en deux heures ou en une journée ne conduit pas aux mêmes choix d’architecture, de performance de stockage ou de priorité de restauration. Enfin, le périmètre doit être explicite : serveur de fichiers, VM, bases de données, postes, identités, applications SaaS (M365/Google Workspace), ERP, partages, configurations réseau et éléments de sécurité.

GFS s’applique particulièrement bien aux serveurs de fichiers et aux VM, et peut structurer la rétention de sauvegardes cloud, d’exports applicatifs ou de dumps de bases. Pour les bases transactionnelles, il faut toutefois compléter avec des mécanismes adaptés comme les sauvegardes applicatives cohérentes, les journaux de transactions et la restauration à un instant donné (PITR) lorsque le RPO/RTO est exigeant. Sans cela, une rotation GFS peut donner une illusion de sécurité tout en restant insuffisante pour la réalité d’un SI transactionnel.

3) Exemple de planning GFS “simple et efficace” pour une PME

Un modèle fréquemment pertinent et facile à expliquer consiste à conserver sept sauvegardes quotidiennes, quatre sauvegardes hebdomadaires et douze sauvegardes mensuelles. Ce schéma fournit une couverture claire : une semaine au jour le jour, environ un mois au rythme hebdomadaire et un an au rythme mensuel, sans multiplier les points au-delà du nécessaire.

Concrètement, une sauvegarde quotidienne est créée chaque nuit et la plus ancienne est remplacée lorsque le seuil est dépassé. En fin de semaine, on conserve un point hebdomadaire, soit en exécutant une sauvegarde dédiée, soit en promouvant un point quotidien, puis on remplace la plus ancienne hebdomadaire lorsque la limite est atteinte. En fin de mois, on conserve un point mensuel, avec la même logique de remplacement au-delà de douze versions.

Ce schéma ne garantit pas toujours la présence d’un point “exactement à J-7” ou “exactement à S-4” : il garantit plutôt une couverture par paliers. Le choix du jour de la sauvegarde hebdomadaire, la gestion des mois incomplets et les périodes de maintenance doivent être calés sur l’activité, idéalement avec des sauvegardes “cohérentes applicativement” quand les applications l’exigent. Si vous avez des obligations légales de conservation sur plusieurs années, GFS doit être étendu ou complété par de l’archivage conforme, car la sauvegarde n’est pas une politique d’archivage réglementaire.

4) Où stocker les rotations : règle 3-2-1 (et variante anti-ransomware)

GFS organise la rétention, mais ne suffit pas si toutes les copies vivent au même endroit ou sous les mêmes identités d’administration. Pour réduire le risque de panne, de vol, d’erreur humaine et surtout de ransomware, la logique 3-2-1 reste une base solide : disposer de plusieurs copies, sur des supports ou environnements distincts, avec au moins une copie hors site.

Dans une PME, une approche pragmatique consiste à conserver une cible locale rapide pour accélérer les restaurations courantes, typiquement les sauvegardes quotidiennes, et une cible hors site pour la résilience, a minima pour les hebdomadaires et mensuelles. Le hors site peut être un second site, un datacenter partenaire ou du stockage objet/cloud, à condition que le chiffrement et les contrôles d’accès soient sérieux.

Contre les ransomwares, l’élément décisif est d’empêcher la modification ou la suppression des sauvegardes par un attaquant ayant compromis le SI. L’immutabilité (WORM/Object Lock) est aujourd’hui l’une des protections les plus efficaces, mais elle n’est utile que si les identités et les droits sont bien cloisonnés : comptes de service dédiés, séparation stricte des comptes d’administration, MFA quand c’est applicable, absence de droits interactifs d’écriture, et idéalement un dépôt de sauvegarde qui ne dépend pas des mêmes mécanismes d’authentification que le domaine compromis. Dans les incidents réels, l’échec vient rarement de GFS, mais d’une cible accessible avec des droits trop larges.

5) Mise en place pratique : arborescence, nommage et règles de rétention

Que vous utilisiez un logiciel de sauvegarde ou des scripts, la lisibilité et l’auditabilité comptent. Une organisation par niveaux de rétention, ou des tags équivalents, permet de comprendre immédiatement ce qui est conservé et pourquoi. Une arborescence simple du type /backups/daily, /backups/weekly et /backups/monthly, avec des dossiers datés ou des identifiants de période, facilite le contrôle, à condition que la politique de rétention soit réellement appliquée par l’outil et pas uniquement “simulée” par des dossiers.

Un nommage stable et triable doit indiquer au minimum la source, le type de sauvegarde et la date. Il est utile d’ajouter le périmètre fonctionnel et l’environnement, afin d’éviter les confusions lors d’une restauration sous stress. Pour les environnements virtualisés et les bases de données, la cohérence des dépendances est un point non négociable : si votre stratégie repose sur de l’incrémental avec chaînes, la rétention doit être gérée de manière à ne pas rendre des points anciens inutilisables. Les solutions modernes gèrent souvent cela via des full synthétiques ou des modèles “forever incremental”, mais il faut le vérifier et le tester, pas le supposer.

6) Automatiser sans se compliquer la vie

Dans la plupart des cas, un logiciel de sauvegarde avec une politique GFS est l’option la plus fiable : vous bénéficiez des journaux, de l’alerting, des catalogues, du chiffrement, d’une restauration guidée et d’une gestion cohérente des dépendances. Les scripts restent utiles pour des cas spécifiques comme des exports applicatifs, des dumps SQL, des éléments métiers difficiles à capturer autrement ou des systèmes très particuliers. Dans ce cas, il faut documenter, versionner et éviter les bricolages non maintenables, car une automatisation fragile devient une dette opérationnelle.

Quelle que soit l’approche, la différence entre une sauvegarde “présente” et une sauvegarde “opérationnelle” repose sur quelques fondations : une fenêtre de sauvegarde alignée sur l’activité, un contrôle de l’impact (bande passante, I/O, priorités), un compte de service dédié avec droits minimaux, des alertes sur échec mais aussi sur absence de sauvegarde attendue, et un suivi de capacité pour anticiper la croissance des données et éviter les rétentions qui se dégradent en silence.

7) Vérification d’intégrité : ce qui évite les “mauvaises surprises”

Une sauvegarde “terminée” n’est pas une sauvegarde “restaurable”. Il faut distinguer la réussite d’un job et la qualité d’un point de restauration. Les contrôles d’intégrité par checksum/CRC, les tests de lecture, la validation du catalogue et la cohérence applicative quand elle est disponible doivent faire partie du cycle normal. Il est également essentiel de surveiller les tendances : une sauvegarde anormalement petite peut signaler des données non capturées, une sauvegarde anormalement grosse peut révéler une dérive ou un changement non maîtrisé, et des variations de durée ou de déduplication peuvent indiquer un incident en préparation.

Pour cadrer la démarche “backup & recovery” côté bonnes pratiques, les ressources NIST pour les petites entreprises constituent une base utile : https://www.nist.gov/itl/smallbusinesscyber.

8) Tests de restauration : le vrai critère de réussite

Le succès d’une stratégie GFS se mesure à votre capacité à restaurer vite et juste dans des scénarios réalistes : fichier supprimé, répertoire corrompu, VM inutilisable, panne de stockage, compromission ransomware. Les tests doivent être ritualisés, car sans répétition ils disparaissent de la routine et reviennent trop tard, au pire moment.

Une cadence raisonnable en PME consiste à restaurer régulièrement des éléments simples dans un espace de test et à réaliser périodiquement une restauration plus large, idéalement dans un environnement isolé, tout en mesurant le temps réel et en vérifiant l’exploitabilité. Après toute évolution majeure (migration, mise à jour, changement de stockage, modification de politique, changement d’authentification), un test de restauration complet s’impose, car c’est précisément dans ces périodes que les plans de sauvegarde se fragilisent.

La documentation est un livrable opérationnel, pas un confort : qui lance la restauration, avec quel compte, où se trouve la procédure, où restaurer, comment valider, quelles dépendances (clés de chiffrement, accès au hors site, paramètres applicatifs) et quels délais observés. En crise, la qualité de cette documentation fait souvent la différence entre un incident maîtrisé et une interruption prolongée.

9) Erreurs fréquentes (et comment les éviter)

La première erreur est de tout garder au même endroit, sous les mêmes droits. Si la cible est chiffrée, supprimée ou rendue inaccessible, la rotation ne sert plus à rien. La seconde est de confondre snapshots et sauvegardes : un snapshot est une facilité de retour arrière local, utile mais dépendante du stockage source, et ne remplace pas une copie hors site. Une autre cause fréquente d’échec est l’absence d’alerting fiable : un échec visible est gérable, une absence de sauvegarde qui passe inaperçue ne l’est pas. L’erreur la plus coûteuse reste l’absence de tests de restauration, car une sauvegarde non testée n’est qu’une hypothèse.

Il faut aussi éviter les rétentions “par habitude” qui gonflent la capacité sans bénéfice réel, et au contraire calibrer selon les besoins métiers, les contraintes de sécurité et les obligations de conservation. Enfin, il est vital de gérer les identités et les secrets : mots de passe, clés de chiffrement, procédures d’accès au hors site, et séparation des rôles. Le jour où l’on découvre qu’on ne peut pas déchiffrer ou qu’on ne peut pas se connecter au dépôt, il est trop tard.

10) Aller plus loin : compléter GFS avec une approche adaptée à votre contexte

GFS constitue un excellent socle, mais il doit être ajusté aux exigences réelles. Si votre RPO est inférieur à 24 heures pour des données actives, des sauvegardes intra-journalières ou des mécanismes applicatifs (journaux, PITR) deviennent nécessaires. Dans beaucoup d’environnements, la combinaison snapshots rapides pour des retours arrière immédiats et sauvegardes robustes, versionnées et hors site pour la résilience offre un bon équilibre, à condition de ne pas confondre les usages.

Le chiffrement des sauvegardes, en transit et au repos, doit être systématique, avec une gestion professionnelle des clés (accès restreints, stockage sécurisé, rotation quand c’est pertinent, procédure de récupération). Lorsque c’est possible, viser une approche de type 3-2-1-1-0 renforce nettement la résistance aux attaques : une copie offline ou immuable, et un objectif opérationnel de “zéro erreur” via vérification et tests réguliers. Pour comparer d’autres approches avant de trancher, vous pouvez aussi consulter cet article : Trois méthodes de sauvegarde de fichiers pour les toutes petites entreprises.

En définitive, GFS est juste et pertinent lorsqu’il est utilisé pour ce qu’il est vraiment : une discipline de rétention qui met de l’ordre dans le temps. Pour qu’il ait pleinement du sens en production, il doit être piloté par des objectifs RPO/RTO clairs, s’appuyer sur une architecture 3-2-1 renforcée par l’immutabilité ou un cloisonnement strict des accès, et être maintenu vivant par des contrôles d’intégrité et des tests de restauration réguliers. Une rotation bien pensée ne se juge pas au nombre de points conservés, mais à la certitude qu’un point restaurable existe au bon endroit, au bon moment, et que votre équipe sait le récupérer sous contrainte.