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)

🏢 Scénarios d'entreprise (CAF/WAF)

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

Contexte business : une enseigne retail FR (500 magasins, e-commerce, ERP SAP HANA) a vu un concurrent se faire ransomwarer il y a 6 mois. Le board exige : « pouvoir récupérer même si un attaquant prend le contrôle de notre tenant Azure et de nos comptes admin ». Choix architectural : un coffre RSV en Immutable Vault verrouillé (Locked) + double validation (MUA) + soft-delete poussé à 180 jours + restauration cross-région (CRR) + backup applicatif de SAP HANA. Architecture / pattern :

• RSV en GRS (réplique tout seul vers la région jumelle) avec CRR activé.
• Immutable Vault en Locked : irréversible, même un Global Admin compromis ne peut pas raccourcir la rétention ni effacer les backups.
• MUA via un Resource Guard placé dans un abonnement séparé géré par l'équipe sécu (pas l'IT) : désactiver le soft-delete ou supprimer le coffre exige l'accord d'un 2e admin sécu.
• Soft-delete poussé au max (180 jours) : large fenêtre pour détecter une attaque après coup.
• Politique de backup quotidien + hebdo + mensuel + annuel (GFS), rétention 7 ans pour SAP (obligation fiscale).
• Pour SAP HANA : backup applicatif avec sauvegarde des logs, ce qui donne un RPO de 15 min et une restauration à un instant précis. Trade-offs assumés :
• Gain : récupération garantie même tenant et comptes admin compromis (immutabilité + MUA + CRR).
• Perte : le verrouillage Locked est irréversible et la double validation ralentit toute opération sur le coffre. Pièges à éviter :
• Le soft-delete seul ne suffit pas : un attaquant avec le rôle Backup Contributor le désactive, purge, et tout est perdu. D'où l'Immutable Vault.
• Immutable Vault « Enabled » (réversible) vs « Locked » (irréversible) : pour une vraie protection anti-ransomware, prendre Locked, même si on ne peut plus revenir en arrière.
• Backup n'est pas du DR : ce montage protège les données, pas la continuité de service. Pour basculer immédiatement si une région tombe, il faut ASR en plus (cf. scénario 3).

📐 Réf. CAF/WAF — BCDR design area : "Use Azure-native backup capabilities" : CAF recommande Azure Backup natif (vs solutions tierces) précisément parce que la config de backup peut être auditée et imposée via Azure Policy pour garantir la conformité org. WAF Reliability/Security : l'immutabilité + soft-delete + MUA sont les contrôles de data protection contre la suppression malveillante. CAF — Business continuity and disaster recovery

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

Contexte business : un groupe d'assurance régional a un siège + 25 agences (10-30 personnes chacune). Chaque agence a un Windows Server fichiers/impression + un AD DS local. Pas de SAN, pas d'admin sur place. Il faut sauvegarder les fichiers et la config serveur vers Azure (pas du DR, juste se protéger d'un ransomware ou d'un incendie). Choix architectural : l'agent MARS sur chaque serveur de fichiers, qui pousse vers un RSV régional au siège, avec la passphrase de chiffrement rangée dans un Key Vault. Architecture / pattern :

• 1 seul RSV au siège (West Europe), en redondance GRS.
• MARS installé sur chaque Windows Server d'agence, le fichier d'identifiants du coffre étant téléchargé par l'IT central.
• On sauvegarde Fichiers/Dossiers + System State (registre, métadonnées AD, permissions de partage), 3 fois par jour maximum.
• La passphrase de chiffrement est rangée automatiquement dans Key Vault (option de la console MARS) : récupérable même si elle est perdue localement.
• Rétention : 30 jours en quotidien + 12 mois en mensuel + 7 ans en annuel (obligation assurance). Trade-offs assumés :
• Gain : protection fichiers/system state vers le cloud sans infra locale ni admin sur place.
• Perte : MARS ne couvre que fichiers + system state d'un serveur (pas de VM ni d'app) et la restauration dépend du lien WAN de l'agence. Pièges à éviter :
• Ne pas confondre MARS et MABS : pour sauvegarder des VMs Hyper-V on-prem, c'est MABS (ou DPM). MARS ne fait QUE fichiers/dossiers + system state d'un seul serveur.
• Perdre la passphrase = backups irrécupérables (Microsoft ne peut PAS la régénérer). Toujours la garder en Key Vault ou dans un coffre physique.
• La restauration fichier par fichier est lente si le lien ADSL de l'agence est faible (5 Mo/s) : pour une grosse restauration, la faire au siège puis transporter le disque.

