Questions générales sur Azure Site Recovery

Site Recovery contribue à mettre en œuvre la stratégie de continuité d’activité et de récupération d’urgence (BCDR) de votre entreprise en coordonnant et en automatisant la réplication de machines virtuelles Azure entre des régions, de machines virtuelles et serveurs physiques locaux sur Azure et de machines locales sur un centre de données secondaire. Plus d’informations

Non, Azure Site Recovery ne prend pas en charge les charges de travail Docker s’exécutant sur des machines virtuelles. Pour protéger ces machines virtuelles avec Site Recovery, excluez les disques sur lesquels Docker est installé.

Site Recovery prend différentes mesures pour garantir l'intégrité des données. Une connexion sécurisée est établie entre tous les services à l'aide du protocole HTTPS. Vous êtes ainsi assuré qu'aucun programme malveillant ou aucune entité extérieure n'altérera les données. Une autre mesure consiste à utiliser des sommes de contrôle. Le transfert de données entre la source et la cible est exécuté en calculant les sommes de contrôle des données entre elles. Cela permet de garantir la cohérence des données transférées.

Azure ne prend pas en charge les adresses MAC persistantes : les logiciels avec des modèles de licence MAC ne peuvent donc pas être utilisés pour la migration d’un environnement local vers Azure ou pour la reprise d’activité.

Non, le service Azure Site Recovery ne prend actuellement pas en charge les disques éphémères.

L’agent Microsoft Azure Recovery Services est utilisé pour la configuration/l’inscription auprès des services Site Recovery et pour la surveillance de l’intégrité de tous les composants. Ce composant est l’un des blocs de construction de base de toute l’infrastructure Azure Site Recovery locale. Il permet de répliquer vos charges de travail sur une autre région Azure à partir d’un site local et de basculer vers Azure en cas de sinistre.

Oui, Site Recovery prend en charge les modèles d’infrastructure dédiée et partagée.

Non. L’identité du locataire reste anonyme. Vos locataires n’ont pas besoin d’accéder au portail Site Recovery. Seul l’administrateur du fournisseur de services interagit avec le portail.

Si vous répliquez sur Azure, les données d’application sont envoyées à Stockage Azure, mais pas au service Site Recovery. Les données sont chiffrées en transit (HTTPS) et restent chiffrées dans Azure.

Non. La relation de facturation d’Azure concerne directement le fournisseur de services. Les fournisseurs de services sont responsables de la création de factures spécifiques pour leurs locataires.

Non, les données sont répliquées vers le stockage Azure de votre abonnement. Lorsque vous effectuez un basculement de test (test de récupération d’urgence) ou un basculement réel, Site Recovery crée automatiquement des machines virtuelles dans votre abonnement.

Oui.

Nous prenons en charge Azure Pack et le système Cloud Platform, ainsi que les déploiements basés sur System Center (2012 et versions supérieures). En savoir plus sur l’intégration d’Azure Pack et de Site Recovery.

Non, vous pouvez répliquer des machines virtuelles Hyper-V seulement sur Azure.

Consultez les détails de la tarification Site Recovery.

Vous pouvez utiliser la calculatrice de prix pour estimer les coûts d’utilisation de Site Recovery.

Pour obtenir une estimation détaillée des coûts, exécutez l’outil Planificateur de déploiement pour VMware ou Hyper-V et utilisez le rapport d’estimation des coûts.

Oui, des frais s’ajoutent pour l’utilisation du compte de stockage de cache lors de la réplication de machines virtuelles avec Site Recovery. Les coûts du compte de stockage de cache restent les mêmes, que le stockage du réplica soit de type disques managés ou disques non managés.

Oui. Chaque instance protégée n’engendre aucun frais Azure Site Recovery pendant les 31 premiers jours. Par exemple, si vous avez protégé 10 instances depuis six mois et que vous connectez une 11e instance à Azure Site Recovery, aucuns frais ne sont facturés pour cette 11e instance pendant les 31 premiers jours. Des frais Azure Site Recovery continuent d’être facturés pour les 10 premières instances, car celles-ci sont protégées depuis plus de 31 jours.

