Tutoriel pour mettre en place une rotation de sauvegardes avec la méthode GFS en entreprise

Mettre en place une rotation de sauvegardes fiable fait souvent la différence entre une copie « au cas où » et une véritable capacité de continuité et de reprise d’activité. La méthode GFS (Grandfather–Father–Son) reste une approche classique, facile à expliquer et particulièrement adaptée aux PME : elle structure la conservation de points de restauration à court, moyen et long terme, ce qui permet de couvrir à la fois les incidents récents (suppression, corruption, ransomware) et les exigences de conservation (audit, obligations internes ou réglementaires). GFS n’est toutefois pertinente que si elle est alignée sur vos objectifs de reprise, correctement automatisée, protégée contre la compromission et régulièrement éprouvée par des restaurations.

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

Le principe consiste à organiser plusieurs niveaux de rétention dans le temps, avec des sauvegardes qui se renouvellent selon une fréquence définie. Le niveau « Son » correspond aux sauvegardes quotidiennes, souvent incrémentales, conservées quelques jours. Le niveau « Father » regroupe des sauvegardes hebdomadaires, généralement complètes ou synthétiques, conservées plusieurs semaines. Le niveau « Grandfather » correspond aux sauvegardes mensuelles, en pratique des sauvegardes complètes ou des hebdomadaires « promues », conservées plusieurs mois, voire davantage selon vos besoins.

Concrètement, vous produisez des points de restauration quotidiens. À la fin de la semaine, un point devient la référence hebdomadaire. À la fin du mois, une hebdomadaire est conservée plus longtemps en tant que mensuelle. Il est important de comprendre que GFS décrit une logique de conservation dans le temps, pas un format de sauvegarde : selon l’outil, la mise en œuvre peut s’appuyer sur des sauvegardes complètes, incrémentales, synthétiques, avec ou sans déduplication.

2) Définir vos objectifs : RPO, RTO et rétention

Avant de configurer quoi que ce soit, il faut clarifier trois repères qui conditionnent la pertinence d’un schéma GFS. Le RPO (Recovery Point Objective) correspond à la perte de données maximale acceptable, par exemple « au pire 24 heures ». Le RTO (Recovery Time Objective) correspond au délai maximal de remise en service, par exemple « service rétabli en 4 heures ». La rétention définit combien de temps vous conservez des points de restauration et à quel niveau de granularité, par exemple « 7 quotidiens, 5 hebdomadaires, 12 mensuels ».

Ces éléments guident le choix entre incrémental et complet, la fréquence des sauvegardes, la capacité de stockage, le débit nécessaire vers un site distant ou un cloud, ainsi que le degré d’automatisation. Sans objectifs explicites, on se retrouve fréquemment avec une rotation « qui tourne » mais incapable de tenir un RTO réaliste, ou au contraire surdimensionnée et coûteuse sans bénéfice réel.

3) Exemple de planning GFS prêt à l’emploi (PME)

Un planning simple et robuste pour une PME consiste à exécuter chaque nuit une sauvegarde incrémentale conservée 7 jours, à produire chaque semaine une sauvegarde complète (ou une « full synthétique ») conservée 5 semaines, puis à conserver une sauvegarde mensuelle pendant 12 mois, par exemple celle du premier week-end du mois. Ce schéma est lisible, facile à défendre et couvre la majorité des besoins courants.

Si l’espace manque, l’association « incrémentales quotidiennes + complète hebdomadaire » est souvent un bon compromis, à condition de bien maîtriser la chaîne de dépendances et la cohérence de la rétention. À l’inverse, réaliser des complètes quotidiennes simplifie parfois la restauration, mais augmente rapidement les besoins de stockage et la fenêtre de sauvegarde. Quel que soit le choix, vérifiez comment votre solution gère les dépendances : une rétention mal paramétrée peut supprimer une sauvegarde de base et rendre des incrémentales restantes inutilisables, ce qui revient à croire que l’on est protégé alors qu’on ne l’est pas.

4) Mise en œuvre pratique : organisation des dossiers et nommage

Une organisation claire réduit les erreurs humaines, surtout en situation de stress. Si votre logiciel n’impose pas sa propre structure, séparer les dépôts par périodicité aide à s’y retrouver rapidement, par exemple en distinguant des emplacements « daily », « weekly » et « monthly ». Un nommage stable avec date au format ISO facilite l’identification et l’audit, notamment lorsqu’il faut comparer des points de restauration ou retrouver une version précise.

Dans un contexte multi-périmètres, il est tout aussi important d’identifier explicitement la source sauvegardée, qu’il s’agisse d’un serveur de fichiers, d’une VM, d’un annuaire ou d’une base de données. La lisibilité n’est pas un luxe : lors d’un incident, choisir vite la bonne sauvegarde compte autant que l’avoir produite.

5) Configuration avec des outils courants (logique universelle)

La GFS est une politique que vous appliquez avec un outil, qu’il s’agisse d’une solution de sauvegarde d’entreprise, d’un logiciel open source, d’un NAS ou d’une combinaison de scripts et de snapshots. Dans tous les cas, l’essentiel est de s’assurer que la planification couvre bien les cycles quotidien, hebdomadaire et mensuel, que la rétention est automatisée et fiable, que la journalisation permet d’exploiter les erreurs sans ambiguïté, et que le chiffrement est effectivement activé, au repos et idéalement en transit.

