Sauvegarder les groupes de disponibilité Always On de SQL Server

Sauvegarde Azure offre un support de bout en bout pour sauvegarder les groupes de disponibilité SQL Server Always On si tous les nœuds se trouvent dans la même région et dans le même abonnement que le coffre Recovery Services. Toutefois, si les nœuds AG sont répartis entre les régions/abonnements/emplacements locaux et Azure, certaines considérations doivent être prises en compte.

Pour voir les scénarios de sauvegarde et de restauration que nous prenons en charge, consultez la matrice de prise en charge. Pour les questions courantes, consultez les questions fréquemment posées.

Comportement des préférences de sauvegarde par version SQL Server

La prise en charge des sauvegardes complètes et différentielles sur les réplicas secondaires dépend de la version de SQL Server. La préférence de sauvegarde du groupe de disponibilité et la version de SQL Server déterminent le nœud choisi pour chaque type de sauvegarde.

SQL Server 2022 et versions antérieures

La préférence de sauvegarde utilisée par les groupes de disponibilité SQL de Sauvegarde Azure prend en charge les sauvegardes complètes et différentielles uniquement à partir du réplica principal. Par conséquent, ces tâches de sauvegarde s’exécutent toujours sur le nœud principal, quelle que soit la préférence de sauvegarde. Pour les sauvegardes avec copie complète uniquement et de journal des transactions, la préférence de sauvegarde AG est prise en compte lors de la détermination du nœud où la sauvegarde sera exécutée.

SQL Server 2025 et versions ultérieures

Dans SQL Server 2025 et versions ultérieures, les réplicas secondaires prennent également en charge les sauvegardes complètes et différentielles. La préférence de sauvegarde régit désormais uniformément les deux types de sauvegarde. Lorsque vous définissez secondaire uniquement ou préférez secondaire, les sauvegardes complètes et différentielles ne nécessitent plus le nœud principal.

Lorsque vous inscrivez un nœud auprès du service Sauvegarde Azure, vous installez l’extension de sauvegarde de charge de travail sur ce nœud. Lorsque vous configurez une base de données de groupe de disponibilité pour la sauvegarde, les planifications de sauvegarde sont envoyées à tous les nœuds inscrits du groupe de disponibilité. Les planifications sont activées sur tous les nœuds du groupe de disponibilité et les extensions de sauvegarde de la charge de travail sur ces nœuds se synchronisent entre eux afin de décider quel nœud peut effectuer la sauvegarde. La sélection du nœud dépend du type de sauvegarde et de la préférence de sauvegarde décrite dans le comportement des préférences de sauvegarde par SQL Server version.

Le nœud sélectionné poursuit le travail de sauvegarde, alors que le travail déclenché sur les autres nœuds est annulé, c’est-à-dire qu’il est ignoré.

Inscrire des nœuds de groupe de disponibilité dans le coffre Recovery Services

Un Recovery Services vault prend en charge la sauvegarde des bases de données uniquement depuis des machines virtuelles situées dans la même région et associées au même abonnement que le vault.

SQL Server 2022 et versions antérieures :

• Enregistrez le nœud principal auprès du coffre (sinon, les sauvegardes complètes ne peuvent pas être réalisées).
• Enregistrez au moins un nœud secondaire auprès du coffre (sinon, les sauvegardes de journaux ou les sauvegardes complètes en mode copie seule ne peuvent pas être effectuées) si la préférence de sauvegarde est secondaire uniquement.

La configuration des sauvegardes pour les bases de données AG échoue avec le code d'erreur FabricSvcBackupPreferenceCheckFailedUserError si les conditions ci-dessus ne sont pas remplies.

SQL Server 2025 et versions ultérieures :

• L’inscription du nœud primaire n’est plus obligatoire pour la configuration de la sauvegarde AG. Étant donné que les sauvegardes complètes et différentielles peuvent désormais s’exécuter sur des réplicas secondaires, vous pouvez configurer des sauvegardes avec uniquement des nœuds secondaires inscrits (lorsque la préférence de sauvegarde est secondaire uniquement ou préférez secondaire).
• Pour la préférence de sauvegarde principale , le nœud principal doit toujours être inscrit.
• Inscrivez au moins un nœud répondant à la préférence de sauvegarde choisie.

Prenons comme référence le déploiement de groupe de disponibilité suivant.