📐 Réf. CAF/WAF — BCDR : RTO/RPO drive le design : CAF cadre la décision backup/DR sur les RTO/RPO par workload. Ici, des données files de branche avec un RPO de quelques heures (3 backups/j MARS) et pas d'exigence de continuité justifient backup seul (pas d'ASR). Subscription limits à connaître : nombre de RSV et taille de chaque vault sont plafonnés (à considérer si beaucoup d'agences/serveurs). CAF — BCDR design considerations

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

Contexte business : une néobanque (~2M clients), régulée par l'ACPR, a un engagement de RTO 1h / RPO 5min sur son app de paiement. Le core banking tourne sur 8 VMs Azure (West Europe en primaire, North Europe en DR). L'audit annuel exige un test de DR documenté. Choix architectural : ASR (Azure Site Recovery) A2A avec un Recovery Plan orchestré + des tests de bascule trimestriels + Azure Backup en plus pour récupérer la donnée finement. Architecture / pattern :

• RSV créé dans North Europe (la région SECONDAIRE, surtout pas la primaire !) : si West Europe tombe, le coffre reste joignable.
• Politique de réplication : RPO 5 min (cohérent applicatif), points de récupération gardés 24h.
• Recovery Plan (et pas juste une politique de réplication) : ordre de bascule (base d'abord → app → web), scripts Azure Automation avant/après (bascule DNS, préchauffage du cache), et un point de pause manuel pour validation humaine avant la prod.
• Test de bascule trimestriel dans un réseau isolé vnet-dr-test : on vérifie que les VMs démarrent et que l'app marche, sans toucher la prod.
• En parallèle : un RSV séparé pour Azure Backup des VMs (quotidien, 30j). ASR protège la continuité, Backup protège de la corruption logique (un DROP TABLE est déjà répliqué par ASR, mais Backup permet de revenir à hier). Trade-offs assumés :
• Gain : RTO 1h / RPO 5min tenu avec bascule orchestrée et testable, plus une protection contre la corruption logique.
• Perte : ASR + Backup en double = coût supplémentaire et orchestration (Recovery Plan, tests) à maintenir. Pièges à éviter :
• Ne pas confondre politique de réplication (juste RPO + rétention) et Recovery Plan (l'orchestration) : pour un vrai DR géré, toujours un Recovery Plan.
• VM source en disques non managés : ASR refuse. Migrer en disques managés avant d'activer la réplication.
• Lors d'une vraie bascule (région tombée) : (1) vérifier que c'est protégé/sain → (2) Run failover → (3) Reprotect quand la région revient (préalable à un futur failback). Pas de « Initiate replication » ni de « Test failover » pendant une vraie panne.

📐 Réf. CAF/WAF — BCDR : "Employ Azure Site Recovery for Azure-to-Azure VM DR" : recommandation CAF directe — ASR utilise réplication temps réel + automation pour répliquer cross-region et atteindre des RPO/RTO bas, avec des recovery drills sans impacter la prod (= test failover). Azure Policy peut activer la réplication et auditer la protection des VMs à l'échelle. ⚠️ CAF rappelle aussi : éviter les plages d'IP qui se chevauchent entre réseaux prod et DR (sinon failover complexe/retardé). CAF — BCDR design recommendations

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)