Microsoft AZ-801: Reprise après sinistre et continuité des activités — Guide d'étude

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Fait partie du Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La conception de la reprise après sinistre (DR) et de la continuité d’activité (BC) commence par la quantification de deux métriques : l’objectif de temps de récupération (RTO) et l’objectif de point de récupération (RPO). Le RTO représente la rapidité avec laquelle vous devez restaurer le service ; le RPO définit la quantité de perte de données (en temps) qui est acceptable. Ces valeurs déterminent les choix technologiques, la topologie et les coûts. Un RTO faible favorise l’orchestration et l’automatisation (plans de récupération Azure Site Recovery, runbooks et ressources cibles pré-créées). Un RPO faible favorise la réplication continue (ASR) ou la validation synchrone (SQL Always On), tandis qu’un RPO plus élevé peut s’appuyer sur des sauvegardes périodiques (Azure Backup, Windows Server Backup). Les groupes de cohérence multi-VM et les instantanés cohérents avec l’application préservent l’intégrité transactionnelle entre les VM lorsqu’un RPO strict est requis. Le choix du coffre (Recovery Services vault ou Backup vault), la conception de la stratégie de réplication et la planification des sauvegardes sont tous sélectionnés pour atteindre ces objectifs sans dépenses excessives.

Azure Site Recovery : Hyper-V, VMware, orchestration et cohérence

Azure Site Recovery (ASR) fournit une réplication continue et un basculement/une restauration orchestrés pour les machines virtuelles VMware, Hyper-V sur site et Azure IaaS.

Protection Hyper-V

• Stratégie de réplication : Définit le seuil de RPO, la rétention des points de récupération et la cadence des instantanés cohérents avec l’application. Par exemple, définissez le seuil de RPO à 15 minutes, conservez les points de récupération pendant 24 à 72 heures pour une restauration à un instant dans le passé, et prenez des instantanés cohérents avec l’application toutes les 1 à 4 heures. Les stratégies contrôlent la limitation de la bande passante et la compression ; la cohérence multi-VM peut être activée pour les VM associées afin que leurs points de récupération s’alignent.
• Points de récupération : ASR maintient en continu des points cohérents au niveau du crash et des points supplémentaires cohérents au niveau de l’application lorsque la mise au repos VSS réussit. La rétention vous permet de sélectionner des points antérieurs pour atténuer la corruption logique ou les ransomwares.
• Test de basculement : Des exercices non perturbateurs valident les runbooks, l’ordre de démarrage et la mise en réseau. Utilisez un VNet isolé, fournissez des valeurs d’entrée de test (par exemple, les adresses IP des DNS) et assurez-vous que la résolution de noms est isolée. La réplication de production se poursuit sans être affectée, et le nettoyage supprime les artefacts de test après la validation. Établissez une correspondance réseau et testez les mappages de cartes réseau au préalable pour éviter les conflits d’adresses IP.

Protection VMware

• Serveur de configuration : L’appliance sur site qui s’enregistre auprès du coffre Recovery Services, découvre l’inventaire vCenter/ESXi, coordonne la réplication et déploie les agents Mobility Service. C’est le plan de contrôle pour la protection VMware.
• Serveur de processus : Généralement colocalisé avec le serveur de configuration au départ ; il effectue le suivi des modifications, la compression, le chiffrement et le transfert de données vers Azure. Des serveurs de processus en scale-out sont ajoutés pour augmenter le débit et pour positionner l’entrée de données près des hôtes protégés afin de minimiser la latence.
• Serveur cible maître : Utilisé pour la restauration (failback) d’Azure vers VMware. Il reçoit les modifications répliquées pendant la reprotection et fournit une zone d’atterrissage pour que vous puissiez restaurer les charges de travail vers vSphere. Dimensionnez le stockage pour le taux d’écriture agrégé pendant la restauration, et assurez-vous que le débit réseau correspond aux fenêtres de resynchronisation de pointe.
• Mobility Service : Installé dans chaque VM protégée pour capturer les modifications de disque. Maintenez à jour les informations d’identification ou les mécanismes de déploiement, et surveillez la santé de l’agent dans le coffre.

Orchestration et cohérence

