Un plan de sauvegarde et de reprise après sinistre (DR) ne se mesure pas au nombre de copies réalisées, mais au temps que met l'organisation à reprendre son activité après un incident et à la quantité de données perdues en chemin. Ces deux questions ont un nom technique — RTO et RPO — et constituent le point de départ de toute conception sérieuse. Dans cet article, nous développons la méthodologie complète : de l'analyse d'impact à la bascule automatique, avec la règle 3-2-1-1-0, la défense face au rançongiciel et les tests de restauration qui distinguent un plan réel d'un document décoratif.
RTO et RPO : les deux métriques qui gouvernent tout
Le RTO (Recovery Time Objective) est le temps maximal acceptable durant lequel un système peut rester hors service après un incident avant de provoquer un dommage inacceptable pour l'activité. Le RPO (Recovery Point Objective) est la quantité maximale de données, mesurée en temps, que l'organisation peut se permettre de perdre ; un RPO d'une heure signifie que, dans le pire des cas, jusqu'à une heure de transactions sera perdue. Tous deux découlent de l'analyse d'impact sur l'activité (BIA), qui classe chaque système selon sa criticité.
La conséquence technique est directe : un RPO de cinq minutes ne se couvre pas avec une sauvegarde nocturne, il exige une réplication quasi continue ; un RTO de quinze minutes ne se couvre pas en restaurant depuis une bande, il exige un système en attente à chaud. Définir le RTO et le RPO système par système est ce qui évite la double erreur de trop dépenser pour protéger l'insignifiant ou de rester en deçà pour le critique. Ces métriques sont en outre une exigence explicite de la norme ISO 22301 de continuité d'activité et de la mesure de sauvegarde de la norme ISO/IEC 27001:2022.
La règle 3-2-1 et son évolution 3-2-1-1-0
La règle classique 3-2-1 établit : trois copies des données, sur deux types de support distincts, dont une copie hors des locaux (offsite). C'est le minimum civilisé. L'ère du rançongiciel a exigé de la durcir en 3-2-1-1-0 : le premier « 1 » supplémentaire exige une copie immuable ou air-gapped (isolée du réseau), et le « 0 » exige zéro erreur lors de la vérification des copies. Une copie qui n'a pas été vérifiée n'est pas une copie : c'est une supposition.
L'immuabilité se met en œuvre avec des technologies d'object lock dans le stockage objet ou avec des dépôts WORM (Write Once Read Many). La raison en est que le rançongiciel moderne recherche et chiffre activement les dépôts de sauvegarde avant de se déclencher ; si la copie ne peut être ni modifiée ni effacée pendant sa période de rétention, l'attaquant ne peut pas la rendre inutilisable. L'air-gap, physique ou logique, ajoute une seconde barrière en déconnectant la copie du réseau de production.
Types de copie : complète, incrémentale et différentielle
La sauvegarde complète copie toutes les données à chaque fois ; c'est la plus simple à restaurer mais la plus coûteuse en espace et en fenêtre. L'incrémentale ne copie que ce qui a changé depuis la dernière copie (complète ou incrémentale) ; elle minimise la fenêtre de sauvegarde mais enchaîne des dépendances, de sorte que la restauration exige la complète plus toute la chaîne d'incrémentales. La différentielle copie ce qui a changé depuis la dernière complète ; elle occupe plus d'espace que l'incrémentale mais restaure en deux étapes. La stratégie habituelle combine une complète hebdomadaire avec des incrémentales ou différentielles quotidiennes, en ajustant la fréquence au RPO visé.
Deux techniques modernes nuancent ce schéma classique. La sauvegarde incrémentale permanente (incremental-forever) réalise une seule copie complète initiale puis, à partir de là, uniquement des incrémentales, en synthétisant périodiquement une nouvelle complète dans le dépôt sans relire toutes les données d'origine ; cela réduit drastiquement la charge sur les systèmes de production. De son côté, la déduplication élimine les blocs répétés avant de les stocker, de sorte qu'une donnée identique présente sur mille machines n'est conservée qu'une seule fois, avec des ratios d'économie qui, dans les environnements virtualisés, dépassent fréquemment 90 %. Les deux techniques abaissent le coût de la rétention longue, mais introduisent une dépendance critique : si la copie complète de base ou l'index de déduplication se corrompt, toute la chaîne est compromise, ce qui renforce la nécessité d'une vérification périodique.
Un dernier concept à planifier est la rétention échelonnée (GFS, Grandfather-Father-Son) : des copies quotidiennes conservées quelques semaines, des hebdomadaires conservées des mois et des mensuelles ou annuelles conservées des années. Ce schéma équilibre la capacité à revenir à un point récent avec l'obligation légale ou métier de conserver des jalons à long terme, et doit s'aligner sur les politiques de conservation qu'impose le RGPD pour les données personnelles.
Réplication et bascule : de la copie à la continuité
La sauvegarde protège les données ; la réplication protège le service. La réplication synchrone écrit sur le site primaire et sur le site secondaire avant de confirmer la transaction, ce qui garantit un RPO nul mais impose une distance maximale par la latence. La réplication asynchrone confirme sur le primaire et propage vers le secondaire avec un léger décalage, ce qui permet de grandes distances géographiques au prix d'un RPO de quelques secondes ou minutes.
La bascule (failover) est le mécanisme qui commute l'exploitation vers le site secondaire lorsque le primaire tombe. Elle peut être manuelle, assistée ou automatique. La bascule automatique avec un RTO de quelques minutes exige un site en attente à chaud, des répartiteurs de charge qui redirigent le trafic et une base de données répliquée et promouvable. Tout aussi importante est la reprise du primaire (failback) : la procédure de retour vers le site primaire une fois restauré, sans perdre les données générées sur le secondaire pendant la contingence. Beaucoup de plans conçoivent la bascule et oublient la reprise, et découvrent le problème au pire moment.
Stratégies de DR selon le budget et la criticité
| Stratégie | RTO typique | RPO typique | Coût relatif |
|---|---|---|---|
| Sauvegarde et restauration | Heures à jours | Jusqu'à 24 h | Faible |
| Pilot light | Dizaines de minutes | Minutes | Moyen-faible |
| Warm standby | Minutes | Secondes à minutes | Moyen-élevé |
| Multi-site actif-actif | Quasi nul | Quasi nul | Élevé |
Le choix n'est pas une préférence esthétique : il se déduit du RTO et du RPO que le BIA a fixés pour chaque système. Un ERP qui facture n'admet pas le même niveau qu'un portail interne de documentation, et mélanger les deux dans la même stratégie revient à gaspiller de l'argent ou à assumer un risque inacceptable.
Les tests de restauration : ce qui distingue vraiment un plan réel
Un plan de DR non testé est une fiction documentaire. Les tests doivent être périodiques et échelonnés : revue sur table (tabletop, sur papier, validant les rôles et les décisions), tests de restauration partielle de systèmes précis et, au moins une fois par an, un exercice de bascule complet qui commute la production vers le site secondaire. La métrique validée est double : que le RTO réel ne dépasse pas l'objectif et que l'intégrité des données restaurées soit de 100 %. La norme ISO 22301 exige de documenter ces exercices et d'enregistrer les leçons apprises.
Un détail souvent oublié : la procédure de reprise doit être disponible en dehors des systèmes qu'elle protège. Si les instructions de DR ne vivent que sur le serveur de fichiers qui vient de tomber, le plan s'est auto-saboté.
Sauvegarde et RGPD : la dimension légale
Les sauvegardes contiennent des données personnelles et sont donc soumises au RGPD. Cela implique de chiffrer les copies en transit et au repos, de contrôler l'accès aux dépôts et d'appliquer des politiques de rétention cohérentes avec le principe de limitation de la durée de conservation. Le droit à l'effacement (« droit à l'oubli ») pose un défi technique : lorsqu'une personne concernée exerce son droit, les sauvegardes historiques la conserveront jusqu'à leur péremption ; la solution admise par l'Agence espagnole de protection des données consiste à documenter l'impossibilité d'un effacement sélectif dans les sauvegardes et à garantir que la donnée ne sera pas réintroduite si l'on restaure une ancienne copie.
Erreurs courantes dans les plans de sauvegarde et de DR
- Ne pas tester la restauration : la sauvegarde paraît correcte jusqu'à ce qu'on tente de restaurer et que cela échoue.
- Une seule copie en ligne : sans copie immuable ou hors ligne, le rançongiciel chiffre aussi les sauvegardes.
- RTO/RPO sans BIA : des objectifs fixés à l'intuition qui ne répondent pas à l'impact réel.
- Oublier la reprise du primaire : on bascule vers le secondaire et il n'y a aucun moyen propre de revenir.
- Copies non chiffrées : risque légal et d'exfiltration du dépôt de sauvegarde.
Questions fréquentes
À quelle fréquence dois-je faire des sauvegardes ?
La fréquence est dictée par le RPO de chaque système. Si l'activité ne peut perdre plus d'une heure de données, les copies ou la réplication doivent couvrir cette fenêtre ; il n'existe pas de chiffre universel valable pour tous les systèmes.
Le cloud rend-il le plan de DR inutile ?
Non. Le cloud facilite la géo-redondance, mais le modèle de responsabilité partagée laisse la sauvegarde des données et la configuration du DR entre les mains du client. Une erreur de configuration ou une suppression accidentelle n'est pas couverte par le fournisseur.
Qu'est-ce qu'une copie immuable et pourquoi est-ce important ?
C'est une copie qui ne peut être ni modifiée ni supprimée pendant une période définie. Elle importe parce qu'elle neutralise l'attaque du rançongiciel contre les sauvegardes elles-mêmes, qui est aujourd'hui l'une des tactiques les plus courantes.
À quelle fréquence faut-il tester le plan de DR ?
Au minimum une fois par an avec un exercice complet, et trimestriellement avec des tests partiels de restauration. Après tout changement important d'infrastructure, il convient de refaire le test.
Conclusion
Un plan robuste de sauvegarde et de reprise se construit à l'envers de la manière dont on procède habituellement : on décide d'abord combien d'indisponibilité et de perte de données l'activité tolère (RTO et RPO par système), et seulement ensuite on choisit la technologie qui satisfait ces chiffres au moindre coût. La règle 3-2-1-1-0, la copie immuable face au rançongiciel et, surtout, les tests de restauration périodiques sont ce qui transforme un ensemble de copies en une véritable capacité de continuité. Chez Summum Sistemas, nous concevons les plans de DR en partant toujours du BIA et nous les validons par des exercices réels, car la seule sauvegarde qui compte est celle dont on a démontré qu'elle restaure, et le seul plan qui vaille est celui qui a déjà été exécuté au moins une fois avant l'incident réel.