11 — Availability and Recovery (AZ-305)

A. Vocabulaire HA / DR ⭐

A.1 RTO vs RPO ⭐⭐

Exemples concrets :

Plus RTO/RPO bas → plus cher. Négocier avec business avant design.

A.2 HA vs DR

A.3 Sync vs Async

🚨 Pas de sync cross-region (~80ms RTT eastus↔weu trop élevé). Async = compromis pratique DR.

A.4 Always On Availability Group

Feature SQL Server : 1 primary + N replicas (sync ou async) + failover auto. Azure SQL Business Critical déploie un AG managé MS sous le capot (4 replicas in-cluster) — transparent côté user.

A.5 Zone-redundant vs Geo-redundant

A.6 Listener (DNS stable)

• Sans listener (Active Geo-Rep) : app utilise mysrv-primary.database.windows.net → si failover, change la conn string sur mysrv-secondary.database.windows.net.
• Avec listener (Auto-FG) : app utilise myfg.database.windows.net toujours → MS update DNS auto. App zéro change.

🎯 Toujours préférer Auto-FG (listener) vs Active Geo-Rep en prod.

A.7 Failover vs Failback

• Failover : bascule primary → secondary suite à incident.
• Failback : revenir au primary initial une fois OK.
• Choix : repartir nominal (failback) ou rester sur nouveau primary (parfois plus simple).

A.8 Grace period (Auto-failover)

Délai avant auto-failover sur incident détecté. Évite les bascules sur du faux positif.

Exemple : hoquet réseau 45s. Sans grace → failover déclenché, down 1 min, failback. Avec grace 1h → pas de failover, zéro perturbation.

• Default 1h, range 1-24h
• Court = failover rapide + risque false-positive
• Long = stable + downtime plus long pendant grace si incident réel

B. Compute HA — VM, App Service, AKS ⭐

B.1 VM HA — Availability Sets vs Availability Zones

🎯 Au 305 : AZ > AS quasi-systématique en prod prod. AS = legacy/régions sans AZ.

B.2 VMSS (Virtual Machine Scale Sets)

• N VMs identiques déployées en bulk + auto-scale.
• VMSS Flexible ⭐ (mode moderne) : déployable across zones (1+2+3) → HA cross-AZ + scale.
• VMSS Uniform (mode legacy) : single AZ ou regional.
• Use case : web tier prod, autoscale CPU/RAM/custom, intégration Load Balancer.

B.3 App Service HA