• Plans de récupération : Des runbooks déclaratifs pour la reprise après sinistre qui définissent des groupements, l’ordre de démarrage, des étapes d’approbation manuelle et des tâches d’automatisation. Utilisez des runbooks Azure Automation pour reconfigurer les NSG, mettre à jour les enregistrements DNS, préchauffer les caches d’application ou exécuter des scripts SQL. Assignez des groupes logiques tels que les niveaux « Données », « Application » et « Web », et insérez des pauses pour la validation.
• Runbooks : Automatisez les tâches spécifiques à l’environnement comme le basculement des points de terminaison de Traffic Manager, la mise à l’échelle des dépendances PaaS ou la désactivation de la surveillance sur site pendant un basculement pour réduire les fausses alertes. Paramétrez-les pour un basculement de test par rapport à un basculement de production.
• Groupes de cohérence multi-VM : Activez-les pour les niveaux qui partagent le même ordre d’écriture (par exemple, un serveur d’applications et l’enregistreur de journaux de la base de données). Cela garantit un point de cohérence temporelle entre les VM ; cela sacrifie le débit au profit de l’exactitude et doit être limité aux VM réellement interdépendantes.

Impact sur le RTO/RPO

• RPO serré : Préférez ASR avec une réplication agressive et des instantanés cohérents avec l’application, des serveurs de processus dimensionnés pour le débit et des réseaux de réplication dédiés. Pour les bases de données, envisagez la validation synchrone Always On au sein d’une zone métropolitaine.
• RTO serré : Pré-créez les VNet, sous-réseaux et équilibreurs de charge cibles ; utilisez des plans de récupération avec automatisation pour éliminer les étapes manuelles. Utilisez régulièrement des tests de basculement pour établir une référence du RTO attendu.

Sauvegarde et restauration : Azure Backup (MARS, MABS/DPM), coffres et Sauvegarde Windows Server

Azure Backup fournit une protection à un instant T pour les charges de travail sur site et Azure. Choisissez le type d’agent et de coffre approprié en fonction de la charge de travail et des fonctionnalités.

Agent MARS (agent Microsoft Azure Recovery Services)

• Stratégie de sauvegarde : Configurez jusqu’à trois sauvegardes quotidiennes avec une rétention granulaire (quotidienne/hebdomadaire/mensuelle/annuelle) dans le coffre Recovery Services. Sélectionnez la redondance du stockage (LRS ou GRS) et alignez la rétention sur la conformité tout en maîtrisant la croissance du coffre. Planifiez en dehors des pics d’E/S et activez la limitation de la bande passante réseau si nécessaire.
• Sauvegarde de l’état du système : Prise en charge avec MARS pour Windows Server afin de protéger AD, le registre, COM+ et les fichiers de démarrage. À utiliser pour la récupération de contrôleur de domaine (faisant autorité/ne faisant pas autorité) ou la réparation du système d’exploitation sans sauvegarde complète au niveau de l’image.
• Récupération en ligne : Restaurez des fichiers/dossiers en utilisant Parcourir ou Rechercher. La Restauration instantanée monte le point de récupération en tant que volume pour une copie rapide de fichiers. Vous pouvez restaurer vers les chemins d’origine ou alternatifs, et même vers un autre serveur en utilisant les informations d’identification du coffre sur la cible et en vous authentifiant auprès du coffre.
• Gestion de la phrase secrète : L’agent MARS utilise une phrase secrète de chiffrement (AES-256) détenue par le client, générée et stockée localement ; Microsoft ne la possède jamais. La perte de la phrase secrète rend la récupération impossible. Stockez-la dans un emplacement sécurisé et sauvegardé (par ex., un secret Key Vault scellé, adossé à un HSM, avec RBAC). Pour effectuer une rotation, arrêtez la protection et reprotégez avec une nouvelle phrase secrète. Activez les fonctionnalités de suppression réversible et de code PIN de sécurité dans le coffre pour vous protéger contre les arrêts/suppressions malveillants.

Azure Backup avec MABS/DPM et IaaS