Oui, bien qu’Azure Site Recovery soit gratuit pendant les 31 premiers jours d’une instance protégée, des frais peuvent s’appliquer pour Stockage Azure, les transactions de stockage et le transfert de données. Des frais de calcul Azure peuvent également être facturés pour une machine virtuelle récupérée.

Le test de récupération d’urgence n’engendre aucun coût à part. Des frais de calcul s’ajoutent une fois la machine virtuelle créée, après le test de basculement.

Non, Site Recovery n’intercepte pas les données répliquées et n’a pas d’informations sur les éléments exécutés sur vos machines virtuelles ou serveurs physiques. Les données de réplication sont échangées entre des hôtes Hyper-V, des hyperviseurs VMware ou des serveurs physiques locaux et le stockage Azure ou votre site secondaire. Site Recovery n’a aucun moyen d’intercepter ces données. Seules les métadonnées nécessaires pour coordonner la réplication et le basculement sont envoyées au service Site Recovery.

Le logiciel Site Recovery est certifié conforme aux normes ISO 27001:2013, 27018, HIPAA et DPA. Il fait actuellement l’objet d’une évaluation de conformité aux exigences SOC2 et JAB FedRAMP.

Oui. Quand vous créez un coffre Site Recovery dans une région, nous vérifions que toutes les métadonnées dont nous avons besoin pour activer et coordonner la réplication et le basculement restent au sein de cette région.

Pour la réplication de machines virtuelles et de serveurs physiques vers Azure, le chiffrement en transit et le chiffrement au repos (dans Azure) sont tous deux pris en charge.

Oui, le protocole TLS 1.2 est appliqué par défaut pour le scénario Azure vers Azure Site Recovery.

Les agents de mobilité installés sur les éléments répliqués communiquent avec le serveur de traitement uniquement sur TLS 1.2. Toutefois, la communication entre le serveur de configuration et Azure, et entre le serveur de processus et Azure, peut se faire sur TLS 1.1 ou 1.0. Suivez les instructions pour appliquer le protocole TLS 1.2 sur tous les serveurs de configuration et serveurs de processus configurés par vous-même.

Toutes les communications entre les microservices d’Azure Site Recovery se produisent sur le protocole TLS 1.2. Site Recovery utilise le dernier protocole TLS disponible ainsi que des fournisseurs de sécurité configurés dans le système d’exploitation. Vous devez activer explicitement le protocole TLS 1.2 dans le registre, afin que Site Recovery puisse commencer à utiliser TLS 1.2 pour la communication avec les services.

Vous pouvez activer l’identité managée du coffre Recovery Services en accédant au paramètre Identité. Une fois le coffre inscrit auprès de Microsoft Entra ID, accédez à vos comptes de stockage et attribuez les rôles suivants au coffre :

• Comptes de stockage basés sur Resource Manager (type Standard) :
  • Contributeur
  • Contributeur aux données Blob du stockage
• Comptes de stockage basés sur Resource Manager (type Premium) :
  • Contributeur
  • Propriétaire des données Blob du stockage
• Comptes de stockage Classic :
  • Contributeur de compte de stockage classique
  • Rôle de service d’opérateur de clé de compte de stockage classique

Azure Site Recovery ne suit pas les modifications apportées aux machines virtuelles sources en dehors du système d’exploitation source. Par exemple, si vous utilisez la réplication Azure sur Azure et que vous changez la taille de la machine virtuelle source, le changement de la taille de la machine virtuelle source n’est pas répliqué sur la machine virtuelle cible.

• Machines virtuelles Azure : Site Recovery permet de répliquer n’importe quelle charge de travail exécutée sur une machine virtuelle Azure prise en charge.
• Machines virtuelles Hyper-V : Site Recovery peut protéger toute charge de travail exécutée sur une machine virtuelle Hyper-V.
• Serveurs physiques : Site Recovery peut protéger les serveurs physiques exécutant Windows ou Linux.
• Machines virtuelles VMware : Site Recovery peut protéger toute charge de travail exécutée sur une machine virtuelle VMware.

