Un plan de reprise après sinistre se mesure au RTO, le temps d'arrêt maximal tolérable, et au RPO, la perte de données maximale tolérable — tous deux définis dans l'analyse d'impact sur l'activité ; la règle 3-2-1-1-0 ajoute une copie immuable ou isolée (air-gap) ainsi qu'une vérification sans erreur.
Un plan de sauvegarde et reprise après sinistre (DR) ne se mesure pas au nombre de copies effectuées, mais au temps qu'il faut à l'organisation pour reprendre son activité après un incident et à la quantité de données perdues en chemin. Ces deux questions ont des noms techniques — 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 contre les rançongiciels 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 d'arrêt maximal acceptable pour un système après un incident, avant de causer un dommage insupportable à 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. Les 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 n'est pas couvert par une sauvegarde nocturne, il exige une réplication quasi continue ; un RTO de quinze minutes n'est pas couvert par une restauration depuis une bande, il exige un système de secours actif (hot standby). Définir le RTO et le RPO système par système permet d'éviter la double erreur de trop dépenser pour protéger ce qui est secondaire ou de manquer de moyens sur le critique. Ces métriques sont également une exigence explicite de la norme de continuité d'activité ISO 22301 et du contrôle 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 énonce : trois copies des données, sur deux types de support différents, avec une copie hors site. C'est le minimum civilisé. L'ère des rançongiciels a imposé de la renforcer en 3-2-1-1-0 : le « 1 » supplémentaire exige une copie immuable ou isolée du réseau (air-gap), et le « 0 » exige zéro erreur dans 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 est que les rançongiciels modernes recherchent activement et chiffrent les dépôts de sauvegarde avant de se déclencher ; si la copie ne peut être ni modifiée ni supprimée pendant sa période de rétention, l'attaquant ne peut pas la neutraliser. L'air gap, physique ou logique, ajoute une seconde barrière en déconnectant la copie du réseau de production.
Types de sauvegarde : complète, incrémentielle 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 de sauvegarde. La sauvegarde incrémentielle ne copie que ce qui a changé depuis la dernière copie (complète ou incrémentielle) ; elle réduit la fenêtre de sauvegarde mais enchaîne les dépendances, si bien que la restauration exige la copie complète plus toute la chaîne d'incrémentiels. La sauvegarde différentielle copie ce qui a changé depuis la dernière copie complète ; elle prend plus d'espace que l'incrémentielle mais se restaure en deux étapes. La stratégie habituelle combine une sauvegarde complète hebdomadaire avec des incrémentiels ou différentiels quotidiens, en ajustant la fréquence au RPO visé.
Deux techniques modernes affinent ce schéma classique. La sauvegarde incremental-forever réalise une seule copie complète initiale puis, ensuite, uniquement des incrémentiels, en synthétisant périodiquement une nouvelle copie complète dans le dépôt sans relire toutes les données source ; cela réduit considérablement 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 stockée qu'une seule fois, avec des taux d'économie qui, dans les environnements virtualisés, dépassent fréquemment 90 %. Ces deux techniques réduisent le coût d'une rétention longue, mais elles 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 à prévoir est la rétention par paliers (GFS, Grand-père-Père-Fils) : copies quotidiennes conservées quelques semaines, copies hebdomadaires conservées quelques mois et copies mensuelles ou annuelles conservées plusieurs 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 de long terme, et il doit être aligné avec les politiques de rétention imposées par 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 secondaire avant de confirmer la transaction, ce qui garantit un RPO de zéro mais impose une distance maximale à cause de 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 en échange d'un RPO de quelques secondes ou minutes.
Le failover (bascule) est le mécanisme qui bascule le fonctionnement vers le site secondaire quand le primaire tombe. Il peut être manuel, assisté ou automatique. Une bascule automatique avec un RTO de quelques minutes exige un site de secours actif, des répartiteurs de charge qui redirigent le trafic et une base de données répliquée et « promouvable ». Tout aussi important est le failback (retour) : la procédure de retour au 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 le failover et oublient le failback, et découvrent le problème au pire moment possible.
Stratégies de reprise 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 la BIA a fixés pour chaque système. Un ERP qui émet des factures ne tolère pas le même niveau qu'un portail de documentation interne, et mélanger les deux dans la même stratégie revient à gaspiller de l'argent ou à assumer un risque inacceptable.
Tests de restauration : ce qui distingue vraiment un plan réel
Un plan de reprise non testé est de la fiction documentaire. Les tests doivent être périodiques et progressifs : un exercice sur table (sur papier, validant les rôles et les décisions), des tests de restauration partielle de systèmes spécifiques et, au moins une fois par an, un exercice complet de bascule qui fait basculer 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 %. L'ISO 22301 exige que ces exercices soient documentés et que les enseignements tirés soient consignés.
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 reprise ne vivent que sur le serveur de fichiers qui vient de tomber, le plan s'est saboté lui-même.
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 conservation. Le droit à l'effacement (le « droit à l'oubli ») pose un défi technique : lorsqu'une personne concernée exerce son droit, les sauvegardes historiques conserveront les données jusqu'à leur expiration ; la solution admise par l'Agence espagnole de protection des données (AEPD) consiste à documenter l'impossibilité de suppression sélective dans les sauvegardes et à garantir que les données ne seront pas réintroduites si une ancienne copie est restaurée.
Erreurs courantes dans les plans de sauvegarde et de reprise
- Ne pas tester la restauration : la sauvegarde semble correcte jusqu'à ce qu'on tente de la restaurer et qu'elle é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 le failback : on bascule vers le secondaire et il n'existe pas de retour propre.
- Copies non chiffrées : risque juridique et d'exfiltration sur le 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 pas perdre plus d'une heure de données, les sauvegardes 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 un plan de reprise 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 de la reprise 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. C'est important car elle neutralise l'attaque par rançongiciel contre les sauvegardes elles-mêmes, l'une des tactiques les plus courantes aujourd'hui.
À quelle fréquence faut-il tester le plan de reprise ?
Au moins une fois par an avec un exercice complet, et trimestriellement avec des tests de restauration partielle. Après tout changement majeur d'infrastructure, il est prudent de répéter le test.
Conclusion
Un plan de sauvegarde et de reprise robuste se construit à l'inverse de ce qui se fait habituellement : on décide d'abord combien de temps d'arrêt et combien de perte de données l'activité tolère (RTO et RPO par système), et c'est seulement ensuite qu'on choisit la technologie qui répond à ces chiffres au moindre coût. La règle 3-2-1-1-0, la copie immuable contre les rançongiciels et, surtout, des 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 reprise en partant toujours de la BIA et nous les validons par des exercices réels, car la seule sauvegarde qui compte est celle dont on a prouvé qu'elle restaure, et le seul plan qui vaut quelque chose est celui déjà exécuté au moins une fois avant l'incident réel.