• Sauvegarde de récupération complète (BMR) : Utilisez Microsoft Azure Backup Server (MABS) ou System Center DPM pour capturer une BMR pour Windows Server. Cela permet des reconstructions complètes de serveur sur du nouveau matériel ou une VM en démarrant WinRE ou un support d’installation et en pointant vers l’image BMR.
• Récupération vers un emplacement alternatif : Pour les sauvegardes de fichiers/données via MARS/MABS/DPM, restaurez vers un chemin alternatif ou un serveur différent pour éviter d’écraser les données source. Pour les sauvegardes de VM IaaS Azure (dans un coffre Recovery Services), restaurez sur une nouvelle VM, restaurez des disques sur une VM existante ou remplacez des disques. Avec la Restauration inter-région activée sur le coffre, vous pouvez restaurer dans la région jumelée pour les scénarios de panne régionale.
• SQL et SAP HANA dans les VM Azure : Protégez avec des extensions prenant en charge la charge de travail pour réaliser des sauvegardes cohérentes avec l’application et une restauration granulaire de base de données. Alignez la fréquence de sauvegarde des journaux sur le RPO (par ex., 15 minutes) et la rétention sur les besoins de conformité.

Sauvegarde Windows Server (WSB)

• Récupération complète (bare metal) : WSB peut capturer une BMR (volumes système et état du système). Stockez sur un disque ou un volume dédié pour plusieurs points de récupération. Pour les cibles de partage réseau, seule la dernière version est conservée. Récupérez en démarrant à partir d’un support Windows dans WinRE, en sélectionnant « Récupération de l’image système ».
• Sauvegarde de l’état du système : Fournit une récupération rapide d’AD DS, du registre et des fichiers de démarrage. Utile pour les contrôleurs de domaine et les serveurs de configuration. Combinez avec des sauvegardes de fichiers planifiées pour une couverture plus large.
• Planification : Utilisez la console MMC WSB ou wbadmin pour planifier des sauvegardes quotidiennes/horaires. Choisissez entre VSS Complet et Copie selon que vous souhaitez ou non tronquer les journaux d’application. Assurez-vous que les fenêtres de sauvegarde évitent les pics d’E/S et vérifiez l’intégrité du catalogue (wbadmin get versions).

Types de coffres : Coffre Recovery Services vs Coffre de sauvegarde

• Coffre Recovery Services (RSV) : Le coffre traditionnel pour les sauvegardes de VM Azure, les sauvegardes de l’agent MARS, MABS/DPM, la sauvegarde Azure Files, SQL Server dans une VM Azure et SAP HANA dans une VM Azure. Il héberge également les métadonnées ASR. Il prend en charge des fonctionnalités telles que la suppression réversible, le code PIN de sécurité et la Restauration inter-région (le cas échéant).
• Coffre de sauvegarde : Le coffre modernisé pour certaines charges de travail natives d’Azure telles que la sauvegarde Azure Disks et la sauvegarde Azure Blobs, et les serveurs flexibles Azure Database for PostgreSQL. Il utilise Azure RBAC pour l’autorisation du plan de gestion, prend en charge les clés gérées par le client, les options d’immuabilité, et s’intègre avec Resource Guard pour la protection des opérations critiques. Il n’héberge pas les métadonnées ASR et, à ce jour, ne remplace pas le RSV pour MARS/MABS/DPM ou la plupart des sauvegardes de VM IaaS.

Haute disponibilité au niveau de l’application : SQL Always On et DFS Replication

Certains workloads exigent une réplication native qui complète ou remplace la reprise après sinistre (DR) au niveau de l’hyperviseur, en fonction des RTO/RPO.

Always On Availability Groups (AGs)

• Validation synchrone ou asynchrone : La validation synchrone attend que le réplica secondaire durcisse le journal avant de valider la transaction sur le principal, offrant une perte de données quasi nulle (RPO faible) au détriment de la latence et du débit ; à utiliser sur des liaisons à faible latence (généralement métropolitaines). La validation asynchrone n’attend pas le secondaire, permettant des performances plus élevées sur les liaisons WAN avec une perte de données potentielle lors du basculement (RPO plus élevé).
• Conditions de basculement automatique : Le basculement automatique nécessite au moins deux réplicas à validation synchrone avec le basculement automatique activé et synchronisé. Le Windows Server Failover Clustering surveille la santé des nœuds/services ; la politique de basculement flexible de SQL Server définit les niveaux de condition de défaillance (allant des plantages de processus aux problèmes d’E/S graves). La détection de l’état de santé de la base de données peut être activée pour forcer le basculement lorsque la base de données principale est suspecte. La conception du quorum et du témoin (witness) garantit que le split-brain est évité ; assurez-vous que les adresses IP du DNS et de l’écouteur (listener) sont prêtes sur le site de reprise pour une reconnexion rapide des clients.

DFS Replication (DFSR)

