Disaster recovery Azure — Site Recovery, Backup et Availability Zones AZ-305

📍 Article principal du cluster : Azure Solutions Architect Expert AZ-305 — guide complet 2026

Ce tutoriel fait partie du cluster certification AZ-305. Pour la vue d’ensemble, lisez d’abord le pilier.

Introduction

Le domaine 3 « Design business continuity solutions » teste votre capacité à concevoir des architectures résilientes face aux pannes : RTO et RPO définis, backups automatiques, disaster recovery cross-region, haute disponibilité multi-zone. Ce tutoriel met en place une architecture de continuité d’activité complète : Azure Backup pour les VMs et SQL, Recovery Services Vault avec Soft Delete, Azure Site Recovery pour la bascule cross-region, et un test de failover réel pour mesurer le RTO atteint.

Prérequis

• Compte Azure et CLI configurés
• Tutoriels précédents AZ-305 terminés
• 40 minutes

Étape 1 — Comprendre RTO, RPO et SLA Azure

Avant de construire, il faut maîtriser le vocabulaire. RTO (Recovery Time Objective) = temps maximal d’indisponibilité acceptable après un incident. RTO 4h = vous tolérez 4 heures sans service avant le rétablissement. RPO (Recovery Point Objective) = perte de données maximale acceptable. RPO 1h = vous acceptez de perdre jusqu’à 1 heure de données. SLA = engagement Azure de disponibilité pour un service.

Exemples de SLA Azure 2026 : VM single-instance avec Premium SSD = 99,9 % (8h45 downtime/an) ; VMs en Availability Set = 99,95 % (4h22) ; Availability Zones = 99,99 % (52 minutes) ; deux régions paired actives = 99,995 % (26 minutes). Ces chiffres tombent à l’examen — savoir comparer les niveaux est attendu.

Étape 2 — Créer un Recovery Services Vault

Le Recovery Services Vault est le coffre où Azure stocke vos backups VMs, files, SQL, et la configuration ASR. Un seul vault par région est généralement suffisant.

az group create --name rg-bcdr --location westeurope

az backup vault create \
  --name rsv-az305-prod \
  --resource-group rg-bcdr \
  --location westeurope

# Activer Soft Delete (par défaut) et Multi-User Authorization recommandés
az backup vault backup-properties set \
  --name rsv-az305-prod \
  --resource-group rg-bcdr \
  --soft-delete-feature-state "Enabled"

Le Soft Delete protège vos backups contre la suppression accidentelle (ou malveillante via ransomware) — un backup supprimé reste récupérable pendant 14 jours minimum. Activé par défaut depuis 2024 mais à vérifier explicitement.

Étape 3 — Backup d’une VM avec policy retention

On créé une VM Linux et on l’enregistre pour backup avec une policy qui garde 30 jours de daily, 12 weekly, 60 monthly, 10 yearly.

# Créer une VM rapide pour la démo
az vm create \
  --resource-group rg-bcdr \
  --name vm-app-prod \
  --image Ubuntu2404 \
  --size Standard_B2s \
  --admin-username azureadmin \
  --generate-ssh-keys

# Créer une policy custom de rétention
az backup policy create \
  --resource-group rg-bcdr \
  --vault-name rsv-az305-prod \
  --name "GoldPolicy" \
  --policy '{
    "schedulePolicy": {
      "schedulePolicyType": "SimpleSchedulePolicy",
      "scheduleRunFrequency": "Daily",
      "scheduleRunTimes": ["2026-01-01T02:00:00Z"]
    },
    "retentionPolicy": {
      "retentionPolicyType": "LongTermRetentionPolicy",
      "dailySchedule": {"retentionDuration": {"count": 30, "durationType": "Days"}},
      "weeklySchedule": {"retentionDuration": {"count": 12, "durationType": "Weeks"}, "daysOfTheWeek": ["Sunday"]},
      "monthlySchedule": {"retentionDuration": {"count": 60, "durationType": "Months"}},
      "yearlySchedule": {"retentionDuration": {"count": 10, "durationType": "Years"}}
    }
  }'

az backup protection enable-for-vm \
  --resource-group rg-bcdr \
  --vault-name rsv-az305-prod \
  --vm vm-app-prod \
  --policy-name GoldPolicy

