La présence de réplicas synchronisés ne prouve ni la capacité à restaurer une donnée supprimée, ni la reprise complète d’une application, ni le respect d’un RTO en situation de crise.
À retenir
- Always On améliore la disponibilité mais ne remplace pas les sauvegardes.
- RTO et RPO doivent être définis et mesurés par service.
- Un PRA inclut applications, DNS, identités, jobs et interfaces.
- La résilience n’est crédible qu’après une restauration et un exercice chronométrés.
1. Séparer haute disponibilité, reprise et restauration
La haute disponibilité vise à réduire l’interruption lors d’une défaillance locale. Le PRA traite la perte d’un site ou d’un ensemble de dépendances. La restauration protège contre les erreurs logiques, suppressions, corruptions ou compromissions.
Ces objectifs utilisent parfois les mêmes technologies, mais ils ne sont pas interchangeables. Un réplica peut recevoir immédiatement une mauvaise transaction ; il ne remplace donc pas l’historique des sauvegardes.
2. Définir les RTO et RPO par service
Le RTO exprime le temps maximal acceptable pour reprendre. Le RPO exprime la perte de données maximale acceptable. Ils doivent être définis avec les métiers et déclinés par service, pas seulement par instance.
Le coût augmente fortement lorsque les objectifs se rapprochent de zéro. La DSI doit rendre visible le compromis entre exigence, architecture, exploitation et budget.
3. Choisir la topologie selon les scénarios de panne
Always On Availability Groups, failover cluster instances, log shipping et restauration de sauvegardes répondent à des scénarios différents. Le mode synchrone peut réduire la perte potentielle mais dépend de la latence et de la capacité à confirmer les écritures. Le mode asynchrone protège la distance au prix d’un RPO non nul.
La bonne topologie part des pannes à couvrir : instance, hôte, stockage, zone, site, identité, réseau ou erreur humaine.
4. Inclure les clients, le réseau et les dépendances
Une base disponible ne suffit pas si l’application conserve une chaîne de connexion obsolète, si le listener n’est pas résolu, si un certificat expire ou si un service tiers reste indisponible.
Le test doit couvrir DNS, listeners, pilotes, pools de connexions, comptes, secrets, jobs, linked servers, SSIS, files et interfaces.
5. Superviser la capacité de reprise
Les files d’envoi et de redo, les états de synchronisation, la latence, les erreurs et la capacité des secondaires sont des indicateurs de RPO/RTO. Microsoft documente leur utilisation pour estimer le temps de récupération et identifier les goulots.
Le tableau de bord doit déclencher une action lorsque la perte potentielle ou le temps de rattrapage dépasse le seuil convenu.
6. Maintenir une stratégie de sauvegarde indépendante
Les sauvegardes complètes, différentielles et de journaux doivent être cohérentes avec le modèle de récupération et la rétention. La préférence de sauvegarde d’un groupe de disponibilité ne garantit pas qu’un outil tiers respectera automatiquement ce choix ; le comportement doit être vérifié.
Les sauvegardes doivent être protégées contre la suppression ou le chiffrement malveillant, avec séparation des responsabilités et copie hors du domaine de panne principal.
7. Tester la restauration, pas seulement le job de sauvegarde
Un job “vert” indique qu’un fichier a été produit. Il ne prouve pas que la chaîne est complète, que les certificats sont disponibles, que le temps de restauration respecte le RTO ou que l’application peut redémarrer.
Les tests doivent inclure restauration point-in-time, base chiffrée, volume représentatif, intégrité, comptes, jobs et validation fonctionnelle.
8. Construire un runbook de décision
Le runbook indique qui qualifie l’incident, qui décide la bascule, quels contrôles précèdent l’action, comment protéger les écritures, comment informer les métiers et comment revenir à l’état nominal.
Il doit inclure les conditions où il ne faut pas basculer : un réplica incomplet ou une corruption logique peuvent aggraver la situation.
9. Organiser des exercices gradués
Commencer par un tabletop, poursuivre par une restauration isolée, puis tester la bascule technique et enfin la reprise de bout en bout. Chaque exercice mesure temps, décisions, dépendances et écarts documentaires.
Un exercice sans chronométrage ni critères de succès produit peu d’apprentissage. Les résultats doivent alimenter un plan d’amélioration.
10. Intégrer le scénario cyber
Le PRA traditionnel suppose souvent une panne technique. Une attaque peut toucher simultanément production, comptes privilégiés, sauvegardes en ligne et outils d’administration.
La stratégie doit prévoir des sauvegardes protégées, des identités d’urgence, un environnement de restauration propre, des contrôles d’intégrité et la capacité à choisir un point de reprise fiable.
11. Gouverner la preuve de résilience
La DSI doit suivre la date du dernier test, le RTO observé, le point de restauration atteint, les écarts, les propriétaires et les actions ouvertes. Cette preuve vaut davantage qu’un diagramme d’architecture.
Sources et références
Les choix d’architecture, de sécurité et de licence doivent être validés au regard de la version, de l’édition, du contrat et des exigences propres à l’organisation.