Vous pouvez utiliser Site Recovery pour protéger la plupart des charges de travail exécutées sur une machine virtuelle prise en charge ou un serveur physique pris en charge. Site Recovery assure la prise en charge de la réplication compatible avec les applications afin qu’elles puissent être récupérées dans un état intelligent. Site Recovery s’intègre aux applications Microsoft, notamment à SharePoint, Exchange, Dynamics, SQL Server et Active Directory, et fonctionne en étroite collaboration avec les principaux fournisseurs, notamment Oracle, SAP, IBM et Red Hat. En savoir plus sur la protection des charges de travail.

Oui. Lorsque vous utilisez Site Recovery pour coordonner la réplication et le basculement dans vos succursales, vous obtenez une orchestration unifiée et l’affichage de toutes les charges de travail de vos succursales dans un emplacement central. Vous pouvez facilement exécuter les basculements et gérer la récupération d’urgence de toutes les succursales à partir de votre siège social, sans vous rendre dans ces succursales.

Oui, Site Recovery prend en charge la récupération d’urgence pour les machines virtuelles Azure entre les régions Azure. Lisez les questions courantes sur la récupération d’urgence des machines virtuelles Azure. Si vous souhaitez effectuer une réplication entre deux régions Azure d’un même continent, utilisez notre offre de récupération d’urgence Azure sur Azure. Vous n’avez pas besoin de configurer le serveur de configuration/serveur de processus ni les connexions ExpressRoute.

Oui, Site Recovery prend en charge la récupération d’urgence des machines virtuelles VMware locales. Lisez les questions courantes sur la récupération d’urgence des machines virtuelles VMware.

Oui, Site Recovery prend en charge la récupération d’urgence des machines virtuelles Hyper-V locales. Lisez les questions courantes sur la récupération d’urgence des machines virtuelles Hyper-V.

Oui, Site Recovery prend en charge la récupération d’urgence des serveurs physiques locaux exécutant Windows et Linux dans Azure. Découvrez la configuration requise pour la récupération d’urgence sur Azure. Les serveurs physiques sont exécutés en tant que machines virtuelles dans Azure après le basculement. La restauration automatique à partir d’Azure sur un serveur physique local n’est actuellement pas prise en charge. Vous pouvez uniquement effectuer la restauration automatique d’une machine virtuelle VMware.

Non, Azure Site Recovery ne prend pas en charge le déplacement des coffres Recovery Services hébergeant des machines virtuelles protégées.

Azure Site Recovery réplique des données vers un compte de stockage Azure ou des disques managés, via un point de terminaison public. Toutefois, la réplication peut également être effectuée via un VPN de site à site. La connectivité VPN de site à site permet aux organisations de connecter des réseaux existants à Azure ou des réseaux Azure entre eux. Le VPN de site à site se produit via le tunneling IPSec sur Internet, en tirant parti de l’équipement réseau de périphérie local existant et des appliances réseau dans Azure, soit des fonctionnalités natives telles que la passerelle VPN (Virtual Private Network) Azure ou des options tierces telles que Check Point CloudGuard, Palo Alto NextGen Firewall.

• Connectivité privée via l’Internet public à Microsoft Edge
• Coffres de services de récupération configurés pour la sécurité avec des points de terminaison privés
• Réplication sur une connexion de réseau virtuel privé client
• Transition facile vers l’« état futur »
• Aucun SLA ni latence potentiellement plus élevée
• Appareil VPN local disponible requis

Notre partenaire, Riverbed, fournit des instructions détaillées sur l’utilisation d’Azure Site Recovery. Lisez le guide de leur solution.

Oui, vous pouvez utiliser ExpressRoute pour répliquer des machines virtuelles locales vers Azure.