Sur la base de l’exemple de déploiement de groupe de disponibilité donné, voici diverses considérations à prendre en compte :

• Comme le nœud principal se trouve dans la région 1 et l’abonnement 1, le coffre Recovery Services (coffre 1) doit être dans la région 1 et l’abonnement 1 pour la protection de ce groupe de disponibilité.
• VM3 ne peut pas être inscrit dans le coffre 1, car il se trouve dans un autre abonnement.
• VM4 ne peut pas être inscrit dans le coffre 1, car il se trouve dans un autre abonnement.
• Si la préférence de sauvegarde est secondaire uniquement, inscrivez VM1 (principal) et VM2 (secondaire) dans le coffre 1. Sur SQL Server 2022 et versions antérieures, les sauvegardes complètes nécessitent le nœud principal afin d’inscrire les deux nœuds ; sur SQL Server 2025 et versions ultérieures, VM2 seul est suffisant. Pour d’autres préférences de sauvegarde, inscrivez VM1 (principal) dans le coffre 1 ; VM2 est facultatif.
• Bien que vous puissiez inscrire VM3 dans le coffre 2 dans l’abonnement 2 et que les bases de données du groupe de disponibilité s’affichent ensuite pour la protection dans le coffre 2, la configuration des sauvegardes échoue sur SQL Server 2022 et versions antérieures en raison de l’absence du nœud principal dans le coffre 2. Sur SQL Server 2025 et versions ultérieures, vous pouvez configurer des sauvegardes dans le coffre 2 si la préférence de sauvegarde est secondaire uniquement ou préférez secondaire.
• De même, si vous pouvez inscrire VM4 dans le coffre 4 dans la région 2, la configuration des sauvegardes échoue sur SQL Server 2022 et versions antérieures, car le nœud principal n'est pas inscrit dans le coffre 4. Sur SQL Server 2025 et versions ultérieures, vous pouvez configurer des sauvegardes dans le coffre 4 si la préférence de sauvegarde est secondaire uniquement ou préférez secondaire.

Gérer le basculement

Une fois que le groupe de disponibilité a basculé vers l’un des nœuds secondaires :

• SQL Server 2022 et versions antérieures : les sauvegardes complètes et différentielles se poursuivent depuis le nouveau nœud principal s'il est enregistré dans le coffre.
• SQL Server 2025 et versions ultérieures : les sauvegardes complètes et différentielles continuent à partir du nœud qui satisfait à la préférence de sauvegarde. Pour Secondaire uniquement ou Préférer le secondaire, ces sauvegardes peuvent être effectuées sur une réplique secondaire.
• Les sauvegardes de journaux et de copies complètes uniquement se poursuivent à partir du nœud principal/secondaire en fonction de la préférence de sauvegarde.

Sur la base de l’exemple de déploiement de groupe de disponibilité ci-dessus, voici diverses possibilités de basculement à prendre en compte :

• Basculement vers VM2
  • Les sauvegardes complètes et différentielles sont effectuées à partir de VM2.
  • Les sauvegardes de journaux et les sauvegardes complètes en copie uniquement seront effectuées à partir de VM1 ou VM2 selon la préférence de sauvegarde.
• Basculement vers VM3 (un autre abonnement)
  • Comme les sauvegardes ne sont pas configurées dans Vault 2, aucune sauvegarde ne se produira.
  • Sur SQL Server 2022 et versions antérieures, si la préférence de sauvegarde n'est pas secondaire uniquement, vous pouvez désormais configurer des sauvegardes dans Vault 2, car le nœud principal est inscrit dans ce coffre. Sur SQL Server 2025 et versions ultérieures, vous pouvez également configurer des sauvegardes lorsque le nœud inscrit dans Vault 2 satisfait à la préférence de sauvegarde sélectionnée. Cette condition peut entraîner des conflits ou des échecs de sauvegarde. Pour plus d’informations, consultez Configurer des sauvegardes pour un AG multirégion.
• Basculement vers VM4 (une autre région)
  • Comme les sauvegardes ne sont pas configurées dans le coffre 4, aucune sauvegarde ne se produit.
  • Sur SQL Server 2022 et versions antérieures, si la préférence de sauvegarde n'est pas secondaire uniquement, vous pouvez désormais configurer des sauvegardes dans Vault 4, car le nœud principal est inscrit dans ce coffre. Sur SQL Server 2025 et versions ultérieures, vous pouvez également configurer des sauvegardes lorsque le nœud inscrit dans Vault 4 satisfait à la préférence de sauvegarde sélectionnée. Cette condition peut entraîner des conflits ou des échecs de sauvegarde. Pour plus d’informations, consultez Configurer les sauvegardes pour un AG multirégion.

