tadata
← Retour à l'accueil

Architecture de Reprise après Sinistre : niveaux, compromis et tests

#architecture#disaster-recovery#reliability#cloud#business-continuity

La reprise après sinistre (DR) n'est pas une fonctionnalité à ajouter plus tard. C'est une décision architecturale qui détermine le coût d'infrastructure, la complexité opérationnelle et la tolérance au risque dès le premier jour.

Comparaison des niveaux DR

NiveauStratégieRPORTOCoût relatifRisque de perte
Niveau 0Aucun plan DRIndéfiniJours-Jamais1x (base)Perte totale possible
Niveau 1Sauvegarde & RestaurationHeures-JoursHeures-Jours1.1xDernière fenêtre de backup
Niveau 2Pilot LightMinutes-HeuresHeures1.3xMinimal
Niveau 3Warm StandbyMinutes15-60 min1.5-2xTrès faible
Niveau 4Hot StandbySecondesMinutes2-3xQuasi nul
Niveau 5Actif-ActifQuasi nulQuasi nul3-4xEffectivement nul

RPO = Objectif de Point de Reprise (combien de données pouvez-vous perdre) RTO = Objectif de Temps de Reprise (en combien de temps devez-vous être de retour)

tadata
Global DNS / GSLB health-checked, TTL 60 s Cloud A region 1 (primary) primary ok App tier DB primary Cloud B region (warm standby) standby ok App tier (scaled down) DB replica Immutable backups witness object lock, separate account async replication (RPO = lag) daily snapshot Warm standby réparti sur deux clouds
Global DNS / GSLB health-checked, TTL 60 s Cloud A region 1 (primary) primary ok App tier DB primary Cloud B region (warm standby) standby ok App tier (scaled down) DB replica Immutable backups witness object lock, separate account async replication (RPO = lag) daily snapshot Warm standby réparti sur deux clouds
Un DNS global (ou un load balancer global) vérifie la santé des deux sites et bascule en changeant sa réponse ; son TTL fait partie de votre RTO. La réplication asynchrone signifie que le site de secours peut avoir du retard : ce retard est votre RPO

Extrait de la fiche « Hybrid, Multi-Cloud and Connectivity Architecture » · Demander la fiche complète

Checklist de test DR

Type de testFréquencePortéePerturbationConfiance
Exercice sur tableTrimestrielParcours des runbooksAucuneFaible-Moyenne
Basculement composantMensuelUn service/BDDMinimaleMoyenne
Basculement régionalSemestrielBascule complète de régionModéréeHaute
Chaos engineeringContinuInjection de pannes aléatoiresVariableHaute
Exercice DR completAnnuelSimulation de panne totaleSignificativeTrès haute
Test restauration backupMensuelRestaurer un backup pour vérifierAucuneMoyenne
tadata
0 2 4 6 8 Declare disaster, call tree Fail over network and DNS Restore database from backup Application smoke test RTO target Re-key lost transactions MTD limit Invoke Recover IT Work recovery Test DR commenté : reprise mesurée face à un RTO de 4 h et une MTD de 8 h (heures depuis la déclaration)
0 2 4 6 8 Declare disaster, call tree Fail over network and DNS Restore database from backup Application smoke test RTO target Re-key lost transactions MTD limit Invoke Recover IT Work recovery Test DR commenté : reprise mesurée face à un RTO de 4 h et une MTD de 8 h (heures depuis la déclaration)
Journal de test en parallèle (exemple) : le système revient à 4 h, le RTO est tenu ; la reprise métier (ressaisie des données perdues depuis le point RPO) se termine à 6 h, dans la MTD car RTO + WRT ≤ MTD. L'auditeur compare ces temps mesurés aux valeurs du BIA

Extrait de la fiche « CISA Domain 4 (part 2): Business Resilience » · Demander la fiche complète

Matrice coût vs récupération

tadata
TARGET RTO (DOWNTIME) ≤ 15 min TARGET RPO (DATA LOSS) ≤ 1 min CHEAPEST FIT Warm standby Backup and restore RTO 12 hRPO 1 dcost ×1 AWS Backup copies, IaC rebuild misses RTO 12 h > 15 min; RPO 1 d > 1min Pilot light RTO 1 hRPO 1 mincost ×2 data replicated, servers off misses RTO 1 h > 15 min Warm standby RTO 10 minRPO 0 mincost ×4 scaled-down full stack cheapest fit Multi-siteactive-active RTO 1 minRPO 0 mincost ×8 full capacity in 2+ regions meets more cost → shorter RTO and RPO RTO (recovery time objective) = the longest acceptable downtime; RPO (recovery point objective) = the longest acceptable windowof lost data; cost index = running cost relative to the cheapest strategy. A strategy fits when both its RTO and RPO are withinthe targets.
TARGET RTO (DOWNTIME) ≤ 15 min TARGET RPO (DATA LOSS) ≤ 1 min CHEAPEST FIT Warm standby Backup and restore RTO 12 hRPO 1 dcost ×1 AWS Backup copies, IaC rebuild misses RTO 12 h > 15 min; RPO 1 d > 1min Pilot light RTO 1 hRPO 1 mincost ×2 data replicated, servers off misses RTO 1 h > 15 min Warm standby RTO 10 minRPO 0 mincost ×4 scaled-down full stack cheapest fit Multi-siteactive-active RTO 1 minRPO 0 mincost ×8 full capacity in 2+ regions meets more cost → shorter RTO and RPO RTO (recovery time objective) = the longest acceptable downtime; RPO (recovery point objective) = the longest acceptable windowof lost data; cost index = running cost relative to the cheapest strategy. A strategy fits when both its RTO and RPO are withinthe targets.
Ordres de grandeur typiques (votre conception fixe les valeurs réelles). Cible RTO 15 min / RPO 1 min : le warm standby est la stratégie la moins chère qui respecte les deux.

Extrait de la fiche « SAA-C03 Resilient 3: High Availability and DR » · Demander la fiche complète

Décisions par criticité métier

Type de systèmeNiveau recommandéJustification
Outils internesNiveau 1-2Indisponibilité tolérable, sensible au coût
SaaS B2B (standard)Niveau 3SLA typiquement 99.9%, RPO horaire acceptable
SaaS B2B (enterprise)Niveau 4SLA 99.95%+, RPO en minutes
E-commerceNiveau 4Perte de revenu par minute quantifiable
Services financiersNiveau 5Exigences réglementaires, zéro perte
Santé (critique)Niveau 5Sécurité patient, mandats de conformité

Point clé

L'échec DR le plus courant n'est pas technique -- c'est que le plan n'a jamais été testé. Un plan DR qui n'a pas été exercé depuis 6 mois est une hypothèse, pas un plan.

Ressources

Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.