• Groupes de réplication et connexions : Un groupe de réplication est un ensemble de serveurs répliquant un ou plusieurs dossiers répliqués. Les connexions définissent la topologie (maillage complet, hub-and-spoke) et la planification/limitation de la bande passante. Utilisez une topologie hub-and-spoke pour la mise à l’échelle et un dépannage plus facile.
• Zone de transit : DFSR utilise une zone de transit (staging area) par dossier répliqué pour conserver les fichiers delta pour la Remote Differential Compression (RDC). Dimensionnez la zone de transit à au moins la taille de votre plus grand fichier et généralement à 1 à 2 fois le volume de modifications quotidiennes attendu (churn) ; un sous-dimensionnement provoque des nettoyages et des tentatives excessifs, nuisant aux RPO/RTO.
• Résolution des conflits : DFSR est multi-maître. Lorsque des modifications simultanées se produisent, DFSR emploie des vecteurs de version et des horodatages ; le dernier rédacteur l’emporte et la copie perdante est déplacée dans le dossier ConflictAndDeleted (espace régi par un quota). Pour éviter les conflits initiaux lors de l’amorçage (seeding), définissez un membre principal uniquement pour la synchronisation initiale. Pour les scénarios unidirectionnels, utilisez des dossiers répliqués en lecture seule. Surveillez les backlogs avec dfsrdiag et ajustez les planifications pour respecter le RPO.

Impact sur l’architecture du RTO/RPO et des plans de reprise d’activité intégrés

• RPO agressif : Privilégier la réplication de base de données synchrone ou ASR avec un traitement des modifications à haute fréquence et des instantanés cohérents avec les applications. Isoler le trafic de réplication et mettre à l’échelle les serveurs de processus. Utiliser les groupes de cohérence multi-VM avec parcimonie, uniquement pour les niveaux étroitement couplés.
• RTO agressif : Pré-provisionner les VNet, sous-réseaux, tables de routage et NSG cibles ; scripter les réaffectations d’adresses IP et les mises à jour DNS via des plans de récupération et des runbooks. Conserver des images de référence (golden images) et des tailles de VM associées à des références (SKU) dont la capacité est disponible. Tester les basculements trimestriellement et après des changements importants.
• Superposition de la protection des données : Combiner ASR (récupération rapide du service) avec Azure Backup (restauration à un instant T) pour faire face à la fois aux pannes catastrophiques et à la corruption logique. Pour les contrôleurs de domaine, associer les sauvegardes de l’état du système (MARS ou WSB) à des basculements de test ASR pour valider une récupération sécurisée contre la restauration USN (rollback). Pour les services de fichiers, DFSR fournit une haute disponibilité intra-site/inter-sites, avec Azure Backup pour une récupération résistante aux rançongiciels.

Scénario de problème pratique

Fabrikam, Inc., un fabricant mondial, exploite un environnement mixte : Hyper-V pour les niveaux applicatifs de l’ERP, VMware pour le middleware hérité, des groupes de disponibilité (AG) SQL Server 2019 pour les bases de données, et de grands serveurs de fichiers Windows utilisant DFS Replication. Les impératifs métier exigent un RTO ≤ 1 heure et un RPO ≤ 15 minutes pour l’ERP ; les autres charges de travail peuvent tolérer un RTO de 4 heures et un RPO de 24 heures.

1. Classifier les charges de travail et les objectifs de RTO/RPO

• Les VM applicatives/web de l’ERP et les AG SQL sont identifiées comme Tier 1 (RTO 1h, RPO 15m). Le middleware et les services de fichiers sont Tier 2/3.
• Pourquoi : Garantit que les objectifs les plus stricts guident les choix de réplication et d’orchestration.

2. Implémenter ASR pour les niveaux ERP sur Hyper-V

• Installer le fournisseur ASR sur les hôtes Hyper-V et l’enregistrer auprès d’un coffre Recovery Services. Créer une stratégie de réplication avec un seuil de RPO de 15 minutes, des instantanés cohérents avec les applications toutes les heures et une rétention de 48 heures. Activer un groupe de cohérence multi-VM pour les serveurs applicatifs de l’ERP qui partagent des transactions avec l’écouteur SQL.
• Pourquoi : La réplication continue et les points de contrôle cohérents avec les applications permettent d’atteindre le RPO de 15 minutes tout en maintenant la cohérence du niveau.