Configurer des sauvegardes pour un groupe de disponibilité à plusieurs régions

Le coffre Recovery Services ne prend pas en charge les sauvegardes inter-abonnement ou inter-région. Cette section résume comment activer les sauvegardes pour les AG (groupes de disponibilité) qui couvrent des abonnements ou des régions Azure, ainsi que les considérations associées.

• Évaluez si vous devez vraiment activer des sauvegardes à partir de tous les nœuds. Si une région/un abonnement comporte la plupart des nœuds de groupe de disponibilité, et si le basculement vers d’autres nœuds se produit très rarement, la configuration de la sauvegarde dans cette première région peut suffire. Si les basculements vers une autre région/un autre abonnement se produisent fréquemment et pour une durée prolongée, vous pouvez également configurer des sauvegardes de manière proactive dans l’autre région.

• Chaque coffre dans lequel la sauvegarde est activée aura son propre ensemble de chaînes de points de restauration. Les restaurations à partir de ces points de récupération peuvent être effectuées uniquement sur des machines virtuelles inscrites dans ce coffre.

• SQL Server 2022 et versions antérieures : les sauvegardes complètes et différentielles fonctionnent uniquement dans le coffre de sauvegarde qui contient le nœud principal. Ces sauvegardes dans d’autres coffres continuent d’échouer. Dans SQL Server 2025 et versions ultérieures, ce comportement change pour les préférences Secondaire uniquement et Préférer le secondaire ; voir SQL Server 2025 : modifications des sauvegardes AG multirégion.

• Les sauvegardes de journaux continueront de fonctionner dans le coffre précédent jusqu’à ce qu’une sauvegarde de journal s’exécute dans le nouveau coffre (c’est-à-dire dans le coffre où se trouve le nouveau nœud principal) et rompe la chaîne des journaux pour l’ancien coffre.

  Note

  Il y a une limite stricte de 15 jours après laquelle les sauvegardes de logs commenceront à échouer.

• Les sauvegardes complètes de copie uniquement fonctionnent dans tous les coffres.

• La protection dans chaque coffre est traitée comme une source de données distincte et est facturée séparément.

Pour éviter les conflits de sauvegarde de journal entre les deux coffres, nous vous recommandons de définir la préférence de sauvegarde sur principal. Ensuite, le coffre ayant le nœud principal effectue également les sauvegardes du journal.

SQL Server 2025 : modifications de sauvegarde de groupe de disponibilité multirégions

Avec SQL Server 2025, les sauvegardes complètes et différentielles ne nécessitent plus le nœud principal. Cette modification signifie :

• L’inscription de nœud principal n’est pas nécessaire . Si votre préférence de sauvegarde est secondaire uniquement ou préférez secondaire, vous pouvez configurer et exécuter des sauvegardes à partir de n’importe quel nœud secondaire inscrit, même si le nœud principal se trouve dans une autre région ou un autre abonnement.

• Impact réduit du basculement : après le basculement vers un nœud situé dans une autre région, les sauvegardes peuvent continuer dans le coffre d’origine tant qu’un nœud enregistré conforme à la préférence de sauvegarde est disponible.

Cependant, la limitation fondamentale de la coordination entre coffres reste la même : les sauvegardes ne peuvent pas être coordonnées entre plusieurs coffres. Si vous enregistrez des nœuds d’un groupe de disponibilité dans différents coffres situés dans plusieurs régions, les planifications de sauvegarde simultanées peuvent entrer en conflit et entraîner des ruptures dans la chaîne des journaux ou des sauvegardes en double.

Recommandation pour éviter les conflits inter-coffres :

• Groupe de disponibilité à 2 nœuds : définissez la préférence de sauvegarde sur Secondaire uniquement ou Principal.
• Groupe de disponibilité à 3 nœuds ou plus : définissez la préférence de sauvegarde sur Primaire.

Cette configuration garantit qu’un seul nœud de coffre peut être utilisé pour les sauvegardes à tout moment.

