Reprise après sinistre, sauvegardes, RTO/RPO, failover et surtout la question que beaucoup d’entreprises ne se posent qu’après une panne : sommes-nous vraiment capables de restaurer le système et de reprendre le travail ?
Panne de serveur. Base de données endommagée. Erreur après déploiement. Ransomware. Problèmes chez le fournisseur d’infrastructure. Suppression accidentelle de données. Panne de toute une région.
Les scénarios sont nombreux. Le problème, c’est que la plupart des entreprises se préparent d’abord à éviter qu’une panne ne survienne.
Et bien plus rarement à la situation où elle survient malgré tout.
C’est précisément le domaine de la reprise après sinistre.
Et ici se pose la question fondamentale : si votre application cessait de fonctionner aujourd’hui à 14h00, combien de temps vous faudrait-il pour la remettre en service et combien de données pourriez-vous perdre ?
Si la réponse est « nous avons une sauvegarde », ce n’est pas encore une réponse à cette question.
La sauvegarde n’est pas la reprise après sinistre
Une sauvegarde est une copie des données. La reprise après sinistre est un processus de restauration du fonctionnement du système.
C’est une distinction très importante.
Vous pouvez effectuer des copies de la base de données tous les jours et pourtant ne pas savoir :
-
si la dernière copie est correcte,
-
si elle peut être restaurée,
-
combien de temps prendra la restauration,
-
si la base, une fois restaurée, fonctionnera avec la version actuelle de l’application,
-
si vous restaurerez également la configuration du système,
-
si vous disposez de toutes les clés, certificats et secrets nécessaires pour démarrer l’environnement,
-
si l’infrastructure nécessaire au lancement de l’application est toujours disponible,
-
qui doit exécuter les différentes étapes,
-
si l’ensemble du processus respecte le délai acceptable pour l’activité.
Le NIST indique explicitement la nécessité de tester la restauration des copies, et les directives actuelles d’AWS considèrent également les tests périodiques de reprise comme un moyen de vérifier si la sauvegarde permet réellement d’atteindre les RTO et RPO prévus.
C’est pourquoi la sauvegarde est un élément de la stratégie de reprise, et non son équivalent complet.
La question la plus importante : que se passe-t-il après une panne ?
Imaginons une boutique en ligne.
À 10h17, la base de données cesse de répondre.
Le serveur d’applications fonctionne toujours, mais les utilisateurs ne peuvent pas se connecter. Les commandes ne fonctionnent pas. Le panneau d’administration cesse de répondre. Le système de paiement ne reçoit pas les bonnes informations.
L’équipe vérifie la situation.
Il s’avère que la dernière sauvegarde de la base a été effectuée à 8h00.
En théorie, les données peuvent être récupérées.
Mais d’autres questions apparaissent alors ;
- Savez-vous où se trouve la copie ?
- Savez-vous comment la restaurer ?
- La personne qui sait le faire est-elle disponible ?
- La sauvegarde est-elle complète ?
- La configuration de l’application correspond-elle à la version enregistrée dans la copie ?
- Après restauration, la base fonctionnera-t-elle avec l’application actuelle ?
- Et surtout : combien de temps faudra-t-il pour rétablir le fonctionnement de la boutique ?
Si personne ne l’a vérifié auparavant, la réponse peut être surprenante.
RTO - combien d’interruption pouvons-nous accepter ?
Le RTO, ou Recovery Time Objective, définit le temps maximal acceptable pour rétablir le système après une panne.
Par exemple : RTO = 4 heures signifie que l’organisation suppose pouvoir rétablir le fonctionnement du système en quatre heures maximum.
Cela ne signifie pas pour autant que chaque application devrait avoir un RTO de quatre heures.
Pour un système interne utilisé quelques fois par jour, un tel délai peut être acceptable. Pour une plateforme de vente fonctionnant 24/7, cela peut représenter des pertes très importantes.
Le RTO doit donc découler du métier, et non de ce que l’infrastructure offre actuellement.
Le NIST définit le RTO comme le temps pendant lequel un système peut rester en phase de restauration avant que cela n’affecte négativement l’activité de l’organisation.
RPO - quelles données pouvons-nous perdre ?
Le deuxième paramètre fondamental est le RPO, c’est-à-dire le Recovery Point Objective.
Le RPO répond à la question : jusqu’à quel point dans le passé pouvons-nous revenir avec les données après une panne ?
Exemple : RPO = 1 heure signifie que l’organisation accepte une perte potentielle d’environ une heure de données au maximum.
Si le système tombe en panne à 15h00 et que la dernière copie exploitable date de 14h00, c’est précisément un scénario conforme au RPO prévu. Mais si la sauvegarde est effectuée une fois par jour, il est difficile d’attendre un RPO d’une heure.
Le RPO influence donc directement la manière dont les copies, la réplication des données et la conception de l’infrastructure sont réalisées.
Le RTO nous dit avant tout combien de temps nous pouvons être indisponibles.
Le RPO nous dit combien de données nous pouvons perdre.
Ces deux paramètres devraient être définis avec le métier, car leur atteinte implique des coûts et des solutions techniques. Microsoft souligne également que les RTO et RPO devraient découler de véritables exigences métier, et non de l’hypothèse abstraite « zéro interruption et zéro perte de données ».
La sauvegarde peut exister tout en restant inutile
C’est l’un des mythes les plus dangereux en informatique.
« La sauvegarde s’exécute correctement » ne signifie pas automatiquement : « le système peut être restauré à partir d’elle ».
La copie peut être incomplète. Elle peut être corrompue. Elle peut contenir des données impossibles à utiliser correctement. Elle peut avoir été effectuée d’une manière qui ne permet pas de restaurer l’ensemble de l’environnement.
C’est pourquoi il faut tester la sauvegarde par une restauration réelle.
Il ne suffit pas de vérifier qu’un fichier existe.
Il faut le restaurer.
Démarrer le système.
Vérifier les données.
Contrôler les dépendances.
Vérifier la configuration.
Mesurer le temps.
Et répondre à la question de savoir si le résultat correspond aux hypothèses RTO et RPO.
AWS cite comme erreur typique précisément la restauration d’une sauvegarde sans vérifier si la ressource restaurée fonctionne réellement et si les données récupérées peuvent être utilisées.
Failover - quand on ne veut pas attendre la restauration
Toutes les applications ne peuvent pas se permettre plusieurs heures d’attente pour la remise en service. Dans de tels cas, on utilise notamment des mécanismes de failover.
Le failover consiste à basculer le fonctionnement de l’environnement principal vers un environnement de secours préparé.
Cela peut être :
-
un serveur de secours,
-
une deuxième zone de disponibilité,
-
une deuxième région,
-
une réplique de base de données,
-
un environnement de standby,
-
une infrastructure alternative prête à être lancée.
Dans le modèle le plus simple, l’application fonctionne à un seul endroit, et en cas de panne nous lançons l’environnement de secours. Dans des solutions plus avancées, une partie de l’infrastructure fonctionne en parallèle et est prête à reprendre le trafic.
Il n’existe toutefois pas une seule stratégie adaptée à tous.
Le backup et le restore sont généralement moins coûteux, mais ils peuvent impliquer un temps de récupération plus long. Les solutions de type warm standby ou de redondance active peuvent réduire considérablement le recovery, mais elles exigent des moyens plus importants et une infrastructure plus complexe.
Il faut aussi tester le failover
C’est là qu’apparaît un autre problème.
Une entreprise peut disposer d’un environnement de secours, mais ne pas l’avoir utilisé depuis deux ans;
- Fonctionne-t-il encore ?
- La configuration correspond-elle à la production ?
- A-t-il des performances suffisantes ?
- Tous les services sont-ils disponibles ?
- Les certificats sont-ils à jour ?
- Le DNS basculera-t-il correctement ?
- L’application se connectera-t-elle à la base de données ?
- Le mécanisme d’autorisation fonctionnera-t-il ?
- L’équipe sait-elle exactement ce qu’elle doit faire ?
Seul le test répond à ces questions.
AWS recommande de tester régulièrement le failover précisément pour vérifier le fonctionnement du chemin de récupération et pour s’assurer que le RTO et le RPO réels correspondent aux hypothèses.
Un environnement de disaster recovery qui n’a jamais été testé n’est en partie qu’une hypothèse.
Le disaster recovery, ce n’est pas seulement l’infrastructure
Il est facile de considérer le DR uniquement sous l’angle des serveurs.
C’est une erreur.
Le recovery comprend aussi :
- Données
Toutes les données importantes sont-elles protégées ? - Application
Disposons-nous de la bonne version du code et de la possibilité de la déployer ? - Configuration
Savons-nous quels paramètres sont nécessaires pour démarrer le système ? - Secrets et certificats
Avons-nous un accès sécurisé aux clés, jetons et certificats ? - Dépendances externes
Que se passera-t-il si le système de paiement externe, l’API, le fournisseur d’identité ou le service SaaS devient indisponible ? - Infrastructure
Avons-nous un endroit où l’application peut être lancée ? - Personnes
- Procédures
Existe-t-il un runbook concret, ou bien le recovery repose-t-il sur la connaissance d’une seule personne ?
Ce dernier point est particulièrement important.
Si un seul administrateur sait comment restaurer le système, nous n’avons pas encore une procédure robuste. Nous avons une dépendance à une personne précise.
Le pire moment pour rédiger une procédure de recovery
C’est le moment où le système ne fonctionne déjà plus.
À ce moment-là apparaissent la pression du temps, le stress, les appels des clients et les questions de la direction.
C’est pourquoi la procédure doit être préparée à l’avance.
Elle devrait notamment préciser :
-
quand nous lançons le disaster recovery,
-
qui prend la décision,
-
quels systèmes ont la priorité la plus élevée,
-
où se trouvent les sauvegardes,
-
comment les restaurer,
-
quelles dépendances doivent être démarrées,
-
à quoi ressemble le failover,
-
comment vérifier le bon fonctionnement,
-
comment communiquer l’incident,
-
quand le failback peut commencer,
-
qui approuve le retour à l’environnement principal.
En cas de panne grave, il ne devrait pas y avoir de place pour la question : « Que faisons-nous maintenant ? »
La procédure doit y répondre à l’avance.
Le DR devrait être testé comme une fonctionnalité de l’application
Une bonne approche consiste à traiter le recovery de manière similaire aux tests logiciels. Il ne suffit pas de préparer la procédure une seule fois.
Le système évolue.
La base de données grossit.
Les dépendances changent.
Une nouvelle infrastructure apparaît.
Les versions des applications changent.
De nouvelles intégrations apparaissent.
Les autorisations changent.
C’est pourquoi la stratégie de recovery nécessite elle aussi une vérification continue.
Le test peut commencer par un scénario simple : « La base de données a été perdue. Restaurons-la à partir de la dernière copie. »
Ensuite, on peut passer à des scénarios plus complexes :
- « Le serveur d’application est en panne. »
- « Tout l’environnement de production est indisponible. »
- « Les données ont été chiffrées. »
- « La région principale de l’infrastructure ne fonctionne pas. »
- « Nous n’avons pas accès à l’administrateur principal. »
Chaque test de ce type peut révéler des problèmes invisibles pendant le fonctionnement normal du système.
Chaque application a-t-elle besoin d’un disaster recovery avancé ?
Non.
Et cela aussi est important.
Concevoir une infrastructure résistante à tous les scénarios possibles peut coûter de façon disproportionnée.
Si la panne d’une application interne peut signifier une heure d’inconvénients, nous n’avons pas nécessairement besoin d’une infrastructure active-active sur plusieurs régions. En revanche, si la panne d’un système entraîne l’arrêt des ventes, de la production, du support client ou d’un processus métier critique, la situation est tout autre.
Il faut d’abord déterminer l’impact de la panne sur l’activité.
Ce n’est qu’ensuite qu’il faut choisir la technologie.
Cela peut conduire à différentes solutions :
Backup + restore
Une solution plus simple et moins coûteuse pour les systèmes moins critiques.
Warm standby
L’environnement de secours est partiellement préparé et peut être lancé rapidement.
Hot standby
L’environnement de secours fonctionne dans une plus grande mesure en parallèle et est prêt à reprendre la charge.
Active-active
Deux environnements peuvent traiter le trafic simultanément, en réduisant la dépendance à un point de défaillance unique.
Le choix de la solution doit découler du RTO, du RPO, de la criticité du système, du coût de l’arrêt et des possibilités techniques.
Checklist : votre application est-elle prête à faire face à une panne ?
Il vaut la peine de répondre à quelques questions simples.
1. Avons-nous une sauvegarde ?
Ce n’est qu’un début.
2. La sauvegarde est-elle stockée de manière à être protégée aussi contre une panne de l’environnement de production ?
3. Avons-nous déjà effectué une restauration complète ?
4. Combien de temps dure réellement le restore ?
5. Connaissons-nous le RTO ?
6. Connaissons-nous le RPO ?
7. Sommes-nous capables de restaurer non seulement les données, mais aussi l’application et sa configuration ?
8. Avons-nous une procédure de recovery ?
9. Plus d’une personne sait-elle l’exécuter ?
10. Avons-nous testé le failover ?
11. L’environnement de secours est-il à jour ?
12. Après les derniers changements dans le système, avons-nous retesté le recovery ?
Si, pour plusieurs questions, nous répondons « je ne sais pas », c’est le très bon moment pour examiner la stratégie de disaster recovery.
Le test le plus important est : « Montrez »
En informatique, il est très facile de dire :
- « Nous avons une sauvegarde. »
- « Nous avons un serveur de secours. »
- « Nous avons une procédure. »
- « Nous avons un plan de reprise après sinistre. »
- Mais la sécurité du système ne devrait pas reposer uniquement sur des déclarations.
La question la plus importante est : Montrez que vous pouvez le restaurer.
- Lancez une restauration.
- Mesurez le temps.
- Vérifiez les données.
- Testez l'application.
- Effectuez un basculement.
- Vérifiez la procédure.
- Répétez le test après des changements significatifs.
Ce n'est qu'alors qu'on peut dire que la stratégie de reprise a été testée dans la pratique.
La sauvegarde protège les données. La reprise rétablit l'activité
C'est sans doute la différence la plus importante.
La sauvegarde répond à la question : « Avons-nous une copie ? »
La reprise après sinistre répond à une question bien plus difficile : « Après une panne, sommes-nous capables de reprendre l'activité ? »
Et entre les deux se trouve toute l'architecture de reprise : RPO, RTO, réplication, sauvegardes, restauration, basculement, configuration, procédures, responsabilités et tests réguliers.
Un système bien conçu ne suppose pas qu'une panne n'arrivera jamais. Il suppose qu' une panne se produira un jour et qu'il faudra savoir quoi faire.
Car la vraie résilience d'une application ne consiste pas à ne jamais tomber en panne. Elle consiste à ce que, lorsque quelque chose tourne mal, l'organisation soit capable de reprendre l'activité de manière prévisible, contrôlée et conforme aux exigences de l'entreprise.
Glossaire
Disaster Recovery (DR) - stratégie et procédures permettant de rétablir le fonctionnement des systèmes après une panne majeure.
Backup - copie des données destinée à être restaurée plus tard.
Restore - processus de restauration des données ou d'un système à partir d'une copie.
RTO (Recovery Time Objective) - temps maximal acceptable de rétablissement du système.
RPO (Recovery Point Objective) - perte de données maximale acceptable exprimée dans le temps.
Failover - basculement du fonctionnement du système de l'environnement principal vers l'environnement de secours.
Failback - retour du fonctionnement vers l'environnement principal après suppression de la cause de la panne.
Recovery test - test visant à confirmer que le système peut réellement être restauré conformément aux hypothèses retenues.
Runbook - instruction détaillée à suivre dans un scénario de panne donné.