3. Implémenter ASR pour le middleware VMware

• Déployer un serveur de configuration sur site, avec un serveur de processus colocalisé dimensionné pour le taux de modification projeté. Ajouter un serveur de processus scale-out sur le site le plus grand. Installer le service Mobilité sur les VM protégées. Préparer un serveur cible maître pour la future restauration automatique (failback).
• Pourquoi : L’architecture ASR pour VMware fournit une capture fiable des modifications et un chemin contrôlé pour la restauration automatique (failback) lorsque le site sur site est rétabli.

4. Orchestrer avec des plans de récupération et des runbooks

• Construire un plan de récupération groupant SQL (données), puis les niveaux applicatifs de l’ERP, puis les niveaux web. Insérer des runbooks Azure Automation pour : reconfigurer les NSG, mettre à jour les zones DNS privées pour pointer vers les adresses IP Azure, et basculer les points de terminaison Traffic Manager. Ajouter une étape de validation manuelle avant de mettre le web en ligne.
• Pourquoi : L’automatisation réduit le RTO et l’erreur humaine pendant une crise, en appliquant l’ordre de démarrage correct et l’état réseau attendu.

5. Protéger SQL Server avec des groupes de disponibilité (AG) ajustés par site

• Conserver le réplica principal et un secondaire en validation synchrone dans la région métropolitaine pour un RPO quasi nul ; conserver un secondaire de reprise d’activité distant en validation asynchrone. Configurer le basculement automatique entre les réplicas synchrones avec la détection de l’état de santé de la base de données activée. Intégrer les étapes de basculement du groupe de disponibilité dans le plan de récupération ASR pour une visibilité croisée.
• Pourquoi : Les groupes de disponibilité synchrones offrent le RPO le plus bas pour le niveau de base de données ; ASR fournit l’orchestration du site autour de cette configuration.

6. Superposer les sauvegardes avec Azure Backup

• Pour les serveurs Windows sur site nécessitant une protection des fichiers et de l’état du système, déployer l’agent MARS et configurer des stratégies avec des sauvegardes quotidiennes et une rétention de 30/52/7 (quotidienne/hebdomadaire/annuelle). Stocker et protéger la phrase secrète de chiffrement dans Azure Key Vault (adossé à un HSM). Utiliser MABS pour capturer des images BMR (Bare Metal Recovery) pour les serveurs d’applications critiques afin de permettre une reconstruction complète si nécessaire. Activer la suppression réversible (soft delete) et le code PIN de sécurité sur le coffre.
• Pourquoi : La restauration à un instant T protège contre la corruption logique et les rançongiciels, en complément du basculement rapide d’ASR.

7. Renforcer DFSR et les services de fichiers de sauvegarde

• Revoir la topologie du groupe de réplication (hub-and-spoke), s’assurer que les zones de transit sont dimensionnées à 1,5 fois le taux de modification quotidien, et ajuster les planifications pour maintenir une réplication quasi temps réel intra-région. Protéger les partages avec MARS/MABS pour une rétention à long terme et des tests de restauration vers un emplacement alternatif.
• Pourquoi : Un réglage approprié de DFSR répond aux besoins de disponibilité au quotidien, tandis que les sauvegardes offrent une sécurité de restauration (rollback).

8. Valider avec des basculements de test et des runbooks documentés

• Exécuter des basculements de test ASR trimestriels vers un VNet isolé, valider la fonctionnalité de l’ERP avec des données masquées, et mesurer le RTO. Effectuer des exercices de restauration : restaurations MARS vers un emplacement alternatif et une récupération BMR complète depuis MABS vers un environnement de test (sandbox).
• Pourquoi : Des exercices réguliers prouvent l’efficacité du plan, révèlent les dérives de configuration et fournissent à la direction une preuve de conformité avec les RTO/RPO.

Cette conception répond aux objectifs de Fabrikam : ASR fournit un RTO inférieur à une heure, les groupes de disponibilité SQL en mode synchrone minimisent le RPO pour les bases de données, et Azure Backup avec MARS/MABS offre une capacité de restauration sécurisée à un instant T et de reconstruction complète de la machine. Les plans de récupération et les runbooks éliminent l’ambiguïté lors des incidents, et DFSR reste optimisé pour la continuité opérationnelle entre les sauvegardes.

← Hyper-V · Tous les domaines · Gestion des identités et des accès pour les environnements hybrides →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →