Sauvegarder des fichiers et des applications sur Azure Stack Hub

Considérez une situation dans laquelle Azure Stack Hub héberge des machines virtuelles qui exécutent des charges de travail utilisateur. Il est nécessaire de sauvegarder et de restaurer les fichiers et les applications des charges de travail. Cet article de référence sur l’architecture décrit une approche qui fournit une solution optimisée pour les activités de sauvegarde et de restauration.

Architecture

Téléchargez un fichier Visio de cette architecture.

Workflow

Les composants cloud comprennent les services suivants :

• Un abonnement Azure hébergeant toutes les ressources cloud incluses dans cette solution
• Un locataire Microsoft Entra associé à l’abonnement Azure. Il fournit l’authentification des principaux de service Microsoft Entra afin d’accorder l’accès aux ressources Azure.
• Un coffre Azure Recovery Services dans la région Azure la plus proche du centre de données local qui héberge le déploiement d’Azure Stack Hub

En fonction des critères présentés dans cet article, les composants cloud peuvent également inclure les services suivants :

• Un circuit Azure ExpressRoute qui connecte le centre de données local et la région Azure qui héberge le coffre Azure Recovery Services. Le circuit est configuré de façon à disposer du peering Microsoft afin de prendre en charge des tailles de sauvegarde plus importantes

• Le service Azure Import/Export permettant d’activer les sauvegardes MABS hors connexion vers Azure

  Notes

  À compter du mois d’août 2020, la sauvegarde MABS hors connexion vers Azure à l’aide d’Azure Data Box est en préversion.

En fonction de l’utilisation du service Azure Import/Export pour la sauvegarde hors connexion du MABS sur Azure, la solution peut également avoir un compte de stockage Azure dans la même région Azure que le coffre Recovery Services.

Les composants locaux incluent les services suivants :

• Un système intégré Azure Stack Hub dans le modèle de déploiement connecté qui exécute la mise à jour actuelle (2002 en août 2020), et localisé dans le centre de données local du client

• Une machine virtuelle Windows Server 2016 ou Windows Server 2019 hébergée par le système intégré Azure Stack Hub et exécutant la mise en production (UR) 1 de MABS v3

• des machines virtuelles Azure Stack Hub avec l’agent de protection du MABS, qui gère les sauvegardes et les restaurations à partir de la machine virtuelle Azure Stack Hub du MABS ; l’agent de protection du MABS effectue le suivi des modifications apportées aux charges de travail protégées et transfère les modifications au magasin de données du MABS ; Il identifie également les données sur son ordinateur local pouvant être protégées, et joue un rôle dans le processus de récupération

• Un agent MARS (Microsoft Azure Recovery Services) installé sur le serveur qui exécute MABS. L’agent intègre MABS et le coffre Azure Recovery Services

  Notes

  L’agent MARS est également appelé agent Sauvegarde Azure.

Composants

• Azure Stack Hub
• Microsoft Entra ID
• Compte Azure Storage
• Azure ExpressRoute

Autres solutions

La solution recommandée décrite dans cet article ne constitue pas l’unique manière de fournir une fonctionnalité de sauvegarde et de restauration aux charges de travail utilisateur qui s’exécutent sur Azure Stack Hub. Les clients ont d’autres options, à savoir :

• Sauvegarde et restauration locales à l’aide de la fonctionnalité Sauvegarde Windows Server incluse dans le système d’exploitation Windows Server. Les utilisateurs peuvent ensuite copier les sauvegardes locales vers un stockage à plus long terme. Cette approche prend en charge les sauvegardes de cohérence d’applications en s’appuyant sur des fournisseurs VSS Windows, mais augmente l’utilisation de l’espace disque local et les frais de maintenance de la sauvegarde.
• Sauvegarde et restauration à l’aide du service Sauvegarde Azure avec l’agent MARS installé localement. Cette approche réduit l’utilisation de l’espace disque local et automatise le processus de chargement des sauvegardes dans le stockage cloud. En revanche, il ne prend pas en charge les sauvegardes de cohérence d’applications.
• Sauvegarde et restauration à l’aide d’une solution de sauvegarde installée dans le même centre de données, mais en dehors d’Azure Stack Hub. Cette approche facilite les scénarios qui impliquent un modèle de déploiement déconnecté d’Azure Stack Hub.
• Sauvegarde et restauration au niveau d’Azure Stack Hub à l’aide de captures instantanées de disque. Cette approche nécessite l’arrêt de la machine virtuelle sauvegardée, ce qui n’est généralement pas une option viable pour les charges de travail critiques, mais peut être acceptable dans certaines situations.

Détails du scénario

La sauvegarde et la restauration sont des composants essentiels de toute stratégie complète de continuité d’activité et reprise d’activité. La conception et l’implémentation d’une approche cohérente et fiable de la sauvegarde dans un environnement hybride sont difficiles, mais elles peuvent être considérablement simplifiées grâce à l’intégration avec les services Microsoft Azure. Cela s’applique non seulement aux charges de travail qui s’exécutent sur une infrastructure locale traditionnelle, mais aussi à celles qui sont hébergées par des fournisseurs tiers de clouds publics et privés. Toutefois, les avantages de l’intégration avec les services Azure sont évidents quand les environnements hybrides intègrent des offres du portefeuille Azure Stack, dont Azure Stack Hub.

Si l’un des principaux atouts d’Azure Stack Hub est sa prise en charge du modèle PaaS (Platform-as-a-Service), il aide également les clients à moderniser leurs charges de travail IaaS existantes. Ces charges de travail peuvent inclure des partages de fichiers, des bases de données Microsoft SQL Server, des batteries de serveurs Microsoft SharePoint et des clusters Microsoft Exchange Server. Leur migration vers des machines virtuelles qui s’exécutent sur des clusters hyper-convergés et hautement résilients, ayant des modèles d’administration et de programmation cohérents avec Microsoft Azure, entraîne une réduction de la charge de gestion et de maintenance.

