12 — Backup & Disaster Recovery

Deux services distincts à ne pas confondre :

• Azure Backup : sauvegarde de données (récupération granulaire, conservation longue durée).
• Azure Site Recovery (ASR) : réplication continue de VMs entières pour basculer en cas de désastre (région down).

A. Recovery Services Vault (RSV) & Backup Vault

Container régional qui stocke les backups + recovery points.

2 types de vaults

Pour AZ-104 : retenir RSV = VM backup + ASR, Backup Vault = workloads "modernes" (disks, blobs).

Caractéristiques

• Régional : 1 RSV = 1 region. Les ressources backupées doivent être dans la même région que le RSV.
• Redondance : LRS / GRS / ZRS (à choisir à la création, non modifiable une fois des items protégés).
• Soft-delete : 14 jours par défaut, 14-180 jours configurable. Sur la suppression d'un backup, il reste récupérable.
• Immutable Vault ⭐ : empêche toute modif/suppression de backups (anti-ransomware). 2 modes :
  • Enabled : peut être désactivé
  • Locked : irréversible (compliance forte)
• Multi-User Authorization (MUA) : opérations sensibles (disable soft-delete, delete vault) nécessitent l'approbation d'un second admin (via Resource Guard).

🚨 Supprimer un RSV — workflow obligatoire (piège exam)

Tu ne peux pas delete un RSV qui a des dépendances. Erreurs typiques : Vault cannot be deleted as there are existing resources within the vault.

4 dépendances à éliminer dans cet ordre :

1. Stop backup of each protected item
   → RSV > Backup items > [item] > Stop backup
   → Choisir : "Retain Backup Data" OU "Delete Backup Data"