• Azure Site Recovery réplique des données vers un stockage Azure via un point de terminaison public. Vous devez configurer le peering Microsoft ou utiliser un peering public existant (déconseillé pour les nouveaux circuits) afin d’utiliser ExpressRoute pour la réplication Site Recovery.
• Le peering Microsoft est le domaine de routage recommandé pour la réplication.
• La réplication est prise en charge sur un Peering privé uniquement lorsque des points de terminaison privés sont activés pour le coffre.
• Si vous protégez des machines VMware ou des machines physiques, vérifiez que les exigences de mise en réseau pour le serveur de configuration sont également remplies. La connectivité à des URL spécifiques est requise par le serveur de configuration pour l’orchestration de la réplication Site Recovery. ExpressRoute ne peut pas être utilisé pour cette connectivité.
• Une fois que les machines virtuelles ont été basculées vers un réseau virtuel Azure, vous pouvez y accéder à l’aide de la configuration du peering privé avec le réseau virtuel Azure.

L’utilisation de comptes de stockage comme stockage cible n’est pas prise en charge par Azure Site Recovery. Nous vous recommandons de vous servir plutôt de disques managés comme stockage cible pour vos machines. Les disques managés ne prennent en charge que le type LRS pour la résilience des données.

• Hyper-V : Les machines virtuelles Hyper-V peuvent être répliquées toutes les 30 secondes (sauf pour le stockage premium) ou toutes les cinq minutes.
• Machines virtuelles Azure, machines virtuelles VMware, serveurs physiques : Une fréquence de réplication n’est pas pertinente ici. La réplication est continue.

La réplication étendue ou chaînée n’est pas prise en charge. Demandez cette fonctionnalité dans le forum de commentaires.

Ceci n’est pas pris en charge. Demandez cette fonctionnalité dans le forum de commentaires.

Cette fonctionnalité est prise en charge dans le cadre d’une réplication de machines virtuelles VMware et de machines virtuelles Hyper-V sur Azure à l’aide du portail Azure.

Les disques dynamiques sont pris en charge lors de la réplication de machines virtuelles Hyper-V et lors de la réplication de machines virtuelles VMware et physiques sur Azure. Le disque du système d’exploitation doit être un disque de base.

Oui. Pour plus d’informations sur la limitation de bande passante, consultez les articles suivants :

• Planification de la capacité pour la réplication de machines virtuelles VMware et de serveurs physiques
• Planification de la capacité pour la réplication de machines virtuelles Hyper-V sur Azure

Oui. Azure Site Recovery pour le système d’exploitation Linux prend en charge les scripts personnalisés des applications à des fins de cohérence. Le script personnalisé avec options pré- et post-script est utilisé par l’agent Mobilité d’Azure Site Recovery lors de la cohérence des applications. Voici les étapes pour activer cela.

1. Connectez-vous en tant qu’utilisateur racine à l’ordinateur.

2. Basculez le répertoire sur l’emplacement d’installation de l’agent Mobilité Azure Site Recovery. La valeur par défaut est « /usr/local/ASR »
   # cd /usr/local/ASR

3. Remplacez le répertoire par « VX/scripts » sous l’emplacement d’installation
   # cd VX/scripts