Pour la mise en œuvre de la sauvegarde de fichiers et d’applications qui s’exécutent sur des machines virtuelles Azure Stack Hub, Microsoft recommande une approche hybride qui repose sur une combinaison de composants cloud et locaux, afin de fournir une solution de sauvegarde scalable, performante, fiable, sécurisée, facile à gérer et rentable. Le composant central de cette solution est le serveur de sauvegarde Microsoft Azure (MABS) v3, qui fait partie de l’offre Sauvegarde Azure. Le MABS s’appuie sur l’infrastructure Azure Stack Hub pour les ressources de calcul, de réseau et de stockage à court terme, et il utilise le stockage basé sur Azure en tant que magasin de stockage à long terme. Cette approche réduit ou élimine la nécessité de conserver des supports de sauvegarde physiques tels que des bandes.

Principales fonctionnalités

La solution proposée prend en charge les fonctionnalités suivantes sur les machines virtuelles Azure Stack Hub qui exécutent Windows Server 2019, 2016, 2012 R2, 2012, 2008 R2 SP1 (64 bits avec Windows Management Framework 4.0), 2008 SP2 (64 bits avec Windows Management Framework 4.0) et Windows 10 (64 bits) :

• sauvegarde et restauration des volumes, des partages, des dossiers, des fichiers et de l’état du système du NFTS (New Technology File System) et du ReFS (Resilient File System) ;

• Sauvegarde et restauration des instances SQL Server 2019, 2017, 2016 (avec les Service Packs (SP) requis) et 2014 (avec SP requis), ainsi que de leurs bases de données

• sauvegarde et restauration des serveurs et bases de données Exchange Server 2019 et Exchange Server 2016, y compris les serveurs et les bases de données autonomes dans un groupe de disponibilité de base de données (DAG) ;

• restauration des boîtes aux lettres individuelles et des bases de données de boîtes aux lettres dans un DAG ;

• sauvegarde et restauration SharePoint 2019 et SharePoint 2016 (avec les derniers SP), ainsi que du contenu de serveur web frontal ;

• restauration des bases de données, applications web, fichiers, éléments de liste et composants de recherche SharePoint 2019 et SharePoint 2016.

  Notes

  Pour déployer des systèmes d’exploitation clients Windows 10 sur Azure Stack Hub, vous devez disposer de licences Windows par utilisateur ou en acheter via un QMTH (Qualified Multitenant Hoster).

Le MABS implémente le schéma de sauvegarde de disque à disque à cloud (D2D2C), avec la sauvegarde principale stockée localement sur le serveur qui héberge l’installation du MABS. Les sauvegardes locales sont ensuite copiées dans un coffre Azure Site Recovery. Le disque local fonctionne comme un stockage à long terme, tandis que le coffre fournit un stockage à long terme.

Le processus de sauvegarde comprend les quatre phases suivantes :

1. Vous installez l’agent de protection du MABS sur un ordinateur que vous souhaitez protéger, puis vous l’ajoutez à un groupe de protection.
2. Vous configurez la protection de l’ordinateur ou de son application, y compris la sauvegarde sur les disques locaux du MABS pour le stockage à court terme et sur Azure pour le stockage à long terme. Dans le cadre de l’installation, vous spécifiez la planification de la sauvegarde pour les deux types de sauvegardes.
3. La charge de travail protégée sauvegarde les disques locaux du MABS en fonction de la planification que vous avez spécifiée.
4. La sauvegarde locale stockée sur les disques du MABS est sauvegardée dans le coffre Azure Recovery Services par l’agent MARS qui s’exécute sur le serveur MABS.

Prérequis

L’implémentation de la solution recommandée est subordonnée à la satisfaction des prérequis suivants :

• Accès à un abonnement Azure disposant d’autorisations suffisantes pour provisionner un coffre Azure Recovery Services dans la région Azure la plus proche d’un centre de données local qui héberge le déploiement d’Azure Stack Hub

• Un domaine AD DS (Active Directory Domain Services) accessible à partir d’une machine virtuelle Azure Stack Hub qui hébergera une instance du MABS

• Une machine virtuelle hébergée par Azure Stack Hub, qui exécutera une instance du MABS, satisfaisant ainsi les prérequis énoncées dans Installer le serveur de sauvegarde Azure sur Azure Stack, et disposant d’une connectivité sortante aux URL listées dans Prise en charge du réseau pour DPM/MABS.

  Notes

  Des considérations supplémentaires relatives à l’espace disque et aux performances pour MABS sont décrites plus en détail plus loin dans cet article.

  Notes

  Pour vérifier si la machine virtuelle qui héberge le MABS dispose d’une connectivité au service Sauvegarde Azure, vous pouvez utiliser l’applet de commande DPMCloudConnection (incluse dans le module PowerShell du serveur de sauvegarde Azure).

  Notes

  Le MABS requiert également une instance locale de SQL Server. Pour plus d’informations sur la configuration requise de SQL Server, consultez Installer et mettre à niveau le serveur de sauvegarde Azure.

Types de données

Du point de vue du MABS, il existe deux types de données à prendre en compte :

• Les données de fichier sont des données qui résident généralement sur des serveurs de fichiers (par exemple des fichiers Microsoft Office, des fichiers texte ou des fichiers multimédias) et qui doivent être protégées en tant que fichiers plats.
• Les données d’application sont des données qui existent sur des serveurs d’applications (tels que des groupes de stockage Exchange, des bases de données SQL Server ou des batteries de serveurs SharePoint) et qui nécessitent que le MABS soit informé de la configuration requise pour l’application correspondante.

Types de sauvegarde

Que vous protégiez des données de fichier ou des données d’application, la protection commence par la création d’un réplica de la source de données dans le stockage local d’une instance de MABS. Le réplica est synchronisé ou mis à jour à intervalles réguliers conformément aux paramètres que vous configurez. La méthode qu’utilise le MABS pour synchroniser les réplicas dépend du type des données protégées. Si un réplica est identifié comme incohérent, le MABS effectue un contrôle de cohérence qui consiste en une vérification bloc par bloc du réplica par rapport à la source de données.

