Mise en place réussie d’une rotation de sauvegardes GFS — tutoriel pour PME novices

Quand une PME commence à structurer ses sauvegardes, le premier piège est presque toujours le même : on fait des copies « quand on y pense », puis on manque d’historique le jour où un fichier a été altéré il y a trois semaines, ou bien on sature le stockage de sauvegarde en quelques mois. La rotation GFS (Grandfather-Father-Son) est une méthode simple et éprouvée pour organiser des points de restauration à plusieurs profondeurs temporelles, en conservant des sauvegardes journalières, hebdomadaires et mensuelles de façon lisible, tout en gardant la volumétrie sous contrôle. Il faut toutefois être clair : GFS ne remplace pas une stratégie de sauvegarde. C’est un schéma de rétention. Sans périmètre défini, stockage adapté, sécurité, supervision et tests de restauration, une rotation « correcte sur le papier » peut échouer le jour où l’on en a réellement besoin.

## GFS, c’est quoi exactement (et pourquoi c’est efficace en entreprise) ?

GFS est un schéma de rotation qui classe les sauvegardes par générations afin de couvrir plusieurs horizons de restauration. La génération « Son » correspond aux points quotidiens, très utiles pour récupérer un document supprimé la veille ou revenir sur une modification récente. La génération « Father » correspond aux points hebdomadaires, qui permettent de revenir avant une erreur passée inaperçue quelques jours. La génération « Grandfather » correspond aux points mensuels, utilisés pour des restaurations plus anciennes, des besoins d’audit ou des incidents détectés tardivement.

L’intérêt majeur est d’obtenir un historique « en éventail » : dense sur les derniers jours, puis plus espacé au fil du temps. On évite ainsi de multiplier indéfiniment les sauvegardes quotidiennes tout en gardant des jalons fiables sur la durée. Il est également important de ne pas confondre la logique GFS avec la technique de sauvegarde : selon l’outil, un « point » peut être une sauvegarde complète, incrémentale, différentielle, ou un snapshot copié ensuite vers un dépôt de sauvegarde. Ce qui compte n’est pas le nom, mais l’existence de points réellement restaurables à différents âges, et leur conservation conforme à l’objectif.

## Définir une politique GFS réaliste pour une PME (exemple concret)

Avant de configurer un logiciel, il faut poser une politique compréhensible par l’équipe IT et validée par la direction, car la rétention est un arbitrage entre risque, coût et contraintes opérationnelles. Un standard souvent pertinent en PME consiste à conserver 7 points journaliers, 4 points hebdomadaires et 12 points mensuels. Cette base fonctionne bien pour beaucoup d’environnements, à condition de l’ajuster ensuite en fonction des usages réels et des retours d’expérience lors de restaurations.

Cette politique doit être adaptée à plusieurs paramètres concrets. Les contraintes légales et contractuelles peuvent imposer de conserver certains documents longtemps, mais il est essentiel de distinguer sauvegarde et archivage : une sauvegarde sert d’abord à restaurer après incident, alors que l’archivage vise la conservation probante et la consultation dans le temps, souvent avec des règles de conservation et d’accès différentes. La volumétrie et sa croissance doivent être anticipées, car une politique « raisonnable » aujourd’hui peut devenir intenable en un an si les données doublent. Les objectifs RPO/RTO doivent aussi être explicités : combien de données peut-on perdre et en combien de temps doit-on reprendre l’activité. Enfin, l’exposition au ransomware doit peser fortement dans la conception, car une rétention parfaite ne sert à rien si l’attaquant parvient à chiffrer ou supprimer le dépôt de sauvegarde.

Un bon réflexe consiste à démarrer avec une politique simple, puis à l’ajuster après quelques semaines sur la base d’éléments factuels : demandes de restauration, durées des jobs, fenêtres disponibles, consommation de stockage et incidents observés.

## Choisir le support et l’emplacement : local, NAS, cloud… et règle 3-2-1