4. Créez un script d’interpréteur de commandes bash nommé « customscript.sh » avec des autorisations d’exécution pour l’utilisateur racine.
   a. Le script doit prendre en charge les options de ligne de commande « --pre » et « --post » (notez les doubles tirets)
   b. Lorsque le script est appelé avec l’option pre, il doit geler l’entrée/la sortie de l’application et, lorsqu’il est appelé avec l’option post, il doit libérer l’entrée/la sortie de l’application.
   c. Exemple de modèle -
   

   # cat customscript.sh
   

    #!/bin/bash

    if [ $# -ne 1 ]; then
        echo "Usage: $0 [--pre | --post]"
        exit 1
    elif [ "$1" == "--pre" ]; then
        echo "Freezing app IO"
        exit 0
    elif [ "$1" == "--post" ]; then
        echo "Thawed app IO"
        exit 0
    fi

5. Ajoutez les commandes permettant de geler et de libérer l’entrée/la sortie dans les étapes pre et post pour les applications nécessitant une cohérence des applications. Vous pouvez choisir d’ajouter un autre script spécifiant ceux-ci et l’appeler à partir de « customscript.sh » avec les options pre et post.

Une stratégie de réplication définit les paramètres de l’historique de rétention des points de récupération. La stratégie définit également la fréquence des captures instantanées de cohérence des applications. Par défaut, Azure Site Recovery crée une nouvelle stratégie de réplication avec les paramètres par défaut suivants :

• Un jour pour l’historique de rétention des points de récupération.
• Aucune capture instantanée cohérente avec l’application.

Un point de récupération de cohérence en cas d’incident contient les données sur disque comme si vous aviez débranché le cordon d’alimentation du serveur lors de la capture instantanée. Le point de récupération de cohérence en cas d’incident n’inclut rien de ce qui était en mémoire lors de la capture instantanée.

Aujourd’hui, la plupart des applications peuvent récupérer correctement à partir de captures instantanées cohérentes en cas d’incident. Un point de récupération cohérent en cas d’incident ne suffit généralement pas pour des systèmes d’exploitation de base de données et des applications telles que des serveurs de fichiers, des serveurs DHCP et des serveurs d’impression.

Site Recovery crée un point de récupération cohérent en cas d’incident toutes les 5 minutes.

Les points de récupération cohérents au niveau application sont créés à partir de captures instantanées cohérentes au niveau application. Des points de récupération de cohérence des applications capturent les mêmes données que des captures instantanées de cohérence en cas d’incident, ainsi que de toutes les données en mémoire et toutes les transactions en cours.

En raison de leur contenu supplémentaire, les captures instantanées de cohérence des applications sont davantage sollicitées et prennent le plus de temps. Les points de récupération cohérent au niveau application sont recommandés pour des systèmes d’exploitation de base de données et des applications telles que SQL Server.

Les points de récupération de cohérence des applications capturent toutes les données en mémoire et en cours. Étant donné que les points de récupération capturent ces données, ils nécessitent une infrastructure telle que VSS sur Windows pour suspendre l’application. Si le processus de capture est fréquent, cela peut affecter les performances lorsque la charge de travail est déjà occupée. Nous déconseillons d’utiliser une fréquence faible pour les points de récupération de cohérence des applications en lien avec des charges de travail autres que de bases de données. Même pour une charge de travail de base de données, une heure suffit.

Site Recovery peut créer un point de récupération de cohérence des applications généré à une fréquence minimale d’une heure.

Pour comprendre comment Site Recovery génère les points de récupération, voyons un exemple de stratégie de réplication. Cette stratégie de réplication utilise un point de récupération avec une fenêtre de rétention de 1 jour et une capture instantanée de cohérence des applications à la fréquence d’une heure.

Site Recovery crée un point de récupération cohérent en cas d’incident toutes les 5 minutes. Vous ne pouvez pas modifier cette fréquence. Pour les 2 heures les plus récentes, vous pouvez choisir parmi 24 points de cohérence en cas d’incident et 2 points de cohérence des applications. Au fil du temps, pour la période antérieure aux 2 dernières heures, Site Recovery n’enregistre qu’un seul point de récupération par heure pendant jusqu’à 24 heures par jour.

La capture d’écran suivante illustre cet exemple. Dans la capture d’écran :

• Au cours des 2 dernières heures, la fréquence des points de récupération est de 5 minutes.

• Au-delà des 2 dernières heures, Site Recovery ne conserve qu’un seul point de récupération par heure.

  

Le point de récupération le plus ancien que vous pouvez utiliser est de 15 jours avec un disque managé et de 3 jours avec un disque non managé.

Non, Site Recovery conserve tous vos points de récupération antérieurs. En fonction de la fenêtre de rétention des points de récupération, Site Recovery ne remplace le point le plus ancien que s’il génère de nouveaux points. En raison de ce problème, Site Recovery ne peut pas générer de nouveaux points de récupération. Tant qu’il n’y a pas de nouveaux points de récupération, tous les anciens points subsistent une fois la fenêtre de rétention atteinte.

Accédez à Coffre Site Recovery>Infrastructure Site Recovery>Stratégies de réplication. Sélectionnez la stratégie à modifier, modifiez-la, puis enregistrez les modifications. Toute modification s’applique également à toutes les réplications existantes.

Le premier point de récupération qui est généré possède la copie complète. Les points de récupération successifs ont des modifications d’ordre différentiel.

Si vous prolongez la période de rétention en passant de un à trois jours, Site Recovery enregistre les points de récupération pendant deux jours supplémentaires. L’augmentation de la période entraîne des frais de stockage, car 12 points de récupération supplémentaires devront être enregistrés avec une période de rétention prolongée de un à trois jours. Par exemple, un point de récupération unique peut avoir des modifications différentielles de 10 Go avec un coût par Go de 0,16 USD par mois. Les frais supplémentaires sont alors de 1,60 × 12 USD par mois.

Vous pouvez accéder aux machines virtuelles Azure via une connexion Internet sécurisée, via un VPN site à site ou via Azure ExpressRoute. Vous devez préparer un certain nombre d’éléments afin de vous connecter. Plus d’informations

Azure est conçu pour la résilience. Site Recovery est déjà prévu pour assurer le basculement vers un centre de données Azure secondaire, dans le respect du contrat SLA Azure. Dans ce cas, nous nous assurons que vos métadonnées et vos coffres restent dans la même région géographique que vous avez choisie pour votre coffre.

Vous pouvez déclencher un basculement non planifié à partir du site secondaire. Site Recovery n’a pas besoin d’être connecté au site principal pour effectuer le basculement.

Le basculement n’est pas automatique. Vous lancez les basculements d’un seul clic dans le portail, ou vous pouvez utiliser Site Recovery PowerShell pour déclencher un basculement. La restauration automatique est une action simple dans le portail Site Recovery.

Pour automatiser les processus, vous pouvez utiliser Orchestrator ou Operations Manager localement pour détecter une défaillance de machine virtuelle, puis déclencher le basculement à l’aide du kit SDK.

• Découvrez plus d’informations sur les plans de récupération.
• En savoir plus sur le basculement.
• En savoir plus sur la restauration automatique de serveurs physiques et de machines virtuelles VMware

Oui, vous pouvez utiliser la récupération à un autre emplacement pour la restauration automatique vers un hôte différent depuis Azure.

• Pour les machines virtuelles VMware
• Pour les machines virtuelles Hyper-V

Une fois qu’une machine a basculé de l’emplacement source vers l’emplacement cible, vous avez le choix entre trois options. Ces trois options ont des objectifs différents :

1. La migration complète signifie que vous n’allez plus revenir du tout à l’emplacement source. Vous avez effectué la migration vers la région cible et maintenant, c’est terminé. Cliquer sur Migration complète déclenche la validation, puis la désactivation de la réplication en interne.
2. La validation signifie que ce n’est pas la fin de votre processus de réplication. L’élément de réplication ainsi que toute la configuration sont conservés. Vous pouvez alors choisir Reprotéger ultérieurement pour réactiver la réplication de vos machines dans la région source.
3. La désactivation de la réplication permet de désactiver la réplication et de supprimer toute la configuration associée. Elle n’affecte pas la machine déjà existante dans la région cible.

Oui. Vous pouvez automatiser les flux de travail Site Recovery à l’aide de l’API REST, de PowerShell ou du kit SDK Azure. Scénarios actuellement pris en charge pour le déploiement de Site Recovery à l’aide de PowerShell :

• Répliquer des machines virtuelles Hyper-V dans des clouds VMM avec Azure PowerShell et Resource Manager
• Répliquer des machines virtuelles Hyper-V sans VMM avec Azure PowerShell et Resource Manager
• Réplication de VMware vers Azure avec le gestionnaire des ressources de PowerShell

Non, la mise hors service du module AzureRM n'affecte pas le fonctionnement des mises à jour automatiques de Site Recovery. Aucune modification n'est nécessaire pour le runbook interne, et l'API REST utilisée en parallèle continue de fonctionner comme prévu avec le compte d'automatisation.

Apprenez-en davantage sur les nouvelles mises à jour et obtenez des informations sur les correctifs cumulatifs.

Étapes suivantes

• Lisez la Vue d’ensemble de Microsoft Azure Site Recovery