Intra-region : Plans P1v3+ supportent zone-redundancy (option à l'activation). Cross-region : déployer App Service dans 2 régions + Front Door (routing + WAF + global LB).

[Front Door global] → priority/weighted routing
       ↓                      ↓
[App Service eastus]   [App Service weu]
       ↓                      ↓
[SQL DB primary]  ←Auto-FG→  [SQL DB secondary]

B.4 AKS HA

• Control plane zone-redundant ⭐ (Standard/Premium tier, multi-AZ par défaut prod).
• Node pools : spread across 3 AZ (3+ nodes minimum pour HA).
• DR multi-region : 2 clusters AKS dans 2 régions + Front Door + Cosmos DB multi-write + container images répliquées (ACR geo-replication , PREMIUM).

C. Azure Site Recovery (ASR) — DR compute ⭐⭐

C.1 C'est quoi

Service de réplication BCDR pour faire un DR (cross-region) ou migration. Réplique disques + état de VMs.

C.2 Scénarios supportés

C.3 Composants clés

C.4 RTO / RPO ASR

🚨 Le SLA RTO de 1h est plafond, pas la cible. En vrai, failover ASR = minutes.

C.5 Pièges ASR 305

• 🚨 ASR n'est PAS Azure Backup. ASR = DR continu (RPO secondes/minutes). Backup = restauration ponctuelle (RPO heures/jours).
• 🚨 ASR Azure-to-Azure utilise des cache storage accounts (ZRS recommandé prod).
• 🚨 Extensions VM ne sont PAS répliquées → reinstall manuellement post-failover.
• 🚨 Test failover régulier (trimestriel / semestriel) = best practice.
• 🚨 On-demand capacity reservation dans la région cible si workload critique (sinon failover peut manquer de capacity).

D. Azure Backup ⭐⭐ — déconstruction

D.1 RSV (Recovery Services Vault) vs Backup Vault ⭐⭐

Le piège classique du 305 : il y a 2 types de vault différents qui supportent chacun des workloads différents.

🎯 Mnémo : RSV = "Old guard" (VM, Files, SQL on VM, SAP HANA). Backup Vault = "New stuff" (Disks, Blobs, PG, MySQL, AKS). 🚨 Question type : "Quel vault pour backup PostgreSQL Flexible Server ?" → Backup Vault (pas RSV).

D.2 Azure VM Backup (via RSV)

Fréquence :

• Standard policy : 1× par jour (RPO = 24h)
• Enhanced policy ⭐ : multi-snapshots/jour (jusqu'à 6× par jour = RPO 4h min, schedule possibles : 4 / 6 / 8 / 12 / 24h). Supporte Trusted Launch VMs, Premium SSD v2, Ultra Disks, multi-disk crash-consistent, snapshot tier zone-resilient (Instant Restore). Recommandé prod.
• MARS agent : 3× par jour (Windows on-prem)

🚨 Piège exam : "RPO 4h" → Enhanced policy. "RPO 24h" → Standard suffit. Migration Standard → Enhanced GA mais irréversible (one-way).

Restauration :

• OLR (Original Location Restore) : remplace la VM source
• ALR (Alternate Location Restore) : nouvelle VM ailleurs
• File-level restore : monter le RP comme volume → copier fichiers
• Disk-level restore : restaurer juste un disque

Snapshot tier vs Vault tier :

• Snapshot tier (instantané, dans le storage account) : récupération rapide, peu cher
• Vault tier (dans le vault RSV) : récupération lente, plus de retention

Cross Region Restore (CRR) : restaurer dans la région pairée depuis backup GRS → RPO secondary up to 36h (Standard policy).

D.3 Azure Files Backup (via RSV)

• Snapshot-based, jusqu'à 200 snapshots par share
• Retention : daily / weekly / monthly / yearly
• Item-level restore (fichiers individuels) ou share-level restore

D.4 Backup Vault workloads ⭐

Disks

• Snapshot incremental des disques managés
• Vaulted backup : retention longue, coût bas

Blobs

• Operational backup (continuous, snapshot rapide, in-account)
• Vaulted backup (export vers vault, retention longue, immutable)
• Restore : single object ou point-in-time

PostgreSQL (server + flex) / MySQL flex

• Full + diff + log backup
• Long-term retention via Backup Vault (au-delà des 35 jours natifs)
• Geo-restore si GRS

AKS (preview)

• Backup des manifests + persistent volumes
• Restore in-cluster ou cross-cluster

D.5 Backup features avancées 305

D.6 Backup Center ⭐

Hub unifié multi-vault, multi-sub, multi-region pour gouverner tout le backup d'une org.

• View centralisée des jobs, alerts, policies, recovery points
• Compliance reports
• Disponible dans le portail (Backup center)

🎯 "governance + visibilité unifiée backup sur 50 subs" → Backup Center.

E. Azure SQL HA built-in (3 modèles)

Tous les tiers Azure SQL ont HA managé MS transparent. 3 modèles archi selon tier.

Zone-redundant ⭐ : option à activer, replicas sur 3 AZ, SLA → 99.995%, coût +30%.

E.1 Comprendre les modèles archi

• Always On AG (rappel) : feature SQL Server. 1 primaire + N replicas (sync ou async) + failover auto entre eux. Le primary et les replicas sont tous chauds, en mémoire, prêts à prendre la main instantanément.
• Remote Storage (GP) : le compute (VM SQL) est séparé du storage (DB sur Premium Storage Azure). Si le compute crash, MS attache un autre node au même storage → ~30s de "reattach" pendant lesquels la DB est down.
• Local Storage (BC) : compute et data sur SSD local de chaque node. 4 replicas Always On AG in-cluster (1 primary + 3 secondaries). Failover = un des 3 secondaries (déjà chaud, déjà synchro) devient primary en <10s.
• Hyperscale : compute découplé + storage en page servers distribués (jusqu'à 100 TB) + log service séparé. Compute peut rebooter quasi-instant car la data n'a pas à être chargée.

E.2 🚨 Le piège GP vs BC à l'exam ⭐⭐

Techniquement : GP a du HA (~30s reattach). Mais l'exam MS considère que :

• GP HA = "HA avec disruption" (les 30s comptent comme outage business) + pas de read replicas disponible a utilisé.
• BC HA = "True HA seamless" (Always On AG, <10s, transparent) + read replica utilisable.

Donc dès que la question dit "HA" sans qualifier, ils attendent souvent BC.

Vocabulaire exam → tier attendu

E.3 Pièges 305

• 🚨 Premium DTU = Business Critical vCore (même archi Local Storage AG, 2 nommages).
• 🚨 Basic / Standard DTU = GP vCore (même archi Remote Storage).
• 🚨 Basic : max 5 DTU, max 2 GB → micro-jouet, jamais réponse prod 305.
• 🚨 DTU model dans une question = souvent un piège ou un scénario legacy. La bonne réponse moderne est vCore.
• 🚨 GP RTO ~30s = considéré comme "disruption" par MS, pas du seamless HA.
• 🚨 BC readable secondary : exposé via ApplicationIntent=ReadOnly dans la conn string, gratos, pour offloader les lectures (reporting/analytics). Les 4 replicas Always On AG sont inclus = read scale-out GRATUIT.
• 🚨 GP = 1 compute primary, PAS de read scale-out built-in. Pour read scale-out depuis GP → besoin Active Geo-Replication (replica payant) ou migrer vers Hyperscale (page server reads).
  • Piège exam : "read scale-out + zone-redundant + min cost" → BC zone-redundant ⭐ (read replica intégré, pas besoin de DB séparée). Distractor : "GP + Active Geo-Rep" = plus cher et pas zone-redundant natif.

F. Active Geo-Replication

Réplica async DB primary vers jusqu'à 4 secondary regions. Failover manuel uniquement.

Caractéristiques

• Replication DB → DB (pas server → server) : tu crées les 2 serveurs
• RPO <5s typiquement, réplica readable
• Failover manuel :
  • Planned : sync préalable, zéro data loss (migration / drill)
  • Forced : bascule immédiate (catastrophe, peut perdre <5s)
• DNS endpoint change → app(s) liée(s) doit gérer 2 conn strings

Quand l'utiliser

• Replica intra-region (impossible avec Auto-FG qui est cross région Only), même si HA built-in c'est utile car ici on a le CONTROLE sur la replica (connexion string etc)
• Jusqu'à 4 replicas parallèles cross-region
• Read scale-out géographique (queries EU → replica EU)
• Failover manuel strict (médico-légal, finance avec contrôle humain)

Pièges 305

• 🚨 Pas d'auto-failover.
• 🚨 DNS endpoint change au failover → app doit gérer 2 conn strings.
• 🚨 Scope = 1 DB (pas multi-DB atomique).
• 🚨 SQL DB uniquement (pas SQL MI → pour MI → Auto-FG obligatoire).

G. Auto-failover Groups (Auto-FG) ⭐⭐

Wrapper au-dessus d'Active Geo-Replication avec listener DNS stable + failover auto + multi-DB atomique. Standard prod DR Azure SQL. Disponible sur SQL DB et SQL DB MI.

Architecture

[App RW] → myfg.database.windows.net (RW listener)
                ↓
        [Primary server (region A)]
                ↓ async replication
        [Secondary server (region B)]

[App RO] → myfg.secondary.database.windows.net → Secondary

Active Geo-Rep vs Auto-FG ⭐⭐

RTO / RPO ⭐

Pièges 305

• 🚨 Cross-region uniquement (intra-region → Active Geo-Rep).
• 🚨 Replication async → RPO <5s, pas 0.
• 🚨 Tier doit matcher primary/secondary.
• 🚨 SQL MI Auto-FG : nécessite VNet peering bidirectionnel entre les 2 régions.

H. PITR & LTR (Azure SQL) ⭐⭐

H.1 PITR (Point-In-Time Restore)

Built-in, gratuit (jusqu'à un certain volume), basé sur full + diff + log backups automatiques.

🚨 PITR ne peut restaurer que dans la même région et même server par défaut. Pour cross-region → Geo-restore (depuis backup GRS) ou LTR.

H.2 LTR (Long-Term Retention)

Optionnel, config via policy W/M/Y, jusqu'à 10 ans.

Exemples policy LTR :

🚨 Changer la policy LTR n'affecte que les futurs backups (les anciens gardent leur retention initiale).

H.3 PITR vs Geo-restore vs LTR ⭐

H.4 Backup storage redundancy ⭐

Configurable à la création de la DB (et modifiable après, n'affecte que futurs backups) :

🚨 Geo-restore impossible si LRS ou ZRS. Pour DR cross-region → GRS ou GZRS obligatoire.

I. SQL Managed Instance HA

Architecture

• GP : storage HA + 1 compute → RTO ~5 min (plus lent que SQL DB GP qui est ~30s)
• BC ⭐ : Always On AG (4 replicas in-cluster) → RTO <30s
• Auto-FG MI supportés (depuis 2020) → DR cross-region
• Replication subnet → VNet peering bidirectionnel entre régions

Pièges 305

• 🚨 GP MI RTO ~5 min ≠ SQL DB GP (~30s). MI plus lent au failover.
• 🚨 Auto-FG MI : VNet peering bidirectionnel obligatoire.
• 🚨 Subnets dédiés MI (pas de cohabitation).
• 🚨 Seed FG MI peut prendre plusieurs heures (toutes les DBs MI incluses).

J. MySQL / PostgreSQL Flexible Server — HA + Read Replicas + Backup ⭐

J.1 HA modes (Flexible Server)

🚨 Pour cross region (pas de HA natif)→ utiliser Read Replicas cross-region + promotion manuelle pour DR (devient indépendant du premier)

J.2 Read Replicas

Pattern DR Flexible Server : HA zone-redundant intra-region + read replica cross-region pour DR. Failover cross-region = promotion manuelle de la replica.

J.3 Backup (rappel + détails)

• Retention : 1-35 jours (PITR), LTR via Backup Vault pour compliance longue
• Geo-restore : disponible si GRS, restaure dans n'importe quelle région

K. Cosmos DB HA / DR ⭐

K.1 Régions et modèles d'écriture

🎯 "Disponibilité globale 99.999%" → multi-region writes.

K.2 Backup Cosmos DB

🚨 "Restore d'une collection 2h avant l'incident" → Continuous backup PITR. 🚨 "Backup compliance 30j" → activer Continuous backup tier 30d OU Periodic backup avec retention configurée.

K.3 Conflict resolution (multi-region writes)

• LWW (Last Write Wins, default) — basé timestamp
• Custom merge via stored procedure
• ⚠️ Concevoir l'app pour idempotence + résolution

L. Storage HA / DR - Rappel (AZ-104) ⭐

L.1 Les 6 niveaux de redundance

L.2 Storage Account failover

• Customer-managed failover : tu déclenches manuellement la bascule vers la région secondary
• Cible : compte devient LRS (perte redundance pendant le failover)
• RPO : up to 15 min (last sync)
• RTO : minutes
• ⚠️ Action irréversible sans reconfig complète

L.3 Object Replication (Blob)

• Replication async entre 2 storage accounts (source + destination)
• Premium feature, scope container ou blobs spécifiques
• Use case : workflows multi-region, segregation lecture/écriture

L.4 Pièges 305

• 🚨 Premium file shares ne supportent pas GRS → pour DR, utiliser standard tier.
• 🚨 Archive tier non disponible en ZRS (raw archive = LRS/GRS only).
• 🚨 Failover manuel : pas de bascule auto même avec GRS. RPO 15min, perte data possible.

M. Tableau comparatif SQL DB vs MI vs VM ⭐⭐

LE tableau qui t'aide à choisir pendant l'exam.

🎯 Mnémo choix 305 :

• "App standalone, modernizable, PaaS le plus pur" → SQL DB
• "Compat 100% legacy SQL (Agent, CLR, cross-DB, Service Broker)" → SQL MI
• "Control OS + agents tiers + version SQL spécifique" → SQL on VM

N. Tableau scénarios → RTO / RPO ⭐⭐

LE tableau qui te fait économiser 10 min à l'exam.

🎯 Pattern question 305 : on te donne un RTO + RPO + workload → tu picks la solution dans cette table.

O. Decision trees HA / DR

Par workload

Compute (VM) HA intra-region    → Availability Zones (default) ou Availability Set
Compute (VM) DR cross-region    → Azure Site Recovery (ASR)
VM Backup                       → Azure Backup + RSV
App Service HA intra-region     → Zone-redundancy P1v3+
App Service DR cross-region     → Multi-region + Front Door
AKS HA intra                    → Multi-AZ control plane + 3 nodes/AZ
AKS DR cross-region             → 2 clusters + Front Door + ACR geo-rep

Azure SQL DB HA intra           → Zone-redundant BC (built-in)
Azure SQL DB DR cross           → Auto-failover Group ⭐
Azure SQL MI DR cross           → Auto-FG MI + VNet peering bidir
SQL on VM HA                    → Always On AG + AZ deployment
SQL on VM Backup                → Azure Backup SQL extension (RSV)

MySQL/PG Flex HA intra          → Zone-Redundant HA
MySQL/PG Flex DR cross          → Cross-region Read Replica (manual promote)
MySQL/PG Flex Backup            → GRS pour DR + Backup Vault pour LTR

Cosmos DB 99.999% global        → Multi-region writes
Cosmos DB DR cross-region       → Multi-region reads + auto-failover priority
Cosmos DB PITR                  → Continuous Backup tier 7d ou 30d

Storage HA intra                → ZRS
Storage DR cross                → GRS / GZRS (RA si lecture cross-region)
Storage Blob PITR               → Operational backup (Backup Vault)

Par besoin business

"RTO <60s + DNS stable app"             → Auto-FG (SQL) ou Cosmos multi-region
"RTO manual OK + control humain"        → Active Geo-Rep
"Budget restreint OK perdre <7j"        → PITR + LTR
"Compliance 7-10 ans archive"           → LTR ou Backup Vault immutable
"DR région entière"                     → Auto-FG / ASR / GRS (selon workload)
"App globale 99.999% read+write"        → Cosmos DB multi-region writes
"Compliance HIPAA/PCI immutable"        → LTR immutable + Backup MUA + Soft delete
"DR test régulier sans toucher prod"    → ASR Test Failover
"Backup VM + restore granulaire"        → Azure Backup RSV (file-level / disk-level)
"Backup PostgreSQL Flex compliance"     → Backup Vault PITR + LTR

Combo prod critique

Region primaire (eastus):
  - SQL DB BC zone-redundant (99.995% intra)
       ↓ Auto-FG (RPO <5s, RTO <60s)
  - App Service multi-instance ZR
       ↓ Front Door (failover prio)
Region secondaire (weu):
  - SQL DB BC zone-redundant (read replica via FG RO listener)
  - App Service multi-instance ZR

+ Azure Backup (RSV) pour VMs + Files
+ Storage GZRS pour blobs critiques
+ LTR 7 ans immutable pour compliance
+ ASR pour autres VMs DR
+ Defender for SQL + Audit logs → LAW + Sentinel

DEMO

Portail — Active Geo-Replication

1. SQL Database (primary) > Data management > Replicas > + Create replica
2. Target server : créer / sélectionner server dans autre region (ou même region pour read scale-out intra-region)
3. Compute + storage : matcher tier primary
4. Review + Create → seed initiale (plusieurs min)
5. Vérifier statut Readable secondary sous Replicas
6. Failover manuel (sur le secondary replica) : 2 options
   • Failover = planned, sync préalable, zéro data loss
   • Forced failover = immédiat, peut perdre <5s de writes

App doit changer conn string après failover : mysrv.database.windows.net → mysrv-2.database.windows.net. Préférer Auto-FG pour endpoint stable.

Portail — Auto-failover Group ⭐

Pré-requis : 2 SQL Servers déjà créés dans 2 regions (sqlserv1, sqlserv2), DB sur primary.

1. sqlserv1 > Data management > Failover groups > + Add group
2. Failover group name : myfg (→ myfg.database.windows.net, globalement unique)
3. Server (secondary) : sélectionner sqlserv2 (ou créer)
4. Read/Write failover policy :
   • Automatic ⭐ recommandé prod (MS bascule sur incident après grace)
   • Manual (tu déclenches, aucun auto)
5. Read/Write grace period (hours) : 1 (default) à 24 — anti-flapping
6. Configure databases > cocher les DBs à inclure (= group atomique)
7. Create → seed (minutes à heures selon taille)
8. Vérifier les 2 listeners DNS auto-créés :
   • RW listener : myfg.database.windows.net → toujours primary actuel
   • RO listener : myfg.secondary.database.windows.net → toujours secondary actuel (read scale-out)
9. Tester failover : Failover groups > myfg > Failover → swap, app utilisant le RW listener reconnecte sans changement

App zero change : myfg.database.windows.net toujours stable, DNS update transparent côté MS.

Portail — Zone-redundant SQL DB

À la création :

1. SQL databases > + Create > Basics > Compute + storage > Configure database
2. Choisir tier Business Critical ou Hyperscale
3. Cocher Would you like to make this database zone redundant? : Yes > Apply
4. Additional settings > Backup storage redundancy : Zone-redundant backup
5. Review + Create

Sur DB existante (BC/Hyperscale) :

1. SQL Database > Compute + storage > Zone redundant : Yes > Apply

Portail — SQL MI Failover Group

Pré-requis : VNet peering bidirectionnel entre les 2 regions, MI dans subnets dédiés.

1. SQL managed instance (primary) > Data management > Failover groups > + Add group
2. Failover group name : myfg-mi
3. Secondary managed instance : MI cible dans autre region (même tier)
4. Read/Write failover policy : Automatic + grace 1
5. Create → seed peut prendre des heures (toutes les DBs MI incluses)
6. Failover atomique : toutes les DBs basculent ensemble

Portail — Configure PITR retention (Azure SQL) ⭐

1. SQL Server > Backups > Retention policies
2. Sélectionner la (ou les) DB(s) à configurer
3. Configure policies pane :
   • Point-in-time restore configuration :
     • PITR retention period : slider 1 à 35 jours (default 7)
     • Differential backup frequency : 12 hours (default) ou 24 hours
4. Apply

Portail — Configure LTR policy (Azure SQL) ⭐

1. SQL Server > Backups > Retention policies
2. Sélectionner la DB
3. Configure policies pane → Long-term retention configuration :
   • Weekly LTR backups : retention (ex 12 weeks)
   • Monthly LTR backups : retention (ex 12 months)
   • Yearly LTR backups : retention + Week of year (ex 5 years, Week 1)
4. Apply

⚠️ Première création LTR backup : jusqu'à 7 jours avant visibilité dans la liste de restore. 🚨 Changement de policy n'affecte que les futurs backups.

Portail — Geo-restore depuis backup GRS

1. Azure portal > Create a resource > SQL Database
2. Basics : choisir resource group, region (n'importe quelle région)
3. Additional settings > Use existing data : Backup
4. Backup : sélectionner le geo-restore backup disponible (depuis la liste des DB GRS-backed)
5. Review + Create → restore quelques min/h selon volume

🎯 Use case : région primaire down → geo-restore depuis backup GRS dans une autre région.

Portail — Azure Backup VM (via RSV)

1. Create a resource > Recovery Services Vault (cherche "Recovery Services Vault" — le nom legacy "Backup and Site Recovery (OMS)" est retiré)
2. Basics : RG, vault name, region (même région que les VMs à protéger)
3. Networking : Connectivity public ou Private Endpoint
4. Review + Create

Configurer backup VM :

1. Recovery Services Vault > Backup
2. Where is your workload running? : Azure
3. What do you want to back up? : Virtual machine
4. Backup policy :
   • Standard : 1× par jour
   • Enhanced ⭐ : jusqu'à 4× par jour (multi-snap)
   • Retention : daily/weekly/monthly/yearly configurable
5. Add VMs → sélectionner les VMs
6. Enable Backup

Restore :

1. RSV > Backup items > Azure Virtual Machine > [VM]
2. Restore VM :
   • Create new (ALR) ou Replace existing (OLR)
   • File recovery (monter le RP comme volume) ou Disk-level

Portail — Cross Region Restore (CRR) activation

1. Recovery Services Vault > Properties
2. Backup Configuration > Update :
   • Storage replication type : Geo-redundant ⭐ (obligatoire pour CRR)
   • Cross Region Restore : Enable
3. Save

⚠️ Une fois CRR activé sur un vault, impossible de revenir à GRS sans CRR ou LRS une fois le premier backup commencé. Recovery secondary RPO : up to 36h (Standard policy).

Portail — ASR Azure-to-Azure (DR VM cross-region) ⭐

Pré-requis : aucun (le RSV est créé auto par le wizard si pas existant dans la région cible).

1. VM source > Operations > Disaster Recovery
2. Basics :
   • Source : auto-détectée (la VM elle-même, sa region/sub/RG)
   • Target region : choisir la région cible DR (seul vrai input ici)
3. Advanced settings (optionnel — les defaults marchent) :
   • Target resource group + Target virtual network : peut être laissé en auto (ASR crée des resources "-asr")
   • Cache storage account : par défaut LRS v1 créé auto par ASR. Best practice prod : ZRS (modifiable, premium block blob possible si High Churn)
   • Replication policy :
     • Recovery point retention : default 1 jour, max 15 jours
     • App-consistent snapshot frequency : default 0 (disabled), config en heures
     • 💡 Replication elle-même est continue (pas de "RPO threshold" à régler — ce paramètre existe mais sert d'alerte si RPO réel dépasse le seuil)
4. Review + Start replication → seed initiale (heures selon volume)
5. Statut : Protected quand sync terminée

Test failover (DR drill sans impact prod) :

1. Recovery Services Vault > Replicated items > [VM]
2. Test failover → choisir Recovery point + VNet isolé de test
3. Vérifier la VM dans la région cible (VNet isolé)
4. Cleanup test failover quand validation OK

Planned failover (migration ou drill bidir) :

1. RSV > [VM] > Failover → planned, arrête source proprement, zéro data loss

Unplanned failover (catastrophe) :

1. RSV > [VM] > Failover → unplanned, perte data possible (selon RPO)

Test failover (procédure recommandée AZ-305)

1. Backup before : PITR récent dispo
2. Notify users : maintenance window
3. Manual failover : portail / CLI
4. Test app : connectivity read/write
5. Verify replication : nouveau primary → ancien primary (re-protect auto avec FG)
6. Failback si besoin