Pour un volume ou un partage de fichiers sur un serveur, après la sauvegarde complète initiale, l’agent de protection du MABS utilise un filtre de volume et un journal des modifications pour identifier les fichiers modifiés. Il effectue ensuite une procédure de somme de contrôle pour ces fichiers afin de synchroniser uniquement les blocs modifiés. Pendant la synchronisation, ces modifications sont transférées vers le MABS, puis appliquées au réplica, ce qui a pour effet de synchroniser le réplica avec la source de données.

Si un réplica devient incohérent avec sa source de données, le MABS génère une alerte qui spécifie quel ordinateur et quelles sources de données sont affectés. Pour résoudre le problème, vous pouvez réparer le réplica en lançant une synchronisation avec vérification de cohérence sur le réplica. Lors d’un contrôle de cohérence, le MABS effectue une vérification bloc par bloc et répare le réplica pour qu’il soit de nouveau cohérent avec la source de données. Vous pouvez planifier une vérification de cohérence quotidienne pour les groupes de protection ou lancer manuellement une vérification de cohérence.

À intervalles réguliers que vous pouvez configurer, le MABS crée un point de récupération pour la source de données protégée. Un point de récupération est une version des données qui peut être récupérée.

Pour les données d’application, une fois le réplica créé par le MABS, les modifications apportées aux blocs de volume qui appartiennent aux fichiers d’application sont suivies par le filtre de volume. La façon dont les modifications sont transférées vers le serveur MABS dépend de l’application et du type de synchronisation. L’opération appelée synchronisation dans la console Administrateur du MABS est analogue à une sauvegarde incrémentielle qui crée une réflexion précise et transactionnellement cohérente des données d’application lors de la combinaison de celles-ci avec le réplica.

Lors du type de synchronisation appelée sauvegarde complète rapide dans la console Administrateur du MABS, une capture instantanée complète du service VSS (Volume Shadow Copy) est créée, mais seuls les blocs modifiés sont transférés vers le serveur MABS.

Chaque sauvegarde complète rapide crée un point de récupération pour les données d'application. Si l'application prend en charge les sauvegardes incrémentielles, chaque synchronisation crée également un point de récupération. Le processus de synchronisation dépend de l’application :

• Pour les données Exchange, la synchronisation transfère une capture instantanée VSS incrémentielle à l’aide de l’enregistreur VSS d’Exchange. Des points de récupération sont créés pour chaque synchronisation et pour chaque sauvegarde complète rapide.
• Les bases de données SQL Server qui sont envoyées par des journaux, en mode lecture seule, ou qui utilisent le modèle de récupération simple ne prennent pas en charge la sauvegarde incrémentielle. Des points de récupération sont créés pour chaque sauvegarde complète rapide uniquement. Pour toutes les autres bases de données SQL Server, la synchronisation transfère une sauvegarde de fichier journal, avec des points de récupération créés pour chaque synchronisation incrémentielle et sauvegarde complète rapide. Le journal des transactions est un enregistrement séquentiel de toutes les transactions qui ont été effectuées sur la base de données depuis la dernière sauvegarde du journal des transactions.
• Les serveurs SharePoint ne prennent pas en charge la sauvegarde incrémentielle. Des points de récupération sont créés pour chaque sauvegarde complète rapide uniquement.

Les synchronisations incrémentielles demandent moins de temps que l’exécution d’une sauvegarde complète rapide. Toutefois, le temps nécessaire pour récupérer les données augmente à mesure que le nombre de synchronisations augmente. Cela s’explique par le fait que le MABS doit restaurer la dernière sauvegarde complète, puis restaurer et appliquer toutes les synchronisations incrémentielles jusqu’au point dans le temps spécifié pour la récupération.

Pour permettre des récupérations plus rapides, le MABS effectue régulièrement une sauvegarde complète rapide qui met à jour le réplica pour inclure les blocs modifiés. Au cours de la sauvegarde complète rapide, le MABS prend une capture instantanée du réplica avant de le mettre à jour avec les blocs modifiés. Pour activer des objectifs de point de récupération plus fréquents, et pour réduire la fenêtre de perte de données, le MABS effectue également des synchronisations incrémentielles durant la période entre deux sauvegardes complètes rapides.

Comme pour la protection des données de fichier, si un réplica devient incohérent avec sa source de données, le MABS génère une alerte qui spécifie le serveur et les sources de données affectés. Pour résoudre l’incohérence, vous pouvez réparer le réplica en lançant une synchronisation avec vérification de cohérence sur le réplica. Lors d’un contrôle de cohérence, le MABS effectue une vérification bloc par bloc du réplica et répare celui-ci pour qu’il soit de nouveau cohérent avec les sources de données. Vous pouvez planifier une vérification de cohérence quotidienne pour les groupes de protection ou lancer manuellement une vérification de cohérence.

Stratégies de protection

Un ordinateur ou sa charge de travail est protégé lorsque vous installez le logiciel de l’agent de protection de MABS sur l’ordinateur, et que vous ajoutez les données de l’ordinateur ou sa charge de travail à un groupe de protection. Des groupes de protection sont utilisés pour configurer et gérer la protection des sources de données sur les ordinateurs. Un groupe de protection est un ensemble de sources de données qui partagent la même configuration de protection. La configuration de protection est l’ensemble des paramètres qui sont communs à un groupe de protection, tels que le nom du groupe de protection, la stratégie de protection, les allocations de stockage et la méthode de création de réplicas.

Un MABS stocke un réplica distinct pour chaque membre du groupe de protection dans le pool de stockage. Un membre du groupe de protection peut contenir des sources de données telles que les suivantes :

• un volume, un partage ou un dossier sur un serveur de fichiers ou un cluster de serveurs ;
• un groupe de stockage d’un serveur Exchange ou d’un cluster de serveurs ;
• une base de données d’une instance de SQL Server ou d’un cluster de serveurs.

Pour chaque groupe de protection, vous configurez une stratégie de protection basée sur les objectifs de récupération associés à ce groupe de protection. Les objectifs de récupération représentent les exigences de protection des données correspondant aux RTO et RPO de votre organisation. Au sein d’un MABS, ils sont définis en fonction d’une combinaison des paramètres suivants :