Sur la base de l’exemple de déploiement de groupe de disponibilité ci-dessus, voici les étapes à suivre pour activer la sauvegarde à partir de tous les nœuds. L’hypothèse est que la préférence de sauvegarde est satisfaite à toutes les étapes.

Étape 1 : activer les sauvegardes dans la région 1, abonnement 1 (coffre 1)

Comme le nœud principal se trouve dans la région et l’abonnement, les étapes habituelles pour activer les sauvegardes fonctionnent.

Étape 2 : activer les sauvegardes dans la région 1, abonnement 2 (coffre 2)

1. Basculez l'AG vers VM3 afin que le nœud principal se trouve dans Vault 2.
2. Configurez les sauvegardes des bases de données AG dans le coffre 2.
3. À ce stade :
   1. Les sauvegardes complètes/différentielles échouent dans Vault 1, car aucun des nœuds inscrits ne peut effectuer cette sauvegarde.
   2. Les sauvegardes de journaux réussiront dans le Coffre 1 jusqu’à ce qu’une sauvegarde de journal s’exécute dans le Coffre 2 et rompe la chaîne des journaux pour le Coffre 1.
4. Faire basculer le groupe de disponibilité vers VM1.

Étape 3 : activer les sauvegardes dans la région 2, abonnement 1 (coffre 4)

Identique à l’étape 2.

Sauvegarder un groupe de disponibilité qui s’étend sur Azure et sur site

Sauvegarde Azure pour le SQL Server ne peut pas être exécuté sur site. Si le nœud principal se trouve dans Azure et que la préférence de sauvegarde est satisfaite par les nœuds dans Azure, vous pouvez suivre les instructions ci-dessus pour le groupe de disponibilité à plusieurs régions afin d’activer des sauvegardes pour les réplicas dans Azure. Si un basculement vers un nœud local se produit, les sauvegardes complètes et différentielles dans Azure échouent. Les sauvegardes de journaux peuvent continuer jusqu’à ce que la rupture de la chaîne des journaux intervienne ou que 15 jours se soient écoulés.

Limitation des tâches de sauvegarde dans une base de données AG

Actuellement, les limitations du débit de sauvegarde s'appliquent à chaque ordinateur individuellement. La limite par défaut est fixée à 20 : si plus de 20 sauvegardes sont déclenchées simultanément, les 20 premières s’exécuteront et les autres seront mises en file d’attente. Lorsque les tâches en cours d’exécution sont terminés, celles qui sont en file d’attente commencent à s’exécuter.

Vous pouvez remplacer cette valeur par une valeur inférieure si les sauvegardes simultanées sont à l’origine de la sollicitation de la mémoire/des E/S/de l’UC sur le nœud. Dans la mesure où la limitation se fait au niveau du nœud, l’utilisation de nœuds de groupe de disponibilité déséquilibrés peut entraîner des problèmes de synchronisation de sauvegarde. Pour comprendre cela, prenons l’exemple d’un groupe de disponibilité à 2 nœuds.

Par exemple, le premier nœud compte 50 bases de données autonomes protégées, et les deux nœuds disposent de 5 bases de données de groupe de disponibilité protégées. En fait, le nœud 1 compte 55 tâches de sauvegarde de base de données planifiées, alors que le nœud 2 n’en compte que 5. En outre, toutes ces sauvegardes sont configurées pour s’exécuter en même temps, toutes les heures. À un moment, toutes les 55 sauvegardes seront déclenchées sur le nœud 1, et 35 d'entre elles seront mises en file d'attente. Parmi celles-ci figurent des sauvegardes de la base de données AG. Toutefois, sur le nœud 2, les sauvegardes de la base de données du groupe de disponibilité n’ont pas été placées en file d’attente.

Étant donné que les tâches de base de données de l’AG (groupe de disponibilité) sont mises en file d’attente sur un nœud et s’exécutent sur un autre, la synchronisation des sauvegardes ne fonctionne pas correctement. Le nœud 2 peut supposer que le nœud 1 est défaillant et, par conséquent, les tâches ne sont pas prévues pour la synchronisation. Ce problème peut entraîner des interruptions de chaîne de journal ou des sauvegardes supplémentaires, car les deux nœuds peuvent effectuer des sauvegardes indépendamment.

Un problème similaire peut se produire si le nombre de bases de données protégées du groupe de disponibilité dépasse la limitation. Dans ce cas, la sauvegarde de, par exemple, DB1 peut être mise en file d’attente sur le nœud 1 alors qu’elle s’exécute sur le nœud 2.