2. Delete backup data (si pas fait à l'étape 1)
   → Les items passent en SOFT-DELETED state pendant 14 jours

3. Wait OR Undo soft-delete + permanently delete
   → Pour delete maintenant : disable soft-delete d'abord (risqué)
   → Ou attendre 14 jours pour delete auto

4. Unregister storage accounts
   → RSV > Backup Infrastructure > Storage Accounts > Unregister

💡 Piège exam : la première étape est toujours "Stop backup of each item" (pas modify lock, pas delete data direct, pas modify policy). Sans ça, le delete refuse.

Restore VM — option "Replace Existing" (détail piège exam)

L'option Replace Existing lors d'un restore VM fait :

1. ✅ Snapshot la VM actuelle avant restore (sauvegarde dans staging location)
2. ✅ Remplace les disks attachés par ceux du recovery point sélectionné
3. ⚠️ Les anciens disks détachés sont gardés dans le RG (pas supprimés) → tu peux les re-attacher manuellement si besoin

Exemple piège : tu as ajouté un data disk après le backup, puis tu fais Replace Existing depuis un recovery point antérieur. Le nouveau data disk n'est pas dans le recovery point → après restore il est détaché de la VM mais existe toujours dans le RG. Pour le récupérer : VM > Disks > Attach existing disks → re-attacher le data disk → tes données reviennent.

→ Ne jamais delete un disk détaché post-restore avant d'avoir vérifié son contenu.

B. Azure Backup — workloads

VM Azure

• Azure VM extension déployée auto (VMSnapshot ou VMSnapshotLinux) → snapshot disks via APIs.
• Backup app-consistent (Windows VSS / Linux pre-post scripts) ou crash-consistent.
• Stockage : snapshot tier (rapide) + vault tier (longue durée).
• Restore options :
  • Create new VM (depuis un recovery point)
  • Restore disks (attacher à une autre VM)
  • Replace existing (overwrite)
  • File recovery (mount le recovery point comme drive et copier les fichiers)
  • Cross Region Restore (CRR) : restore depuis la région secondaire (RSV en GRS)

Backup Policy (VM)

• Frequency : Daily / Weekly / Hourly (Enhanced policy).
• Retention : daily/weekly/monthly/yearly retention (avec règles GFS).
• Multiple policies par RSV.

SQL Server in VM

• Workload-specific (vs VM-level qui est plus générique).
• Backup logs SQL (point-in-time restore avec RPO 15min).
• Pre-req : AzureBackupWindowsWorkload extension + Workload backup config.

SAP HANA in VM

• Pareil que SQL : workload backup, log backups.
• Certifié par SAP.

Azure Files

• 2 modes :
  • Snapshot-based (legacy) : snapshot dans le SA lui-même. Pas cross-region.
  • Vaulted backup ⭐ : copie dans un Backup Vault, supporte cross-region, immutability, retention longue.
• Restore : full share ou item-level.

Disks

• Backup direct des managed disks via Backup Vault.
• Snapshot incrémental, restore en quelques minutes.

Blobs

• Backup operational (versioning + change feed + soft-delete) → recovery point-in-time dans le SA.
• Backup vaulted : copie dans Backup Vault (cross-region + immutability).

C. MARS Agent (on-prem → Azure)

Microsoft Azure Recovery Services Agent : agent Windows léger pour backup fichiers/dossiers/system state d'un serveur on-prem (ou VM Azure) vers RSV.

Architecture

• Agent installé sur le Windows Server à backuper.
• Auth : vault credentials file (téléchargé depuis le portail) + passphrase de chiffrement.
• Données chiffrées côté client avec la passphrase → MS ne peut pas les lire.
• ⚠️ Si tu perds la passphrase, tu perds tes backups (MS ne peut pas la récupérer).
• Possibilité de stocker la passphrase dans Key Vault automatiquement depuis MARS console.

Capabilities

• Files, folders, System State (Windows Server : registry, AD, IIS metadata).
• ❌ Pas de backup app-consistent complet (pas SQL/Exchange) → pour ça utiliser MABS (Microsoft Azure Backup Server) ou DPM.
• Schedule : 3 backups/jour max.
• Retention : jusqu'à 99 ans.

MARS vs MABS vs DPM

🚨 Piège exam — "quel agent pour backup VM on-prem vers Azure ?" :

• VM Hyper-V / VMware on-prem → MABS (ou DPM si System Center).
• JAMAIS MARS pour backup de VM ! MARS = files/folders/system state d'un serveur uniquement.
• Files seuls d'un Windows Server on-prem → MARS (léger, direct vers RSV).

Pour VM Hyper-V on-prem en DR (réplication, pas backup) → ASR (Site Recovery Provider sur Hyper-V host) — voir section E.

D. App Service Backups

Snapshot de la config + content + DB (option) d'une App Service.

Caractéristiques

• Disponible à partir du tier Standard.
• Cible : Storage Account (à toi).
• DB supportées : SQL DB, MySQL in-app, PostgreSQL.
• Manual ou scheduled (frequency, retention 0-90 jours).
• Restore : nouvelle app ou overwrite existante.
• Limite : taille max 10 GB (incluant DB). Au-delà → autres méthodes (export DB séparément).

Backup vs Snapshot

• Backup : explicite, vers ton Storage Account (récupérable même si l'app est supprimée).
• Snapshot : auto par MS, restore via support ticket (Premium tier+ uniquement).

E. Azure Site Recovery (ASR)

Réplication continue de VMs vers une autre région (DR) ou on-prem → Azure (migration / DR).

Scenarios supportés

Architecture (Azure-to-Azure)

• RSV dans la région cible / SECONDAIRE (la région où tu vas faire le failover) — PAS dans la région primaire.
• ASR installe un agent sur la VM source (ou utilise l'extension Azure VM Agent).
• Réplication async vers un Cache Storage Account dans la région source → puis managed disks dans la région cible.
• RPO : ~30 secondes (Crash-consistent) ou ~5 min (App-consistent).
• RTO : minutes (failover).

🚨 ASR setup — 3 étapes obligatoires (piège exam)

1. Créer un RSV dans la région SECONDAIRE
   (pas primary ! sinon impossible de failover si primary down)

2. Installer + configurer l'agent ASR sur les VMs
   (Mobility service extension, déployée auto par ASR via VM Agent)

3. Créer un RECOVERY PLAN (pas une replication policy seule)
   → orchestration : ordre VMs, dépendances, scripts pre/post failover
   → vs. Replication policy = juste RPO + retention (insuffisant pour DR)

💡 Piège typique : si la question demande "DR via failover" → la réponse contient Recovery Plan (orchestration). Si la question demande "réplication des données" → Replication policy. Ne pas confondre.

Composants clés

• Replication policy : RPO, retention des recovery points (jusqu'à 24h pour app-consistent), frequency.
• Recovery Plan : orchestration multi-VM (séquence de failover, scripts Azure Automation runbook pre/post failover, pauses manuelles).
• Test failover : sandbox dans un VNet isolé, valide le DR sans impacter prod.
• Failover : passe les VMs en region cible.
• Failback : re-protect inverse + retour en région source.

🚨 Failover réel (région primaire down) — 3 actions à choisir (piège exam QCM "Select THREE")

Quand la région source est en outage et que la replication est déjà en place, les 3 étapes pour basculer :

1. Verify the VMs are protected and healthy
   → Check dans le RSV que les replicated items sont en état "Protected"
   → Confirme un recovery point récent dispo

2. Run a failover
   → Choisir un recovery point (latest processed / latest crash-cons / latest app-cons / specific)
   → ASR power-on les VMs dans la région cible

3. Reprotect the virtual machines
   → Une fois la région source dispo à nouveau : inverser la replication (cible → source)
   → Préalable obligatoire pour pouvoir failback ensuite

⚠️ Mauvaises réponses fréquentes :

• Initiate replication = c'est la 1ère étape du setup initial, pas du failover. Si la replication est déjà en place (énoncé typique), cette action n'a pas de sens à ce stade.
• Run a test failover = pour les drills DR, pas pour un failover réel en cas d'outage.
• Run a failback = inverse du failover, à faire après que la région source soit revenue + après reprotect. Pas pendant l'outage.

À retenir AZ-104

• ASR = DR, pas backup.
• 1 VM = 1 replication target à la fois.
• Recovery Plan = automatisation du failover (séquence VMs + runbooks).
• Test failover obligatoire avant un vrai DR test.

🚨 ASR + Managed Disks (prérequis) : ASR exige que la VM source utilise des managed disks. Les unmanaged disks (legacy, dans un Storage Account) ne sont pas supportés. Conversion unmanaged → managed via VM > Disks > Migrate to managed disks (VM doit être stoppée).

⚠️ Piège exam : VM avec "Managed disks: Disabled" + scénario "move single-VM to AZ via ASR" → la 1ère action est enable managed disks, pas changer region (souvent déjà AZ-capable) / OS disk type / Ultra Disk compatibility.

Azure Business Continuity (ABC) center

Nouvelle interface unifiée (2024+) pour gérer Backup + ASR + DB-native backups en un seul endroit. À noter : monitoring / inventaire global du DR estate.

F. Sécurité Backup (anti-ransomware)

DEMO — chemins portail

Créer un Recovery Services Vault

1. Recovery Services vaults > Create → region, redundancy (LRS/GRS/ZRS), CRR optionnel
2. Properties : configurer soft-delete retention, Immutability, MUA (Resource Guard)
3. Backup configuration : storage replication = LRS / GRS / ZRS (verrouillé après 1ère protection)

Backup VM Azure

1. Depuis la VM : VM > Backup > Enable backup → choisir RSV + policy
2. OU depuis le RSV : Backup > + Backup > Workload: Azure / Type: VM → sélectionner les VMs
3. Backup now : déclenche un backup ad-hoc
4. Restore : Backup items > [VM] > Restore VM → choisir recovery point + type (new VM / restore disks / file recovery)

File Recovery (item-level)

1. RSV > Backup items > [VM] > File Recovery > Download Script
2. Lancer le script PowerShell sur ta machine → mount des drives temporaires
3. Copier les fichiers
4. Unmount

Configurer Backup Files

1. Storage Account > File Shares > Backup (snapshot-based) OU
2. Backup Vault > + Backup > Datasource: Azure Files > Vaulted backup
3. Restore : full share ou item-level

Backup avec MARS (on-prem)

1. RSV > Backup > Workload: On-prem / Type: Files & folders + System State → Download Agent + vault credentials
2. Installer MARS sur le serveur Windows
3. Register : sélectionner vault credentials file + définir passphrase (sauvegarder ! ou Key Vault)
4. Schedule backup : choisir items + frequency + retention
5. Trigger backup

App Service Backup

1. App Service (Standard+) > Backups > Configure
2. Choisir Storage Account + container destination
3. Schedule : frequency, retention (0-90j), DB option (SQL, MySQL)
4. Backup now ou wait scheduled
5. Restore : Backups > Restore → new app / overwrite

Configurer ASR pour VM Azure (A2A)

1. Source VM > Disaster recovery > Enable replication
2. Choisir : target region, target RG, RSV dans target region
3. Cache storage account : Azure crée auto (peut customiser)
4. Replication policy : default 24h (RPO 5min app-consistent, 30s crash-consistent)
5. Wait initial replication (peut prendre h selon taille)

Test failover

1. RSV > Replicated items > [VM] > Test failover
2. Choisir un VNet isolé (pas le prod !)
3. ASR crée une copie de test dans la target region → vérifier que la VM démarre + l'app fonctionne
4. Cleanup test failover quand fini → supprime les ressources de test

Failover (real)

1. RSV > Replicated items > [VM] > Failover
2. Recovery point : latest processed / latest crash-consistent / latest app-consistent / specific
3. ASR shuts down source (option) + power on target VM
4. Après stabilisation : Commit failover → confirmer
5. Re-protect : inverser la replication (target → source) pour pouvoir failback ensuite

Configurer ASR pour Hyper-V on-prem → Azure

1. RSV > Site Recovery > Prepare infrastructure > On-prem to Azure > Hyper-V
2. Download + install Azure Site Recovery Provider sur le Hyper-V host
3. Register le Hyper-V site dans le RSV
4. Enable replication sur les VMs Hyper-V → cible Azure VM
5. Replication continue + tests/failovers comme A2A

Cross Region Restore (CRR)

1. RSV > Properties > Cross Region Restore : Enable (le vault doit être GRS)
2. Lors du restore : option Secondary Region apparaît
3. Restore depuis la copie du backup en région secondaire (utile si la région primaire est down)

🏢 Scenarios d'entreprise réels — pensée d'architecte

Comment ces services s'utilisent dans la vraie vie. Pour chaque scenario : contexte business → choix techniques (uniquement les services traités dans la fiche) → pièges typiques.

Scenario 1 : Retail — protection anti-ransomware niveau enseigne nationale

Contexte business : enseigne retail FR (500 magasins, e-commerce, ERP SAP HANA) — déjà victime d'un ransomware concurrent il y a 6 mois. Demande board : "garantir qu'on récupère même si un attaquant pwn notre tenant Azure et nos comptes admin". Choix techniques : RSV avec Immutable Vault LOCKED + Multi-User Authorization (MUA) + soft-delete 180j + CRR (Cross Region Restore) + workload backup SAP HANA. Architecture / pattern :

• RSV en GRS (réplication automatique vers paired region) + CRR activé
• Immutable Vault = Locked (irréversible : même un Global Admin compromis ne peut pas raccourcir la retention)
• MUA via Resource Guard dans une sub séparée gérée par l'équipe sécu (pas IT) : disable soft-delete / delete vault → besoin approbation 2e admin sécu
• Soft-delete poussé à 180j (max) — fenêtre large pour détecter une attaque post-fait
• Policy backup : daily + weekly + monthly + yearly (GFS) — retention 7 ans pour SAP (compliance fiscale)
• Pour SAP HANA : workload backup avec log backups → RPO 15min, point-in-time restore Pièges à éviter :
• Soft-delete sans Immutable Vault = un attaquant avec Backup Contributor désactive soft-delete → purge → tout perdu
• Immutable Vault Enabled (réversible) vs Locked (irréversible) : pour anti-ransomware fort = Locked, malgré l'impossibilité de revenir en arrière
• Backup ≠ DR : ce setup protège la data mais pas la continuité. Pour bascule immédiate region down → ASR en parallèle (cf scenario 3)

Scenario 2 : Réseau de PME — branch offices, backup files vers Azure (MARS)

Contexte business : groupe d'assurance régional, siège + 25 agences locales (10-30 employés chacune). Chaque agence a un Windows Server file/print + AD DS local. Pas de SAN, pas d'admin local. Besoin backup files + config serveur vers Azure (pas DR, juste protection ransomware/incendie). Choix techniques : MARS agent sur chaque file server vers un RSV régional au siège + passphrase chiffrement stockée en Key Vault. Architecture / pattern :

• 1 RSV unique au siège (région West Europe), redondance GRS
• MARS installé sur chaque Windows Server agence → vault credentials file téléchargé par l'IT central
• Backup : Files/Folders + System State (registry, AD metadata, share permissions) — 3 backups/jour max
• Passphrase de chiffrement stockée auto dans Key Vault (option MARS console) → si perdue localement, récupérable
• Retention 30j daily + 12 mois monthly + 7 ans yearly (compliance assurance) Pièges à éviter :
• Confondre MARS et MABS : pour backup de VMs Hyper-V on-prem → c'est MABS (ou DPM). MARS ne fait QUE files+folders+system state d'1 serveur
• Perdre la passphrase = backups irrécupérables (MS ne peut PAS la régénérer) → toujours sauvegarder en KV ou coffre physique
• Restore item-level lent depuis Azure si pipe ADSL agence faible (5MB/s) → pour gros restore, faire au siège puis transporter disque

Scenario 3 : Fintech — DR cross-region pour core banking

Contexte business : néobanque (~2M clients), réglementée ACPR, RTO contractuel 1h / RPO 5min sur l'app de paiement. Core banking sur 8 VMs Azure (région West Europe primary, North Europe DR). Audit annuel exige drill DR documenté. Choix techniques : ASR (Azure Site Recovery) A2A avec Recovery Plan orchestré + Test failover trimestriels + Azure Backup en plus pour la data récupération granulaire. Architecture / pattern :

• RSV créé dans North Europe (région SECONDAIRE — surtout pas en primary !) → si West EU down, le vault reste joignable
• Replication policy : RPO 5min (app-consistent), retention recovery points 24h
• Recovery Plan (pas juste replication policy) : ordre de failover (DB d'abord → app tier → web tier), scripts Azure Automation pre/post (DNS swap, warm-up cache), point de pause manuel pour validation humaine avant prod
• Test failover trimestriel dans un VNet isolé vnet-dr-test → vérifie démarrage VMs + l'app reste fonctionnelle, sans toucher prod
• En parallèle : RSV séparé pour Azure Backup des VMs (daily 30j) → ASR protège la continuité, Backup protège la corruption logique (un dev DROP TABLE = ASR a déjà répliqué la corruption, Backup permet rollback à hier) Pièges à éviter :
• Confondre Replication policy (just RPO + retention) et Recovery Plan (orchestration) — pour vrai DR géré, toujours un Recovery Plan
• VM source en unmanaged disks : ASR refuse → migrer en managed disks avant d'activer la replication
• Lors du failover réel (région down) : (1) verify protected/healthy → (2) Run failover → (3) Reprotect quand région revient (préalable à un failback futur). Pas de "Initiate replication" ni de "Test failover" lors d'un vrai outage

Scenario 4 : SaaS — App Service backup avant déploiement risqué

Contexte business : équipe DevOps SaaS — déploie une migration de schéma SQL avec breaking change sur une App Service Standard. Veut un snapshot complet (config + content + DB) pré-déploiement, restaurable en <30min si rollback nécessaire. Choix techniques : App Service Backup scheduled + ad-hoc avant chaque release + Storage Account dédié sa-appbackups + retention 30j. Architecture / pattern :

• App Service en tier Standard minimum (Free/Basic ne supportent pas backup)
• Backup configuré vers SA dédié (container privé), retention 30j
• 1 backup scheduled daily + 1 ad-hoc déclenché par pipeline CI/CD avant chaque déploiement breaking (via az webapp config backup create)
• Restore en cas de rollback : Backups > Restore > Overwrite existing → 5-20min selon taille (limite 10GB incluant DB)
• En complément : App Service snapshots (auto MS, Premium tier) → restore via ticket support (filet de secours indépendant) Pièges à éviter :
• Limite 10GB backup max (incluant DB) → si app + DB > 10GB → exporter la DB séparément via bacpac, backup app seul
• Backup ne va pas dans un RSV (App Service backup = vers Storage Account à toi, pas un Recovery Services Vault)
• Restore = nouvelle app OU overwrite : overwrite remplace tout (perte des changements post-backup) — ne JAMAIS overwrite sans avoir validé qu'on a bien le bon point de restauration

Sources :

• Immutable Vaults
• ASR Azure-to-Azure architecture
• MARS Agent overview