• Durée de rétention à court terme. Ce paramètre détermine la durée pendant laquelle vous souhaitez conserver les données sauvegardées sur le stockage local du MABS.

• Fréquences de synchronisation et de point de récupération. Ce paramètre correspond directement à la tolérance à la perte de données qui, à son tour, reflète les RPO de votre organisation. Il détermine également la fréquence à laquelle le MABS doit synchroniser ses réplicas locaux avec des sources de données protégées en collectant les modifications apportées à leurs données. Vous pouvez définir la fréquence de synchronisation en choisissant n’importe quel intervalle compris entre 15 minutes et 24 heures. Vous pouvez également choisir d’effectuer la synchronisation juste avant la création d’un point de récupération plutôt qu’à une heure planifiée.

• Planification des points de récupération à court terme. Ce paramètre établit le nombre de points de récupération à créer dans le stockage local pour le groupe de protection. Pour la protection des fichiers, vous devez sélectionner les jours et les heures auxquels les points de récupération doivent être créés. Pour la protection des données d'applications qui prennent en charge les sauvegardes incrémentielles, la fréquence de synchronisation détermine la planification du point de récupération.

• Planification de sauvegarde complète rapide. Il s’agit de la planification du point de récupération pour la protection des données des applications qui ne prennent pas en charge les sauvegardes incrémentielles mais uniquement les sauvegardes complètes rapides.

• Planification de sauvegarde en ligne. Ce paramètre détermine la fréquence de création d’une copie des sauvegardes locales dans le coffre Azure Recovery Services associé à l’instance locale du MABS. Vous pouvez planifier la sauvegarde sur une base quotidienne, hebdomadaire, mensuelle ou annuelle, avec une fréquence maximale autorisée de deux sauvegardes par jour. Le MABS crée automatiquement un point de récupération pour les sauvegardes en ligne à l’aide du réplica local le plus récent, sans transférer les nouvelles données à partir de la source de données protégée.

  Notes

  Un coffre Recovery Services prend en charge jusqu’à 9 999 points de récupération.

• Stratégie de rétention en ligne. Ce paramètre spécifie la période pendant laquelle les sauvegardes quotidiennes, hebdomadaires, mensuelles et annuelles sont conservées dans le coffre Azure Site Recovery associé à l’instance locale du MBAS.

  Notes

  Pour protéger le contenu le plus récent de la source de données en ligne, créez un point de récupération sur le disque local avant de créer un point de récupération en ligne.

  Notes

  Par défaut, le coffre Azure Recovery Services Vault est géoredondant, ce qui signifie que toute sauvegarde copiée dans son stockage est automatiquement répliquée dans une région Azure faisant partie d’une paire de régions prédéfinie. Vous pouvez paramétrer une réplication localement redondante si cela suffit à vos besoins de résilience et si vous devez réduire les coûts de stockage. Toutefois, vous devez envisager de conserver le paramètre par défaut. Cette option ne peut pas être modifiée si le coffre contient des éléments protégés.

  Notes

  Pour obtenir la liste des paires de régions Azure, consultez Continuité d’activité et reprise d’activité (BCDR) : régions jumelées d’Azure.

Test des restaurations

En plus d’une stratégie de sauvegarde conçue et implémentée de manière optimale, il est important de définir, de documenter et de tester le processus de restauration pour chaque type de charge de travail protégée. Bien que le MABS fournisse des contrôles de cohérence intégrés qui vérifient automatiquement l’intégrité des sauvegardes de données, les tests des restaurations doivent faire partie des procédures d’exploitation de routine. Les tests valident une restauration en examinant l’état des charges de travail restaurées. Les résultats des tests doivent être accessibles aux propriétaires de charge de travail.

En général, les tests des restaurations s’avèrent difficiles, car ils nécessitent un environnement qui ressemble étroitement à celui hébergeant les charges de travail protégées. Azure Stack Hub, avec ses fonctionnalités intégrées de DevOps et d’infrastructure en tant que code (IaC), simplifie grandement la résolution de cette difficulté.

Rôles et responsabilités

La planification et l’implémentation de la sauvegarde et de la restauration des charges de travail basées sur Azure Stack Hub impliquent généralement une interaction entre de nombreuses parties prenantes :

• Opérateurs Azure Stack Hub. Des opérateurs Azure Stack Hub gèrent l’infrastructure Azure Stack Hub, garantissant une disponibilité suffisante des ressources de calcul, de stockage et de réseau nécessaires pour l’implémentation d’une solution de sauvegarde et de restauration complète, ainsi que pour la mise à disposition de ces ressources pour les locataires. Ils collaborent également avec les propriétaires d’applications et de données pour les aider à déterminer l’approche optimale pour déployer leurs charges de travail sur Azure Stack Hub.
• Administrateurs Azure. Les administrateurs Azure gèrent les ressources Azure nécessaires à l’implémentation des solutions de sauvegarde hybrides.
• Administrateurs Microsoft Entra. Des administrateurs Microsoft Entra gèrent les ressources Microsoft Entra, y compris les objets utilisateur et groupe utilisés pour approvisionner, configurer et gérer les ressources Azure.
• Équipe informatique du locataire Azure Stack Hub. Ces parties prenantes conçoivent, implémentent et gèrent le MABS, y compris les sauvegardes et restaurations MABS.
• Utilisateurs d’Azure Stack Hub. Ces utilisateurs fournissent des exigences de RPO et de RTO, et soumettent des demandes de sauvegarde et de restauration de données et d’applications.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Azure Stack Hub permet d’augmenter la disponibilité des charges de travail grâce à une résilience inhérente à son infrastructure. Vous pouvez accroître davantage la disponibilité en concevant et en implémentant des solutions qui augmentent l’étendue de la protection des charges de travail. Il s’agit de la valeur ajoutée qu’apporte le MABS. Dans le contexte du MABS qui s’exécute sur Azure Stack Hub, deux aspects de la disponibilité doivent être explorés de façon plus approfondie :