GFS décrit la rotation, pas l’emplacement. Pour qu’une rotation ait du sens face aux pannes, aux erreurs humaines et aux attaques, elle doit s’inscrire dans une architecture de stockage résiliente. La règle 3-2-1 reste une référence pragmatique : disposer d’au moins trois copies des données, sur deux types de supports différents, dont une copie hors site.

En pratique, cela signifie généralement des données en production, une sauvegarde locale pour restaurer vite, et une copie externalisée sur un autre site ou dans le cloud. Cette troisième copie doit être pensée comme une « assurance catastrophe », capable de survivre à un sinistre de site (incendie, vol, dégât des eaux) ou à une compromission du réseau interne.

Pour être réellement utile en contexte ransomware, cette architecture gagne à intégrer une notion d’immutabilité ou, à défaut, une isolation forte. Une copie immuable (WORM, Object Lock, snapshots immuables selon les technologies, bande) empêche la suppression ou la modification des sauvegardes pendant une durée donnée. Si l’immutabilité n’est pas disponible, il faut au minimum réduire la surface d’attaque avec des comptes dédiés, des droits minimaux, une segmentation réseau et une séparation claire entre administration système et administration sauvegarde. Sans cela, une attaque qui atteint l’outil de sauvegarde ou ses identifiants peut neutraliser l’ensemble des points GFS.

## Mise en place : comment traduire GFS dans des outils courants

Beaucoup d’outils savent appliquer une logique proche de GFS, même si le terme n’est pas toujours affiché. L’essentiel est de vérifier, d’une part, la rétention réelle (combien de temps chaque catégorie est conservée) et, d’autre part, la nature du point de restauration (est-il autonome, exporté, vérifié, et restaurable même en cas de panne du stockage primaire). Il faut aussi clarifier ce que l’outil appelle « sauvegarde » : certains mécanismes reposent sur des instantanés locaux qui protègent bien contre une suppression accidentelle, mais ne constituent pas une protection suffisante contre la perte du stockage ou l’indisponibilité du site.

### Cas A — Sauvegarde d’un serveur de fichiers (Windows/Linux) avec snapshots et copie

Les snapshots sont très efficaces pour des retours rapides, notamment en cas de suppression accidentelle ou d’incident sur les dernières heures ou les derniers jours. En revanche, un snapshot n’est pas une sauvegarde hors site et dépend généralement du même stockage ; il ne doit donc pas être l’unique ligne de défense.

Une mise en œuvre robuste consiste à combiner snapshots pour le court terme et copie de sauvegarde vers un dépôt distinct pour la résilience. Dans cette approche, on peut appliquer une rétention de type GFS aux snapshots, tout en s’assurant que les données sont également exportées régulièrement vers un autre système ou un stockage cloud, avec versioning et, si possible, immutabilité. Le point déterminant reste la capacité à restaurer après perte du NAS ou compromission du site, ce que des snapshots seuls ne garantissent pas.

### Cas B — Sauvegarde de VM et serveurs avec un logiciel de backup

Les suites de sauvegarde proposent en général des politiques de rétention, des jobs planifiés et des mécanismes de sauvegarde complète et incrémentale, parfois avec « synthetic full ». L’objectif, dans une logique GFS, est d’obtenir des points quotidiens et des points hebdomadaires et mensuels identifiables et conservés plus longtemps. Selon l’outil, cela se fait via une option GFS native, via des marqueurs, ou via des jobs distincts ciblant des répertoires ou dépôts différents.

Un point souvent sous-estimé concerne les applications et en particulier les bases de données. Une sauvegarde qui « tourne » n’est pas nécessairement cohérente au moment de la restauration. Il faut vérifier la cohérence applicative (VSS, agents, mécanismes de quiesce, sauvegarde des journaux de transactions) et la procédure de restauration complète, car c’est elle qui conditionne la reprise réelle. De la même manière, si l’entreprise dépend de services SaaS (messagerie, partage de fichiers, CRM), il ne faut pas supposer que la rétention native du fournisseur suffit : une vraie stratégie doit décider explicitement si et comment ces données sont sauvegardées et restaurables.