Nous vous recommandons d’utiliser les préférences de sauvegarde suivantes pour éviter ces problèmes de synchronisation :

• Pour un groupe de disponibilité à 2 nœuds, définissez la préférence de sauvegarde sur principal ou sur secondaire uniquement : un seul nœud pourra alors effectuer les sauvegardes, l’autre abandonnera toujours.
• Pour un groupe de disponibilité avec plus de 2 nœuds, définissez la préférence de sauvegarde sur principal. Ensuite, seul le nœud principal peut effectuer les sauvegardes, d’autres seront exclues.

Facturation pour les sauvegardes de groupe de disponibilité

Comme pour une instance SQL autonome, une instance AG sauvegardée est considérée comme une instance protégée. La taille totale de l'interface frontale de toutes les bases de données protégées dans une instance est facturée. Prenons l’exemple du déploiement suivant :

Les instances protégées sont calculées comme suit :

Déplacer une base de données protégée à l’extérieur ou à l’extérieur d’un groupe de disponibilité

Sauvegarde Azure considère le nom de l'instance SQL ou le nom du groupe de disponibilité/nom de la base de données comme le nom unique de la base de données. Lorsque la base de la version autonome était protégée, son nom unique était StandAloneInstanceName\DBName. Lorsqu’il se déplace dans un groupe de disponibilité, le nom unique devient AGName\DBName. Les sauvegardes de la base de données autonome échouent avec le code d’erreur suivant : UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

La base de données doit être configurée pour la protection à partir du groupe de disponibilité. Elle sera traitée comme une nouvelle source de données avec une chaîne de points de récupération distincte. La protection précédente de la base de données autonome peut être stoppée tout en conservant les données afin d’éviter que des sauvegardes futures ne se déclenchent et échouent. De même, lorsqu’une base de données de groupe de disponibilité protégée quitte le groupe de disponibilité et devient une base de données autonome, ses sauvegardes commencent à échouer avec le code d’erreur suivant : UserErrorBackupFailedDatabaseMovedOutOfAG.

La base de données doit être configurée pour la protection à partir de l’instance autonome. Elle sera traitée comme une nouvelle source de données avec une chaîne de points de récupération distincte. La protection existante de la base de données AG peut être arrêtée tout en conservant les données, afin d'éviter que des sauvegardes futures ne se déclenchent et échouent.

Ajout/suppression d’un nœud à/d’un groupe de disponibilité

Lorsqu’un nouveau nœud est ajouté à un groupe de disponibilité configuré pour les sauvegardes, les extensions de sauvegarde de la charge de travail qui s’exécutent sur les nœuds du groupe de disponibilité déjà enregistrés détectent la modification de la topologie du groupe de disponibilité et informent le service Sauvegarde Azure lors de la prochaine tâche de découverte de la base de données planifiée. Quand ce nouveau nœud est inscrit pour les sauvegardes dans le même coffre Recovery Services que les autres nœuds existants, le service Sauvegarde Azure déclenche un flux de travail qui configure ce nouveau nœud avec les métadonnées nécessaires à l’exécution des sauvegardes de groupe de disponibilité.

Après cette étape, le nouveau nœud synchronise les informations de planification des sauvegardes AG depuis le service Sauvegarde Azure et commence à participer au processus de sauvegarde synchronisée. Si le nouveau nœud n’est pas en mesure de synchroniser les planifications de sauvegarde et de participer aux sauvegardes, le déclenchement d’un nouvel enregistrement sur ce nœud force également la reconfiguration du nœud pour les sauvegardes du groupe de disponibilité. De même, lors du retrait du nœud, les extensions de la charge de travail détectent la modification de la topologie AG et informent le service Sauvegarde Azure. Le service démarre un flux de travail de déconfiguration du nœud sur le nœud retiré afin de supprimer les planifications de sauvegarde des bases de données AG et de supprimer les métadonnées liées à l’AG.

Annuler l’inscription d’un nœud AG d’Sauvegarde Azure