• La disponibilité de MABS et de ses magasins de données
• La disponibilité de la fonctionnalité de restauration à un instant dans le passé des charges de travail protégées par le MABS

Vous devez en tenir compte lors du développement d’une stratégie de sauvegarde axée sur des objectifs de point de récupération (RPO) et des objectifs de temps de récupération (RTO). Les RTO et RPO constituent des exigences de continuité stipulées par des fonctions métier au sein d’une organisation. Le RPO désigne une durée qui représente la perte de données maximale acceptable due à un incident qui rend les données indisponibles pendant un certain temps. Le RTO désigne la durée maximale acceptable que peut prendre le rétablissement de l’accès aux fonctions métier à la suite d’un incident ayant rendu les fonctions indisponibles.

La disponibilité du MABS et de ses magasins de données est subordonnée à la disponibilité de la machine virtuelle qui héberge l’installation du MABS et son stockage tant local que basé sur le cloud. Les machines virtuelles Azure Stack Hub sont hautement disponibles par conception. En cas de défaillance d’un MABS, vous avez la possibilité de restaurer des éléments protégés par le service Sauvegarde Azure à partir de toute autre machine virtuelle Azure Stack Hub qui héberge un MABS. Notez cependant que, pour qu’un serveur qui héberge MABS récupère des sauvegardes effectuées à l’aide de MABS exécuté sur un autre serveur, les deux serveurs doivent être inscrits auprès du même coffre Azure Site Recovery.

La fonction de restauration à un instant dans le passé des charges de travail protégées par un MABS dépend en grande partie du type de données, des sauvegardes et des stratégies de protection. Pour comprendre ces dépendances, il est nécessaire d’explorer ces concepts de façon plus approfondie.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

La gestion des données et applications d’utilisateur dans des scénarios hybrides justifie des considérations supplémentaires en matière de sécurité. Ces considérations peuvent être regroupées dans les catégories suivantes :

• Chiffrement de sauvegarde
• Protection du coffre Azure Recovery Services

MABS et le service Sauvegarde Azure appliquent un chiffrement des sauvegardes au repos et en transit :

• Chiffrement au repos. Pendant l’installation de MABS, l’utilisateur fournit une phrase secrète. Cette phrase secrète est ensuite utilisée pour chiffrer toutes les sauvegardes avant leur chargement dans un coffre Azure Recovery Services. Le déchiffrement a lieu uniquement après que les sauvegardes ont été téléchargées à partir de ce coffre. La phrase secrète n’est accessible qu’à l’utilisateur qui l’a créée et à l’agent MARS installé localement. Il est essentiel de s’assurer que la phrase secrète est stockée dans un emplacement sécurisé, car elle sert de mécanisme d’autorisation lors de l’exécution de restaurations basées sur le cloud sur un serveur MABS autre que celui où les sauvegardes ont eu lieu.
• Chiffrement en transit. Le MABS v3 s’appuie sur le protocole TLS (Transport Layer Security) version 1.2 pour protéger ses connexions à Azure.

Le coffre Azure Recovery Services Vault offre des mécanismes qui protègent davantage les sauvegardes en ligne, à savoir :

• Contrôle d’accès en fonction du rôle Azure (RBAC Azure). RBAC Azure permet la délégation et la répartition des responsabilités selon le principe du privilège minimum. Il existe trois rôles intégrés liés au service Sauvegarde Azure, qui restreignent l’accès aux opérations de gestion des sauvegardes :
  • Contributeur de sauvegarde. Donne accès à la création et à la gestion des sauvegardes, à l’exception de la suppression du coffre Recovery Services et de la délégation de l’accès à d’autres utilisateurs.
  • Opérateur de sauvegarde. Fournit un accès équivalent à celui du Contributeur de sauvegarde, à l’exception de la suppression des sauvegardes et de la gestion des stratégies de sauvegarde.
  • Lecteur de sauvegarde. Fournit un accès pour surveiller les opérations de gestion des sauvegardes.
• Verrous de ressource Azure. Vous pouvez créer et attribuer des verrous de lecture seule et de suppression à un coffre Azure Site Recovery afin de réduire le risque que le coffre soit modifié ou supprimé par inadvertance ou par malveillance.
• Suppression réversible. La suppression réversible permet de protéger le coffre et les données de sauvegarde contre des suppressions accidentelles ou malveillantes. Avec la suppression réversible, si un utilisateur supprime un élément de sauvegarde, les données correspondantes sont conservées pendant 14 jours, ce qui permet une récupération sans perte de données pendant cette période. La conservation des données de sauvegarde pendant 14 jours dans l’état de suppression réversible n’occasionne pas de frais. La suppression réversible est activée par défaut.
• Protection des opérations affectant la sécurité. Le coffre Azure Recovery Services implémente automatiquement une autre couche d’authentification à chaque tentative d’opération affectant la sécurité, telle que la modification d’une phrase secrète. Cette validation supplémentaire permet de s’assurer que seuls des utilisateurs autorisés effectuent ces opérations.
• Surveillance et alertes d’activité suspecte. Le service Sauvegarde Azure fournit un monitoring et des alertes intégrées concernant les événements affectant la sécurité liés aux opérations du service Sauvegarde Azure. Les rapports de sauvegarde facilitent le suivi de l’utilisation, l’audit des sauvegardes et des restaurations ainsi que l’identification des tendances clés en matière de sauvegarde.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Lorsque vous envisagez le coût de la solution de sauvegarde décrite dans cet article, n’oubliez pas de prendre en compte les composants locaux et basés sur le cloud. La tarification des composants locaux est déterminée par le modèle de tarification d’Azure Stack Hub. Comme avec Azure, Azure Stack Hub propose une offre assortie d’un paiement à l’utilisation, disponible par le biais de contrats entreprise et du programme de fournisseurs de solutions cloud. Cette configuration inclut un tarif mensuel par machine virtuelle Windows Server. Si vous pouvez utiliser des licences Windows Server existantes, vous pouvez réduire considérablement ce coût jusqu’à la tarification des machines virtuelles de base. MABS s’appuie sur SQL Server comme magasin de données, mais aucun coût de licence n’est associé à l’exécution de cette instance de SQL Server si elle est utilisée exclusivement pour MABS.