## Automatiser sans exploser le stockage : incrémental, déduplication, compression

La contrainte la plus visible en PME reste souvent l’espace disque et la durée des sauvegardes. Les sauvegardes incrémentales limitent la copie aux changements après une première base complète, ce qui réduit fortement les volumes et les fenêtres de sauvegarde, à condition de maîtriser la durée de restauration et la robustesse de la chaîne selon les outils. La déduplication devient particulièrement intéressante quand plusieurs machines contiennent des données similaires ou lorsque l’on conserve un historique long, tandis que la compression apporte un gain variable selon la nature des fichiers.

La discipline la plus rentable consiste aussi à définir ce qui mérite réellement d’être sauvegardé. Exclure les caches, temporaires, contenus de test ou données facilement reconstituables évite de consommer de la capacité et du temps de traitement inutilement, mais ces exclusions doivent être documentées et validées avec les métiers pour éviter de découvrir trop tard qu’un répertoire « non critique » était en réalité indispensable.

Dès le démarrage, deux indicateurs doivent être suivis de près : la croissance du dépôt de sauvegarde et la durée des jobs. Si les sauvegardes empiètent sur les heures ouvrées, il faut ajuster la fenêtre, le parallélisme, la bande passante, la granularité des jobs ou la stratégie de rétention, plutôt que d’attendre la saturation ou les échecs.

## Vérification et tests de restauration : la partie que tout le monde oublie

Une rotation GFS correctement configurée mais jamais testée reste un pari. La supervision doit s’appuyer sur des alertes exploitables, des rapports consultés et un traitement des erreurs, en particulier pour la copie hors site, souvent la première à échouer sans bruit lorsqu’un lien réseau ou un quota se dégrade.

Les tests de restauration doivent être réguliers et proportionnés. Restaurer fréquemment un fichier de manière contrôlée permet de valider la chaîne de bout en bout et de maintenir les bons réflexes. Périodiquement, il faut aller plus loin avec une restauration d’un périmètre significatif, comme un dossier complet ou une VM, idéalement dans un environnement isolé. À un rythme défini, un exercice plus proche d’un scénario de crise doit confirmer que les objectifs RPO/RTO sont atteignables, que les accès au dépôt hors site sont maîtrisés, et que les étapes de reprise sont connues.

La documentation est un élément de sécurité à part entière. Elle doit préciser où restaurer, qui a les droits, comment accéder aux dépôts et aux comptes cloud, où se trouvent les clés et mots de passe, et comment contacter un prestataire. Cette documentation doit elle-même être accessible en cas d’incident majeur, donc conservée hors du système d’information habituel.

## Checklist de déploiement GFS (PME novice)

Pour qu’une rotation GFS prenne tout son sens, elle doit être rattachée à des décisions simples et vérifiables : définir une politique de rétention réaliste et la faire valider, cadrer le périmètre à protéger en fonction des priorités métiers, disposer d’un dépôt local pour restaurer vite et d’une copie hors site réellement indépendante, idéalement immuable ou fortement isolée, puis automatiser avec supervision et alertes. La sécurité doit être intégrée dès le départ avec chiffrement quand il est disponible, comptes dédiés et séparation des privilèges, car la sauvegarde est une cible privilégiée. Enfin, la restauration doit être testée et la procédure écrite, puis la politique revue régulièrement à la lumière de la volumétrie, des incidents et des résultats de tests.

En conclusion, GFS est une excellente méthode pour structurer la rétention sans complexifier inutilement l’exploitation, mais elle n’est efficace que si elle s’inscrit dans une stratégie complète. Les actions clés sont de formaliser une rétention compréhensible, de l’ancrer dans une architecture 3-2-1 avec une copie hors site résistante aux ransomwares, de sécuriser les accès au dépôt de sauvegarde et de tester la restauration jusqu’à pouvoir mesurer RPO et RTO. Ce n’est pas la présence de sauvegardes qui protège l’entreprise, mais la capacité prouvée à restaurer rapidement et proprement quand l’incident survient.