Vous concevez la reprise après sinistre pour une application de paie à deux niveaux exécutée sur des hôtes VMware sur site. Vous prévoyez d'utiliser Azure Site Recovery (ASR) pour répliquer la VM de base de données et la VM d'application vers Azure. Exigences : vous devez être en mesure d'effectuer un test de reprise après sinistre non perturbateur dans Azure sans impacter les charges de travail sur site, et vous devez vous assurer que la VM de base de données démarre avant la VM d'application lors du basculement. Quelles sont les deux actions que vous devez implémenter dans le coffre Recovery Services ? Choisissez deux.

La création d'un plan de récupération est essentielle pour orchestrer l'ordre de démarrage des VM (base de données avant application) et inclure des actions personnalisées, répondant ainsi à l'exigence de démarrage séquentiel. L'exécution d'un basculement de test vers un réseau virtuel Azure isolé est la méthode standard et non perturbatrice pour valider le plan de reprise après sinistre sans affecter l'environnement de production sur site. L'utilisation du basculement planifié avec l'option de ne pas arrêter le primaire n'est pas une fonctionnalité standard pour les tests non perturbateurs et le basculement planifié est généralement utilisé pour une migration contrôlée avec arrêt de la source. L'activation de la cohérence multi-VM est importante pour la récupération des données, mais ne répond pas directement aux exigences de test non perturbateur ou d'ordre de démarrage. Déclencher un basculement non planifié arrêterait les charges de travail sur site, ce qui contredit l'exigence de non-impact.