Des frais liés à Azure sont encourus pour l’utilisation des ressources suivantes :

• Sauvegarde Azure. Les tarifs du service Sauvegarde Azure dépendent en grande partie du nombre de charges de travail protégées et de la taille des sauvegardes de données (avant compression et chiffrement) pour chacune d’elles. Le coût est également affecté par le choix entre le stockage localement redondant (LRS) et le stockage géoredondant (GRS) pour la réplication du contenu du coffre Azure Recovery Services. Pour plus d’informations, consultez Tarifs Sauvegarde Azure.
• Azure ExpressRoute. La tarification d’Azure ExpressRoute est basée sur l’un des deux modèles suivants :
  • Données illimitées. Il s’agit d’une redevance mensuelle incluant tous les transferts de données entrants et sortants.
  • Données limitées. Il s’agit d’une redevance mensuelle incluant tous les transferts de données entrants gratuits, les transferts de données sortants étant facturés par Go.
• Azure Import/Export. Le coût d’Azure Import/Export comprend des frais fixes pour la gestion des périphériques (par périphérique).
• Stockage Azure. Lorsque vous utilisez Azure Import/Export, les tarifs et frais de transaction standard du service Stockage Azure s’appliquent.

Sans ExpressRoute, il se peut que vous deviez prendre en compte l’utilisation accrue de la bande passante de vos connexions Internet pour les sauvegardes et les restaurations. Le coût varie en fonction de nombreux facteurs, dont la zone géographique, l’utilisation actuelle de la bande passante et le fournisseur de services Internet.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

Simplicité de gestion

Parmi les principaux facteurs qui affectent votre stratégie de sauvegarde et de restauration figurent la configuration des groupes de protection ainsi que les critères que vous utilisez pour décider quelles charges de travail protégées doivent appartenir aux mêmes groupes protégés. Comme décrit plus haut dans cet article, un groupe de protection est une collection de sources de données, telles que des volumes, des partages ou des magasins de données d’application, qui ont des paramètres de sauvegarde et de restauration communs. Lorsque vous définissez un groupe de protection, vous devez spécifier les éléments suivants :

• Sources de données, telles que les serveurs et charges de travail à protéger
• stockage de sauvegarde, dont les paramètres de protection à court terme et à long terme ;
• points de récupération, à savoir les points dans le temps à partir desquels les données sauvegardées peuvent être récupérées ;
• Espace disque alloué, à savoir la quantité d’espace disque du pool de stockage allouée aux sauvegardes
• Réplication initiale, qui est la méthode utilisée pour la sauvegarde initiale des sources de données. La méthode peut être un transfert en ligne (sur un réseau) ou un transfert hors connexion (par exemple via le service Azure Import/Export)
• Méthode de vérification de cohérence, qui est la méthode de vérification de l’intégrité des sauvegardes de données

Les méthodes suivantes sont souvent utilisées pour décider quelles charges de travail protégées doivent appartenir aux mêmes groupes protégés :

• Par ordinateur. Cette méthode combine toutes les sources de données pour un ordinateur dans le même groupe de protection
• Par charge de travail. Cette méthode sépare les fichiers et chaque type de données d’application en différents groupes de protection Toutefois, la récupération d’un serveur hébergeant plusieurs charges de travail peut nécessiter plusieurs restaurations à partir de différents groupes de protection.
• Par RPO et RTO. Cette méthode regroupe les sources de données avec des RPO similaires. Vous contrôlez le RPO en définissant la fréquence de synchronisation pour le groupe de protection, qui détermine la quantité de perte de données potentielle (mesurée dans le temps) en cas d’interruptions inattendues. Dans le scénario décrit dans cet article, vous contrôlez le RTO en définissant la période de rétention au sein du stockage à court terme. Cela détermine la période pendant laquelle les sauvegardes peuvent être restaurées à partir du stockage à court terme local, plutôt qu’à partir du stockage à long terme basé sur le cloud. La sauvegarde à partir du stockage à court terme local entraîne une restauration plus rapide.
• Par caractéristiques des données. Cette méthode tient compte de la fréquence des changements de données, du taux de croissance des données ou des exigences de stockage en tant que critères pour les regroupements.

Lorsque vous nommez des groupes de protection, utilisez des noms uniques et explicites. Un nom peut être n’importe quelle combinaison de caractères alphanumériques et d’espaces, d’une longueur maximale de 64 caractères.

Lorsque vous créez un groupe de protection, vous choisissez une méthode pour la création du réplica initial. La réplication initiale copie toutes les données sélectionnées pour la protection sur le serveur qui héberge MABS, puis les copie dans le coffre Azure Site Recovery La cohérence des deux copies est vérifiée. MABS peut créer des réplicas automatiquement par le biais du réseau, mais vous pouvez créer des réplicas manuellement en sauvegardant, en transférant et en restaurant les données hors connexion.

Pour plus d’informations sur le choix de la méthode de création de réplica, consultez Réplication initiale sur le réseau. L’article contient une table qui fournit des estimations du temps nécessaire à MABS pour créer automatiquement un réplica sur le réseau pour différentes tailles de données protégées et vitesses réseau.

Le processus d’amorçage hors connexion prend en charge l’utilisation du service Azure Import/Export, qui peut transférer des données vers un compte Stockage Azure à l’aide de disques SATA. Cette fonctionnalité peut être utilisée lorsque la sauvegarde en ligne est trop lente en raison de la quantité de données de sauvegarde ou de la vitesse de la connexion réseau à Azure.

Le workflow d’amorçage hors connexion comporte les étapes suivantes :

