🌪️ Storage Systems — Chapitre 30 : Réplication et Disaster Recovery

Chapitre dense sur la réplication et le PRA/PCA : réplication synchrone, asynchrone, metro cluster, active/passive, active/active, RPO/RTO, DRaaS, cohérence, split-brain, réseau, tiers cold/warm/hot, cloud DR, bases de données, Kubernetes, object storage, tests DR, runbooks, failback, cyber recovery, FinOps, gouvernance, anti-patterns et checklist production. Objectif : passer d’une théorie de continuité à une capacité de reprise prouvée.

Réplication synchroneRéplication asynchroneMetro clusterActive/passiveActive/activeRPO / RTO / DRaaS

30.1

Réplication synchrone

RPO proche de zéro, latence critique, validation d’écriture sur deux sites avant ACK.

SyncRPO≈0Latency

30.2

Réplication asynchrone

Distance, coût, RPO non nul, file de changements, réplication par batch ou flux continu.

AsyncDistanceRPO

30.3

Metro cluster

Haute disponibilité multi-site avec latence faible, quorum, witness, stretched compute et storage.

MetroHAWitness

30.4

Active/passive

DR classique : site primaire actif, site secondaire standby froid, tiède ou chaud.

StandbyFailoverFailback

30.5

Active/active

Deux sites servent simultanément le trafic. Puissant, complexe, risque de split-brain et conflits.

Active-activeGSLBConflict

30.6

RPO / RTO

Indicateurs centraux : perte de données admissible et délai maximal de reprise.

RPORTOSLA

30.7

DRaaS

Disaster Recovery as a Service : réplication, orchestration, tests et reprise managée.

DRaaSCloudManaged

30.8

Modes de réplication

Bloc, fichier, objet, base de données, application, hyperviseur : la couche choisie change tout.

BlockFileObjectDB

30.9

Cohérence et ordre d’écriture

Write-order fidelity, consistency groups, crash-consistent, application-consistent et recovery.

ConsistencyWrite orderCG

30.10

Split-brain, quorum, witness

Éviter que deux sites deviennent primaires : quorum, fencing, witness et tie-breaker.

Split-brainQuorumFencing

30.11

Réseau DR

Latence, bande passante, DNS, GSLB, BGP, firewall, certificats, VPN et routage.

WANDNSBGP

30.12

Cold, warm, hot standby

Niveaux de préparation du site secondaire : coûts et RTO très différents.

ColdWarmHot

30.13

DR cloud

AWS, Azure, GCP, OVHcloud, Scaleway : snapshots, cross-region, IaC, IAM, KMS.

CloudMulti-regionIaC

30.14

DR bases de données

Streaming replication, log shipping, synchronous commit, promotion, PITR et failback DB.

DBPITRFailover

30.15

DR Kubernetes

GitOps, Velero/Kasten, PVC, etcd, CRDs, secrets, registry, DNS, ingress.

K8sVeleroGitOps

30.16

DR object storage

Versioning, object lock, bucket replication, inventory, lifecycle et cross-account copy.

S3Object LockReplication

30.17

Tests DR et fire drills

Mesurer RPO/RTO réels avec tests isolés, preuves, rapports et validation métier.

Fire drillEvidenceAudit

30.18

Runbook de bascule DR

Qui décide, quoi promouvoir, quel DNS changer, comment valider, comment revenir.

RunbookFailoverValidation

30.19

Failback et retour normal

Retour vers site primaire : reverse replication, delta, cutback, validation et nettoyage.

FailbackRe-syncCutback

30.20

Cyber Recovery et clean room

Ransomware : backups immuables, environnement isolé, forensic, AD/IAM/PKI propres.

CyberClean roomForensics

30.21

FinOps DR

Coût du standby : compute, stockage, réplication, egress, licences, tests et runbooks.

FinOpsTCOStandby

30.22

Gouvernance et conformité

Owners, tiers de criticité, obligations légales, preuves de tests et comité de crise.

GovernanceComplianceOwner

30.23

Anti-patterns DR

Réplication prise pour backup, DR jamais testé, DNS/AD oubliés, même compte admin partout.

Anti-patternsFalse DRRisk

30.24

Checklist production DR

GO/NO-GO : RPO/RTO validés, réplication monitorée, backup indépendant, tests, failback.

ChecklistPRAProd-ready

30.1 Réplication synchrone

Définition opérationnelle

RPO proche de zéro, latence critique, validation d’écriture sur deux sites avant ACK.

Point clé : le DR doit être prouvé par exercice, pas seulement dessiné dans un schéma. La continuité couvre données, compute, réseau, DNS, identité, certificats, secrets, dépendances SaaS et validation métier.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.2 Réplication asynchrone

Définition opérationnelle

Distance, coût, RPO non nul, file de changements, réplication par batch ou flux continu.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.3 Metro cluster

Définition opérationnelle

Haute disponibilité multi-site avec latence faible, quorum, witness, stretched compute et storage.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.4 Active/passive

Définition opérationnelle

DR classique : site primaire actif, site secondaire standby froid, tiède ou chaud.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.5 Active/active

Définition opérationnelle

Deux sites servent simultanément le trafic. Puissant, complexe, risque de split-brain et conflits.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.6 RPO / RTO

Définition opérationnelle

Indicateurs centraux : perte de données admissible et délai maximal de reprise.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.7 DRaaS

Définition opérationnelle

Disaster Recovery as a Service : réplication, orchestration, tests et reprise managée.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.8 Modes de réplication

Définition opérationnelle

Bloc, fichier, objet, base de données, application, hyperviseur : la couche choisie change tout.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.9 Cohérence et ordre d’écriture

Définition opérationnelle

