Partager via

Restaurer une base de données vers SQL Server à partir d’Azure SQL Managed Instance

S’applique à :Azure SQL Managed Instance

Cet article explique comment restaurer une sauvegarde de base de données à partir d’Azure SQL Managed Instance vers SQL Server 2022 ou SQL Server 2025.

Vue d’ensemble

Lorsque vous configurez votre instance managée SQL avec une stratégie de mise à jour, vous alignez votre format de base de données interne avec une version spécifique de SQL Server. L’alignement du format de base de données entre SQL Managed Instance et SQL Server vous permet de copier ou de déplacer facilement des bases de données de votre instance managée SQL vers une édition Entreprise, Développeur ou Standard de SQL Server hébergée localement, sur des machines virtuelles dans Azure ou dans d’autres clouds.

La restauration de bases de données à partir d’instances managées SQL vers SQL Server 2022 ou SQL Server 2025 déverrouille les scénarios suivants :

  • Elle garantit la mobilité de base de données entre les produits SQL Managed Instance et SQL Server.
  • Elle fournit des copies de base de données aux clients et à d’autres parties éligibles.
  • Elle actualise les environnements en dehors de SQL Managed Instance.

Tenez compte des éléments suivants :

  • La possibilité de restaurer des sauvegardes complètes de copie uniquement de bases de données de SQL Managed Instance vers SQL Server 2022 est disponible par défaut pour toutes les instances existantes et nouvellement déployées. Cette capacité est disponible jusqu’à la fin de la prise en charge standard de SQL Server 2022. Une fois la stratégie de mise à jour d’une instance modifiée en SQL Server 2025 ou Always-up-to-date, la restauration d’une base de données vers SQL Server 2022 n’est plus possible.
  • La possibilité de restaurer des sauvegardes complètes de copie uniquement de bases de données de SQL Managed Instance vers SQL Server 2025 n’est disponible que pour les instances configurées avec la stratégie de mise à jour SQL Server 2025. Cette capacité est disponible jusqu’à la fin de la prise en charge standard de SQL Server 2025. Une fois que la stratégie de mise à jour d’une instance est remplacée par Always-up-to-date, la restauration d’une base de données vers SQL Server 2025 n’est plus possible.

Effectuer une sauvegarde sur SQL Managed Instance

Tout d’abord, créez des informations d’identification pour accéder au compte de stockage à partir de votre instance, effectuez une sauvegarde en copie seule de votre base de données, puis stockez-la.

Vous pouvez créer vos informations d’identification en utilisant une identité managée ou un jeton de signature d’accès partagé (SAS).

Une identité managée est une fonctionnalité de Microsoft Entra ID (anciennement Azure Active Directory) qui fournit aux instances de services Azure, comme Azure SQL Managed Instance, une identité managée automatiquement dans Microsoft Entra ID, l’identité managée affectée par le système.

Vous pouvez utiliser cette identité pour autoriser les demandes d’accès aux données dans d’autres ressources Azure, y compris des comptes de stockage. Les services comme Azure SQL Managed Instance ont une identité managée affectée par le système, et peuvent également avoir une ou plusieurs identités managées affectées par l’utilisateur. Vous pouvez utiliser aussi bien des identités managées affectées par le système que des identités managées affectées par l’utilisateur pour autoriser les demandes.

Avant que l’administrateur de stockage Azure n’écrive un fichier de sauvegarde dans un compte de stockage, il doit accorder des autorisations à l’identité managée pour qu’elle puisse écrire les données. L’octroi d’autorisations à l’identité managée de l’instance s’effectue de la même façon que pour un autre utilisateur Microsoft Entra. Par exemple :

  1. Dans le portail Azure, dans le volet Contrôle d’accès (IAM) d’un compte de stockage, sélectionnez Ajouter une attribution de rôle.

  2. Sélectionnez le rôle RBAC (contrôle d’accès en fonction du rôle) Azure intégré Contributeur aux données Blob du stockage. Il permet d’accéder en lecture/écriture à l’identité managée pour les conteneurs de stockage Blob Azure nécessaires.

    Au lieu d’attribuer à l’identité managée le rôle RBAC Azure Contributeur aux données Blob du stockage, vous pouvez donner des autorisations plus précises. Pour en savoir plus, consultez Définir des listes de contrôle d’accès dans Azure Data Lake Storage Gen2.

  3. Dans la page suivante, pour Attribuer l’accès à, sélectionnez Identité managée.

  4. Choisissez Sélectionner des membres, puis, dans la liste déroulante Identité managée, sélectionnez l’identité managée appropriée. Pour plus d’informations, consultez Attribution de rôles Azure avec le Portail Azure.