1. Vous copiez les données de sauvegarde initiales sur un ou plusieurs disques SATA à l’aide de l’outil AzureOfflineBackupDiskPrep.
2. L’outil génère automatiquement un travail d’importation Azure et une application Microsoft Entra dans l’abonnement qui héberge le compte Stockage Azure cible et le coffre Azure Recovery Services. L’application fournit au service Sauvegarde Azure un accès sécurisé et délimité au service d’importation Azure, comme exigé par le processus d’amorçage hors connexion.
3. Vous expédiez les disques au centre de données Azure qui héberge le compte Stockage Azure cible.
4. Le personnel du centre de données Azure copie les données des disques vers le compte Stockage Azure.
5. Le flux de travail déclenche une copie à partir du compte de stockage Azure vers le coffre Azure Recovery Services.

DevOps

Bien que la sauvegarde et la restauration soient considérées comme faisant partie des opérations informatiques, certaines considérations propres à DevOps méritent d’être incorporées dans une stratégie de sauvegarde complète. Azure Stack Hub facilite le déploiement automatisé de diverses charges de travail, y compris d’applications et services basés sur des machines virtuelles. Vous pouvez utiliser cette fonctionnalité pour rationaliser le déploiement du MABS sur des machines virtuelles Azure Stack Hub, ce qui simplifie la configuration initiale dans des scénarios multilocataires. En combinant des modèles Azure Resource Manager, des extensions de machine virtuelle et le module PowerShell DPM, il est possible d’automatiser la configuration du MABS, notamment la configuration de ses groupes de protection, paramètres de rétention et planifications de sauvegarde. Dans l’esprit des bonnes pratiques de DevOps, vous devez stocker des modèles et des scripts dans un contrôle de code source, et configurer leur déploiement au moyen des pipelines. Ces pratiques aident à réduire le temps de récupération dans les cas où l’infrastructure nécessaire à la restauration des données de fichiers et d’applications doit être recréée.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Lorsque vous prévoyez de déployer MABS sur Azure Stack Hub, vous devez tenir compte de la quantité de ressources de traitement, de stockage et de réseau allouées aux machines virtuelles qui hébergent le déploiement. Microsoft recommande d’allouer un processeur quadruple cœur cadencé à 2,33 gigahertz (GHz) pour satisfaire les besoins de traitement du MABS, et environ 10 Go d’espace disque pour les fichiers binaires d’installation. Les autres exigences de stockage peuvent être classées comme suit :

• Espace disque pour les sauvegardes. La recommandation générale pour l’espace disque de sauvegarde consiste à allouer un espace disque de pool de stockage équivalent à environ 1,5 fois la taille de toutes les données à sauvegarder. Une fois les disques attachés à la machine virtuelle, le MABS gère le volume et l’espace disque. Le nombre de disques que vous pouvez attacher à une machine virtuelle dépend de sa taille.

  Notes

  Vous ne devez pas stocker les sauvegardes localement pendant plus de cinq jours. Les sauvegardes datant de plus de cinq jours doivent être déchargées vers le coffre Azure Site Recovery.

• Espace disque pour l’emplacement du cache de l’agent MARS. Utilisez le lecteur C de la machine virtuelle qui héberge l’installation du MABS.

• Espace disque pour la zone de transit local pendant les restaurations. Utilisez le lecteur temporaire D de la machine virtuelle qui héberge l’installation du MABS.

Pour provisionner du stockage pour la machine virtuelle qui héberge l’installation du MABS, utilisez des disques managés avec le niveau de performance Premium. Les caractéristiques de performances attendues sont 2 300 opérations d’E/S par seconde (IOPS) et 145 Mo/s par disque. Contrairement à Azure, il n’existe aucune garantie de performances pour Azure Stack Hub.

Pour une estimation plus précise du stockage requis pour prendre en charge les sauvegardes de charges de travail basées sur Azure Stack Hub, utilisez la calculatrice de taille de machine virtuelle Azure Stack pour MABS, disponible dans Téléchargements Microsoft. La calculatrice est implémentée sous la forme d’un classeur Microsoft Excel avec des macros qui dérivent des informations de dimensionnement Azure Stack Hub optimales en fonction d’un certain nombre de paramètres que vous fournissez. Ces paramètres sont les suivants :

• Détails relatifs à la source incluant la liste des machines virtuelles à protéger avec, pour chacune d’elles :
  • La taille des données protégées
  • type de charge de travail (Windows Server, SharePoint ou SQL Server).
• Durée de conservation des données, exprimée en jours.

Chaque type de charge de travail est associé par défaut à un taux journalier prédéfini de modifications (ou taux de change). Vous pouvez ajuster ces valeurs si elles ne reflètent pas les modèles d’usage dans votre environnement.

La calculatrice de taille de machine virtuelle Azure Stack pour MABS utilise les informations que vous spécifiez pour fournir les informations suivantes :

• Taille estimée de la machine virtuelle Azure Stack Hub qui héberge l’installation de MABS
• Quantité estimée d’espace disque MABS nécessaire pour héberger les données sauvegardées
• nombre total de disques de 1 téraoctet (To) ;
• Taux d’IOPS disponible pour l’utilisation par MABS
• Durée estimée de la sauvegarde initiale. L’estimation est basée sur la taille totale des données protégées et sur les IOPS disponibles pour l’utilisation par MABS
• Durée estimée des sauvegardes quotidiennes. L’estimation est basée sur la taille totale des changements quotidiens et sur les IOPS disponibles pour l’utilisation par MABS

Si vous créez un groupe de protection à l’aide de l’interface graphique MABS, chaque fois que vous ajoutez une source de données à un groupe de protection, MABS calcule l’allocation de l’espace disque local en fonction des objectifs de récupération à court terme que vous spécifiez. Vous pouvez ensuite décider de la quantité d’espace à allouer dans le pool de stockage pour les réplicas et les points de récupération pour chaque source de données du groupe. Vous devez veiller à ce qu’il y ait suffisamment d’espace sur les disques locaux des serveurs protégés pour le journal des modifications. Le MABS fournit des allocations d’espace par défaut pour les membres du groupe de protection. Pour plus d’informations sur les allocations d’espace par défaut pour les différents composants MABS, consultez la documentation Déployer des groupes de protection.