Write-order fidelity, consistency groups, crash-consistent, application-consistent et recovery.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.10 Split-brain, quorum, witness

Définition opérationnelle

Éviter que deux sites deviennent primaires : quorum, fencing, witness et tie-breaker.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.11 Réseau DR

Définition opérationnelle

Latence, bande passante, DNS, GSLB, BGP, firewall, certificats, VPN et routage.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.12 Cold, warm, hot standby

Définition opérationnelle

Niveaux de préparation du site secondaire : coûts et RTO très différents.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.13 DR cloud

Définition opérationnelle

AWS, Azure, GCP, OVHcloud, Scaleway : snapshots, cross-region, IaC, IAM, KMS.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.14 DR bases de données

Définition opérationnelle

Streaming replication, log shipping, synchronous commit, promotion, PITR et failback DB.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.15 DR Kubernetes

Définition opérationnelle

GitOps, Velero/Kasten, PVC, etcd, CRDs, secrets, registry, DNS, ingress.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.16 DR object storage

Définition opérationnelle

Versioning, object lock, bucket replication, inventory, lifecycle et cross-account copy.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.17 Tests DR et fire drills

Définition opérationnelle

Mesurer RPO/RTO réels avec tests isolés, preuves, rapports et validation métier.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.18 Runbook de bascule DR

Définition opérationnelle

Qui décide, quoi promouvoir, quel DNS changer, comment valider, comment revenir.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.19 Failback et retour normal

Définition opérationnelle

Retour vers site primaire : reverse replication, delta, cutback, validation et nettoyage.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.20 Cyber Recovery et clean room

Définition opérationnelle

Ransomware : backups immuables, environnement isolé, forensic, AD/IAM/PKI propres.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.21 FinOps DR

Définition opérationnelle

Coût du standby : compute, stockage, réplication, egress, licences, tests et runbooks.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.22 Gouvernance et conformité

Définition opérationnelle

Owners, tiers de criticité, obligations légales, preuves de tests et comité de crise.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.23 Anti-patterns DR

Définition opérationnelle

Réplication prise pour backup, DR jamais testé, DNS/AD oubliés, même compte admin partout.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.

30.24 Checklist production DR

Définition opérationnelle

GO/NO-GO : RPO/RTO validés, réplication monitorée, backup indépendant, tests, failback.

Chaîne DR

Production→Replication / Backup→Target site→Failover→Validation→Failback

RPODonnées

Perte admissible.

RTOTemps

Délai de reprise.

LagRetard

Réplication à surveiller.

ProofTest

DR prouvé.

Composants

Composant	Rôle / explication
Source	Production primaire : application, VM, base de données, volume, bucket, namespace Kubernetes.
Journal ou delta	Changements à transférer : blocs, fichiers, objets, logs transactionnels ou événements.
Lien de réplication	WAN, fibre, VPN, interconnexion privée, réseau datacenter ou backbone cloud.
Cible DR	Site secondaire, région cloud, cluster standby, repository, bucket, base replica.
Orchestration	Runbook humain ou automatisation : promotion, DNS, firewall, validation, failback.
Preuve	RPO/RTO mesurés, logs, captures, rapport d’exercice et validation métier.

Cas d’usage

Perte datacenter ou région cloud
Maintenance majeure sans interruption longue
Erreur humaine ou corruption logique
Ransomware et compromission admin
Migration inter-site ou inter-cloud
Audit continuité, cyber assurance, conformité

Criticité métier→RPO/RTO→Mode réplication→Site cible→Runbook testé

Avantages

Réduit indisponibilité métier
Structure la continuité au-delà du simple backup
Permet prioriser applications par criticité
Facilite tests et preuves d’audit
Peut réduire perte de données selon mode choisi

Risques / limites

Complexité réseau, DNS, IAM et dépendances externes
Réplication peut propager corruption ou ransomware
RTO/RPO annoncés souvent faux sans fire drill
Failback plus difficile que failover
Coût standby et licences souvent sous-estimé

Matrice de décision DR

Question	Décision à prendre
Perte de données acceptable ?	RPO zéro, minutes, heures ou jour. Plus le RPO est bas, plus la solution coûte cher et devient complexe.
Délai de reprise acceptable ?	RTO réel : infra + données + réseau + DNS + identité + validation métier.
Quelle distance ?	Metro/sync si faible latence ; async si distance inter-région ou inter-pays.
Quelle menace ?	Panne site, erreur humaine, ransomware, corruption logique, compromission admin, perte cloud region.
Quelle architecture app ?	Monolithe VM, base critique, microservices, Kubernetes, SaaS, object storage, multi-site.
Quelle preuve ?	Fire drill documenté, RPO/RTO mesuré, validation métier, rapport et actions correctives.

Règle pratique : réplication ≠ backup ; HA ≠ DR ; DR non testé = DR imaginaire.

Runbook DR de référence

Déclarer incident et geler les changements non essentiels.
Identifier dernier point sain : réplication, backup, snapshot, logs applicatifs.
Vérifier santé du site cible : compute, réseau, stockage, DNS, IAM, secrets, certificats.
Promouvoir bases, volumes, buckets ou clusters secondaires.
Rediriger trafic : DNS, GSLB, load balancer, BGP, VPN, firewall.
Valider techniquement puis métier.
Documenter RTO/RPO réel, écarts et plan de failback.

date
dig app.example.com
curl -I https://app.example.com/health
pg_isready -h db-dr
mysqladmin ping -h db-dr
kubectl get nodes,pods,pvc -A
rclone check source:bucket target:bucket --one-way
systemctl --failed
journalctl -p err -n 100

NO-GO : failover sans décision métier, sans point de restauration identifié, sans DNS/réseau validé, ou sans backup indépendant contre corruption/ransomware.