# Lancer un backup immédiat (initial baseline)
az backup protection backup-now \
  --resource-group rg-bcdr \
  --vault-name rsv-az305-prod \
  --container-name "iaasvmcontainerv2;rg-bcdr;vm-app-prod" \
  --item-name vm-app-prod \
  --backup-management-type AzureIaasVM \
  --retain-until 31-12-2027

La GoldPolicy est un pattern standard production. Pour conformité PCI-DSS qui exige 7 ans de rétention, le yearly retention 10 ans couvre largement. Pour le RGPD-équivalent CDP Sénégal qui exige plutôt 3-5 ans selon le type de données, on adapte.

Étape 4 — Restaurer une VM depuis un backup

Test fondamental : la sauvegarde sans test de restauration ne vaut rien. Microsoft mesure cette discipline en domaine 3.

RP=$(az backup recoverypoint list \
  --resource-group rg-bcdr \
  --vault-name rsv-az305-prod \
  --container-name "iaasvmcontainerv2;rg-bcdr;vm-app-prod" \
  --item-name vm-app-prod \
  --backup-management-type AzureIaasVM \
  --query "[0].name" -o tsv)
echo "Recovery point: $RP"

# Restaurer disques (option : restore complet, file-level, ou disk-only)
az backup restore restore-disks \
  --resource-group rg-bcdr \
  --vault-name rsv-az305-prod \
  --container-name "iaasvmcontainerv2;rg-bcdr;vm-app-prod" \
  --item-name vm-app-prod \
  --rp-name $RP \
  --target-resource-group rg-bcdr \
  --storage-account stbackuprestoreaz305

Trois modes de restauration : Create New VM (clone complet sur Azure), Restore Disks (récupère VHDs pour montage manuel), Replace Existing (écrase la VM source). Pour un test de continuité, Create New VM dans un RG isolé est l’approche safe.

Étape 5 — Azure Site Recovery cross-region

ASR est l’outil de DR Azure : réplique en continu une VM source vers une région cible. En cas de panne régionale, on bascule (failover) vers la région cible en quelques minutes.

# Créer le vault dans la région cible
az group create --name rg-bcdr-dr --location northeurope

az backup vault create \
  --name rsv-az305-dr \
  --resource-group rg-bcdr-dr \
  --location northeurope

# Configuration ASR via portal Azure (recommandé)
# Azure portal: Recovery Services vaults > rsv-az305-dr > Site Recovery > Replicate Application
# Source: rg-bcdr / westeurope, VMs to replicate: vm-app-prod
# Replication policy: 24 heures rétention, app-consistent snapshot 4h, crash-consistent 5min

La RPO ASR typique : crash-consistent 5 minutes, app-consistent 1 heure (avec VSS pour Windows, ou pre-script Linux). Le RTO mesuré dépend de la taille des VMs : généralement 5-15 minutes pour un failover complet d’une VM standard.

Étape 6 — Test de failover ASR sans impact production

Test failover = simule une bascule sans toucher la prod. Critique pour valider que votre DR fonctionne réellement avant l’incident.

# Test failover sur un VNet dédié de test
az network vnet create \
  --resource-group rg-bcdr-dr \
  --name vnet-failover-test \
  --address-prefix 10.99.0.0/16 \
  --subnet-name subnet-test \
  --subnet-prefix 10.99.1.0/24

# Lancer test failover via portail (recommandé) ou via PowerShell
# After test, "Cleanup test failover" supprime les ressources créées

echo "Test failover lancé. Mesurer RTO depuis le démarrage de l'opération jusqu'à app accessible."

Microsoft recommande un test failover ASR tous les 6 mois minimum pour les workloads production. Compte Tenu BCEAO et OHADA exigent un test annuel documenté lors des audits.

Étape 7 — Backups Azure SQL Database et géo-restore

Azure SQL Database fait des backups automatiques : full hebdomadaire, differential 12-24h, transaction log toutes les 5-10 minutes. Rétention par défaut 7 jours, configurable jusqu’à 35 jours.

# Pour rétention long terme (LTR), configurer une policy yearly
az sql db ltr-policy set \
  --resource-group rg-bcdr \
  --server sql-az305-prod-we \
  --database appdb \
  --weekly-retention "P1W" \
  --monthly-retention "P12M" \
  --yearly-retention "P10Y" \
  --week-of-year 1

# Géo-restore depuis n'importe quelle région (DR ultime)
az sql db restore \
  --resource-group rg-bcdr-dr \
  --server sql-az305-dr-server \
  --name appdb-restored \
  --time "2026-04-29T10:00:00" \
  --source-database appdb