Utilisez les allocations d’espace par défaut, sauf si vous savez qu’elles ne répondent pas à vos besoins. Si vous remplacez les allocations par défaut, vous risquez d'allouer un espace trop important ou un espace insuffisant. L’allocation de trop peu d’espace pour les points de récupération peut empêcher le MABS de stocker suffisamment de points de récupération pour répondre à vos objectifs de durée de rétention. L'allocation de trop d'espace gaspille la capacité du disque. Après avoir créé un groupe de protection, si vous avez alloué trop peu d’espace pour une source de données, vous pouvez augmenter les allocations pour le réplica et les volumes de point de récupération pour chaque source de données. Si vous avez alloué trop d’espace pour le groupe de protection, vous pouvez supprimer la source de données du groupe de protection, ainsi que le réplica. Ajoutez ensuite la source de données au groupe de protection avec des allocations plus petites.

Après le déploiement, si vous devez ajuster le dimensionnement estimé des machines virtuelles Azure Stack Hub qui hébergent MABS afin de prendre en charge les changements de besoins en matière de traitement ou de stockage, vous avez le choix entre trois options :

• Implémenter une mise à l’échelle verticale. Cela implique de modifier la quantité et du type de ressources de processeur, de mémoire et de disque des machines virtuelles Azure Stack Hub qui hébergent MABS.
• Implémenter une mise à l’échelle horizontale. Cela implique le provisionnement ou déprovisionnement des machines virtuelles Azure Stack Hub où MABS est installé, afin de répondre aux demandes de traitement des charges de travail protégées.
• Modifier les stratégies de protection. Cela implique de modifier les paramètres des stratégies de protection, notamment la durée de rétention, la planification des points de récupération et la planification de la sauvegarde complète rapide.

Si vous choisissez d’augmenter automatiquement les volumes, le MABS rend compte de l’augmentation du volume de sauvegarde à mesure que les données de production augmentent. Dans le cas contraire, le MABS limite le stockage de sauvegarde à la taille des sources de données dans le groupe de protection.

Il existe deux options principales pour ajuster la bande passante disponible :

• Augmentez la taille de la machine virtuelle. Pour les machines virtuelles Azure Stack Hub, la taille détermine la bande passante réseau maximale. Toutefois, il n’existe aucune garantie en terme de bande passante. Au lieu de cela, les machines virtuelles peuvent utiliser la quantité de bande passante disponible jusqu’à la limite déterminée par leur taille
• Augmentation du débit des commutateurs de liaison montante. Les systèmes Azure Stack Hub prennent en charge un vaste éventail de commutateurs matériels, offrant plusieurs options de vitesse de liaison montante. Chaque nœud de cluster Azure Stack Hub a deux liaisons montantes vers les commutateurs TOR pour la tolérance de panne. Le système alloue la moitié de la capacité de liaison montante à l’infrastructure critique, le reste étant une capacité partagée pour les services Azure Stack et tout le trafic utilisateur. Les systèmes déployés avec des vitesses plus rapides ont davantage de bande passante disponible pour le trafic de sauvegarde

Bien qu’il soit possible de séparer le trafic réseau en attachant une deuxième carte réseau à un serveur, tout le trafic des machines virtuelles Azure Stack Hub vers Internet partage la même liaison montante. Une deuxième carte réseau virtuelle ne sépare pas le trafic au niveau du transport physique.

Pour prendre en charge les tailles de sauvegarde plus importantes, vous pouvez utiliser Azure ExpressRoute avec le peering Microsoft pour établir des connexions entre les réseaux virtuels Azure Stack Hub et le coffre Azure Recovery Services. Azure ExpressRoute étend les réseaux locaux au cloud Microsoft via une connexion privée fournie par un fournisseur de connectivité. Vous pouvez acheter des circuits ExpressRoute pour un large éventail de bandes passantes, qui vont de 50 Mbits/s à 10 Gbits/s.

Résumé

Azure Stack Hub est une offre unique qui diffère par de nombreux aspects des autres plateformes de virtualisation. En tant que tel, il justifie une prise en considération spéciale des stratégies de continuité d’activité pour les charges de travail qui s’exécutent sur ses machines virtuelles. Le recours aux services Azure simplifie la stratégie de conception et d’implémentation. Dans cet article, nous avons exploré l’utilisation de MABS pour la sauvegarde des données de fichiers et d’applications sur des machines virtuelles Azure Stack Hub dans le modèle de déploiement connecté. Cette approche permet aux clients de bénéficier de la résilience et de la facilité de gestion d’Azure Stack Hub, ainsi que de l’hyperscale et de la présence globale du cloud Azure.

La solution de sauvegarde décrite ici porte exclusivement sur les données de fichiers et d’applications sur des machines virtuelles Azure Stack Hub. Il s’agit simplement d’une partie d’une stratégie de continuité d’activité globale qui doit tenir compte d’autres scénarios affectant la disponibilité des charges de travail. Il peut s’agir par exemple de défaillances matérielles et logicielles localisées, de pannes de système, d’événements catastrophiques et de sinistres à grande échelle.

Étapes suivantes

• Guides pratiques : Sauvegarder des comptes de stockage sur Azure Stack
• Guides pratiques : Sauvegarder des machines virtuelles sur Azure Stack Hub à l’aide de Commvault
• Sauvegarder des charges de travail cloud et locales vers le cloud
• Installer un serveur de sauvegarde Azure
• Sauvegarder des fichiers et des applications sur Azure Stack
• Sauvegarder une batterie de serveurs SharePoint dans Azure Stack
• Sauvegarder un serveur SQL dans Azure Stack

Ressources associées

Conseils associés sur l’architecture hybride :

• Conception d’une architecture hybride
• Options hybrides Azure
• Considérations sur la conception d’applications hybrides
• Déployer une application hybride avec des données locales qui effectue une mise à l’échelle multicloud

Architectures connexes :

• Récupération d’urgence pour les machines virtuelles Azure Stack Hub
• Sauvegarder des applications et données locales dans le cloud