Il faut aussi distinguer correctement dépôt de sauvegarde, snapshots et réplication. Un snapshot protège surtout contre un incident logique récent sur un stockage donné, mais ne constitue pas à lui seul une sauvegarde hors périmètre de compromission. Une réplication améliore la disponibilité, mais peut répliquer une suppression ou un chiffrement si elle n’est pas conçue avec des points immuables ou des versions. Une stratégie solide combine ces mécanismes au lieu de les confondre.

6) Automatiser la rotation (et éviter les oublis)

Deux choses font échouer les plans pourtant « bons sur le papier » : l’oubli et l’absence de contrôle. L’automatisation doit couvrir la création des sauvegardes, la purge selon la rétention et l’alerte en cas d’échec ou d’absence d’exécution attendue. Sans expiration automatique, l’espace se remplit et le système finit par tomber en panne au pire moment, souvent sans que personne ne s’en rende compte.

Sur le plan organisationnel, il est préférable que les rapports et alertes ne dépendent pas d’une seule personne. Une synthèse régulière envoyée à une boîte partagée (IT et référent métier) et un responsable clairement désigné pour le traitement des alertes rendent la stratégie réellement opérationnelle. L’objectif n’est pas d’accumuler des notifications, mais de garantir qu’un échec déclenche une action, avec un délai de réaction compatible avec vos RPO et RTO.

7) Gérer l’espace disque : capacité, croissance et déduplication

Le dimensionnement se fait d’abord à partir du volume de données, du taux de changement quotidien et de la rétention visée. À partir de là, la compression, la déduplication, les sauvegardes incrémentales et les mécanismes synthétiques peuvent réduire fortement l’empreinte, mais ils ont un impact sur la durée des traitements et parfois sur les temps de restauration. Il faut donc vérifier les performances en conditions réelles, car un plan qui économise du stockage mais ne tient pas le RTO reste un plan défaillant.

La capacité doit aussi intégrer la croissance naturelle des données et une marge de sécurité, sans quoi la rétention devient la variable d’ajustement implicite lorsque les volumes augmentent. Surveiller l’usage, poser des seuils d’alerte et réévaluer périodiquement les besoins évite les ajustements d’urgence qui fragilisent la chaîne de sauvegarde.

8) Tester la restauration : l’étape indispensable

Une sauvegarde non restaurée n’est pas une preuve de protection. Les tests doivent vérifier la capacité à récupérer des données mais aussi la capacité à remettre en service dans des délais acceptables. Un test mensuel simple, consistant à restaurer un dossier représentatif dans un emplacement temporaire et à valider son contenu, détecte déjà une grande partie des problèmes. Un test plus ambitieux, trimestriel ou semestriel selon criticité, devrait viser la restauration d’une machine ou d’un service dans un environnement de test afin de mesurer le temps réel et d’identifier les dépendances oubliées.

La restauration doit être documentée : quoi restaurer, où, qui valide et combien de temps cela prend. Pour les applications, il faut intégrer les contraintes spécifiques, notamment la cohérence transactionnelle des bases de données, les journaux, et les mécanismes « application-aware » quand ils existent. Ce travail est souvent ce qui transforme une sauvegarde « présente » en reprise réellement exploitable le jour où l’incident survient.

9) Bonnes pratiques de sécurité (résilience ransomware)

La rotation GFS n’a de sens que si la sauvegarde résiste à une compromission. La règle 3-2-1 reste une base saine : multiplier les copies, diversifier les supports et conserver au moins une copie hors site ou, plus exactement, hors domaine de compromission. L’immutabilité ou des mécanismes WORM, lorsqu’ils sont disponibles, limitent les suppressions et altérations malveillantes. Les comptes de sauvegarde doivent être dédiés et restreints au strict nécessaire, avec une authentification renforcée pour l’administration.

L’isolation du dépôt est tout aussi déterminante : limiter les accès réseau, segmenter, éviter les partages accessibles en écriture depuis des postes utilisateurs et réduire la surface d’attaque. Enfin, la supervision doit aller au-delà du simple succès/échec : des volumes anormalement élevés de données modifiées, des échecs répétés ou une désactivation de tâches peuvent être des signaux faibles d’un ransomware en cours.

Conclusion : une GFS utile seulement si elle est pilotée et prouvée

La méthode GFS demeure une excellente fondation parce qu’elle est compréhensible, auditable et adaptable, mais elle ne vaut que par son exécution. Alignez la rotation sur des RPO et RTO réalistes, automatisez la rétention et les alertes, dimensionnez l’espace en anticipant la croissance, protégez le dépôt contre la compromission avec une logique 3-2-1 et de l’immutabilité quand c’est possible, puis prouvez régulièrement votre capacité à restaurer. C’est cette combinaison — politique claire, sécurité du dépôt et restaurations testées — qui transforme une rotation de sauvegardes en véritable assurance opérationnelle.