Le géo-restore permet de restaurer une base SQL dans une autre région à partir des backups GRS. RPO ~1 heure (réplication asynchrone), RTO ~12 heures (taille dépendante). Pour des RPO plus serrés, utiliser Auto-failover Groups (vu en domaine 2).

Étape 8 — Availability Zones pour HA intra-région

Les Availability Zones (AZ) divisent une région en 3 zones physiquement séparées (datacenters distincts). Déployer en multi-zone garantit 99,99 % SLA.

# VM en AZ specifique
az vm create \
  --resource-group rg-bcdr \
  --name vm-zone1 \
  --image Ubuntu2404 \
  --zone 1 \
  --size Standard_D2s_v5 \
  --generate-ssh-keys

az vm create \
  --resource-group rg-bcdr \
  --name vm-zone2 \
  --image Ubuntu2404 \
  --zone 2 \
  --size Standard_D2s_v5 \
  --generate-ssh-keys

# Standard Load Balancer en zone-redundant pour répartir
az network lb create \
  --resource-group rg-bcdr \
  --name lb-az305-prod \
  --sku Standard \
  --vnet-name vnet-bcdr \
  --subnet subnet-app \
  --frontend-ip-name fe-ip \
  --backend-pool-name backend-pool

Important en 2026 : les régions Azure Africa (Johannesburg JNB) ont 3 AZs depuis 2024. La région BCEAO probable (Lagos en projet pour 2027) aura aussi 3 AZs. West Europe et North Europe ont 3 AZs depuis longtemps.

Comprendre la différence Backup, ASR, Replication, Snapshot

Quatre concepts proches mais distincts. Azure Backup sauvegarde des données vers un Recovery Services Vault — restauration en heures, RPO en heures, conçu pour rétention longue durée et conformité. Azure Site Recovery (ASR) réplique en continu une VM source vers une région cible — bascule en minutes, RPO en minutes, conçu pour DR. Géo-réplication PaaS (Cosmos, SQL, Storage) maintient des copies cross-region des données du service — pas de bascule manuelle, c’est le service lui-même qui gère. Snapshot = copie ponctuelle d’un disque ou volume à un instant T — léger, rapide, utile pour points de restauration mais pas pour DR.

Question d’examen type : « Une application financière demande RTO 15 minutes et RPO 5 minutes ». Réponse : ASR + Auto-failover Group SQL. Erreur classique : penser qu’Azure Backup suffit pour DR — non, le RTO est trop long.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour les fintechs et néobanques régulées BCEAO, le pattern recommandé : Azure SQL Database avec Auto-failover Group entre West Europe et North Europe (RPO < 5 minutes), Azure Backup avec rétention 7 ans LTR pour conformité, ASR pour les VMs legacy critiques (RPO 5 minutes). Coût total environ 200-400 USD/mois pour un parc de 5-8 VMs et 2-3 bases SQL — investissement nécessaire pour passer les audits réguliers de l’autorité de tutelle.

Pour les ONG et associations qui ont moins de ressources, le minimum vital est : Azure Backup avec policy GoldPolicy + Storage GRS sur le compte de backup. Coût marginal 30-50 USD/mois pour une couverture acceptable.

Tutoriels frères

• Stockage Azure end-to-end
• Networking Azure hub-spoke — VNet peering, ExpressRoute, Azure Firewall (à venir)

Pour aller plus loin

• 🔝 Retour au pilier : AZ-305 — guide complet
• Azure Backup : learn.microsoft.com/fr-fr/azure/backup
• Azure Site Recovery : learn.microsoft.com/fr-fr/azure/site-recovery
• SLA Azure : microsoft.com/licensing/docs

FAQ

Combien de temps de rétention pour un backup ?
Selon vos exigences réglementaires : 30-35 jours minimum recommandé pour Azure Backup, jusqu’à 10 ans pour conformité long terme. SQL Database supporte LTR jusqu’à 10 ans aussi.

ASR ou Auto-failover Group SQL ?
ASR pour VMs Windows/Linux (réplication infra). Auto-failover Group pour bases SQL (réplication PaaS). Souvent combinés : ASR pour les serveurs apps, AFG pour les bases.

Mots-clés secondaires : azure backup vault, azure site recovery, recovery services vault, soft delete backup, sql ltr retention, availability zones azure, rto rpo design