Si un nœud fait partie d’un groupe de disponibilité avec une ou plusieurs bases de données configurées pour la sauvegarde, la sauvegarde Azure n’autorise pas l’annulation de l’inscription de ce nœud. Cela permet d’éviter de futurs échecs de sauvegarde au cas où la préférence de sauvegarde ne peut pas être satisfaite sans ce nœud. Pour annuler l’inscription du nœud, vous devez d’abord le supprimer du groupe de disponibilité. Une fois le workflow d’annulation de la configuration du nœud terminé, en nettoyant ce nœud, vous pouvez annuler son inscription.

Restaurer une base de données à partir d’Sauvegarde Azure vers un groupe de disponibilité SQL. Les groupes de disponibilité SQL ne prennent pas en charge la restauration directe d’une base de données dans un groupe de disponibilité. La base de données doit être restaurée sur une instance SQL autonome, puis doit être jointe à un groupe de disponibilité.

Scénarios de recréation de groupe de disponibilité pour le serveur de base de données SQL

La recréation du groupe de disponibilité (AG), les groupes de disponibilité en doublon et les éléments de sauvegarde sont répertoriés comme éléments pouvant être protégés ou comme éléments protégés dans les scénarios suivants :

• La recréation de groupes de disponibilité (AGs) déjà protégés les fait apparaître comme des AGs en doublon sur la page Configurer la sauvegarde et dans la liste éléments protégés. Si vous voulez conserver les données de sauvegarde déjà présentes dans l’ancien groupe de disponibilité, arrêtez la sauvegarde en utilisant l’option Arrêter la protection et conserver les données avant de recréer et de planifier des sauvegardes sur les nouveaux éléments du groupe de disponibilité.

  Par conception, Sauvegarde Azure répertorie les éléments en doublon dans la Liste des éléments protégés ainsi que dans la page Configurer la sauvegarde ou dans la Liste d’éléments pouvant être protégés, et affiche ces éléments jusqu’au moment où vous voulez conserver les données de sauvegarde.

• Si vous ne voulez pas des données de sauvegarde de l’ancien groupe de disponibilité, arrêtez l’opération de sauvegarde en utilisant l’option Arrêter la protection et supprimer les données pour l’ancien élément avant de recréer et de planifier des sauvegardes sur le nouveau groupe de disponibilité.

  Attention

  L’arrêt de la protection et la suppression des données est une opération destructrice.

• Vous pouvez recréer le groupe de disponibilité après avoir exécuté l’un des processus d’arrêt de la protection ci-dessus afin d’éviter les échecs de sauvegarde.

Considérations relatives à la sauvegarde d’un groupe de disponibilité SQL Server 2025

Modifications de préférence de sauvegarde après la configuration

Si vous modifiez la préférence de sauvegarde de l’AG sans enregistrer le nœud requis dans le coffre, les sauvegardes échouent. Par exemple, si vous modifiez la préférence de Principale à Secondaire uniquement, mais qu’aucun nœud secondaire n’est enregistré, les sauvegardes du journal et les sauvegardes complètes/différentielles échouent. Veillez toujours à ce que les nœuds répondant à la nouvelle préférence de sauvegarde soient enregistrés dans le coffre avant d’effectuer cette modification.

Coordination de la sauvegarde de groupe de disponibilité multirégion

Lorsque vous protégez des nœuds AG dans plusieurs coffres situés dans différentes régions, les coffres ne peuvent pas coordonner les sauvegardes entre ces coffres, quelle que soit la version de SQL Server. Pour obtenir des conseils sur les paramètres de préférence pour les sauvegardes qui évitent les ruptures de la chaîne de journaux et les sauvegardes en double dans ce scénario, consultez SQL Server 2025 : modifications des sauvegardes de l’AG multirégion.

Prise en charge des sauvegardes par cliché

Les sauvegardes par instantané ne sont pas prises en charge sur des réplicas secondaires d’un groupe de disponibilité. Lorsque vous activez la sauvegarde d’instantanés sur la stratégie de sauvegarde, l’inscription du nœud principal reste obligatoire, quelle que soit la version SQL Server.

Étapes suivantes

Découvrez comment :

• Restaurer des bases de données SQL Server sauvegardées
• Gérer les bases de données SQL Server sauvegardées

Contenu connexe

• Sauvegardez des bases de données SQL Server dans des machines virtuelles Azure à l’aide de Sauvegarde Azure via l’API REST.
• Restaurez des bases de données SQL Server dans des machines virtuelles Azure avec l’API REST.
• Gérez les bases de données SQL Server dans des machines virtuelles Azure avec le portail Azure, Azure CLI, l’API REST.