La création d’informations d’identification délimitées à la base de données pour l’authentification de l’identité managée est désormais simple.

Dans l’exemple suivant, notez que Managed Identity est une chaîne codée en dur et que vous devez remplacer le nom du compte de stockage générique par le nom du compte de stockage réel :

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
WITH IDENTITY = 'MANAGED IDENTITY';

Ensuite, effectuez une sauvegarde COPY_ONLY de votre base de données en exécutant l’exemple de commande T-SQL suivant :

BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/SampleDB.bak'
WITH COPY_ONLY;

Restaurer sur SQL Server

Restaurez la base de données sur SQL Server en utilisant l’option WITH MOVE de la commande T-SQL RESTORE DATABASE et en fournissant des chemins explicites pour vos fichiers sur le serveur de destination.

Pour restaurer votre base de données sur SQL Server, exécutez l’exemple de commande T-SQL suivant avec les chemins de fichier appropriés à votre environnement :

RESTORE DATABASE [SampleDB]
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/SampleDB.bak'
WITH
    MOVE 'data_0' TO 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\SampleDB_data_0.mdf',
    MOVE 'log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\SampleDBlog.ldf',
    MOVE 'XTP' TO 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\SampleDB_xtp.xtp';

Remarque

Pour restaurer des bases de données chiffrées au repos à l’aide du chiffrement transparent des données (TDE), l’instance de destination de SQL Server doit avoir accès à la même clé que celle utilisée pour protéger la base de données source via le connecteur SQL Server pour Azure Key Vault. Pour plus d’informations, consultez Configurer SQL Server TDE Extensible Key Management à l’aide d’Azure Key Vault.

Considérations

Quand vous restaurez une base de données vers SQL Server, tenez compte des éléments suivants :

  • Vous devez utiliser le qualificateur WITH MOVE et fournir des chemins explicites pour les fichiers de données.

  • Les bases de données chiffrées avec des clés TDE managées par le service ne peuvent pas être restaurées vers SQL Server. Vous pouvez restaurer une base de données chiffrée vers SQL Server uniquement si elle a été chiffrée avec une clé gérée par le client et si le serveur de destination a accès à la même clé que celle utilisée pour chiffrer la base de données. Pour plus d'informations, consultez Configurer la gestion des clés extensibles SQL Server TDE à l'aide d'Azure Key Vault..

  • La stratégie de mise à jour de votre instance managée SQL doit correspondre ou être une version ultérieure de votre instance SQL Server. Les bases de données restaurées sur SQL Server 2022 doivent provenir d’instances avec la stratégie de mise à jour SQL Server 2022. De même, les bases de données restaurées sur SQL Server 2025 doivent provenir d’instances avec la stratégie de mise à jour SQL Server 2025. Il est également possible de restaurer une base de données à partir d’une instance avec une stratégie de mise à jour SQL Server 2022 vers une instance avec une stratégie de mise à jour SQL Server 2025 . Une fois qu’une base de données est restaurée sur une instance avec une stratégie de mise à jour de version supérieure, cette base de données ne peut plus être restaurée sur une instance avec une stratégie de mise à jour de version inférieure. La restauration de bases de données à partir d’instances avec une stratégie de mise à jour de version inférieure n’est pas prise en charge.

  • Après avoir restauré une base de données Azure SQL Managed Instance sur SQL Server et supprimé un index ou une table avec un index, vous pouvez voir l’erreur 8992 lors de l’exécution de la DBCC CHECKDB commande.

    Avertissement

    Si vous créez un index partitionné sur une table après avoir supprimé un index comme décrit dans ce scénario, la table devient inaccessible.

Contenu connexe

  • Last updated on