Partager via

Sauvegarde SQL Server vers l’URL du Stockage Blob Azure

s’applique à :SQL ServerAzure SQL Managed Instance

Cet article présente les concepts, exigences et composants nécessaires pour utiliser stockage Blob Azure comme destination de sauvegarde. La fonctionnalité de sauvegarde et de restauration est identique ou similaire à l’utilisation DISK ou TAPE, avec quelques différences. Ces différences et quelques exemples de code sont inclus dans cet article.

Tip

À compter de SQL Server 2025 (17.x), vous pouvez sauvegarder sur une URL avec une identité gérée. Veuillez consulter la section Sauvegarde vers une URL avec une identité managée (préversion) - SQL Server activé par Azure Arc.

Overview

SQL Server 2012 Service Pack 1 CU2 et SQL Server 2014 ont introduit la possibilité d’effectuer une sauvegarde vers une URL pointant vers Azure Blob Storage, en utilisant une syntaxe T-SQL familière pour écrire des sauvegardes de manière sécurisée vers le stockage Azure. SQL Server 2016 (13.x) a introduit des sauvegardesFile-Snapshot pour les fichiers de base de données dans Azure et la sécurité via des clés de signature d’accès partagé (SAP), un moyen sécurisé et simple d’authentifier des certificats auprès de la stratégie de sécurité stockage Azure.

Il est important de comprendre les composants et l’interaction entre eux pour effectuer une sauvegarde ou une restauration à partir du Stockage Blob Azure.

La création d’un compte de stockage Azure dans votre abonnement Azure est la première étape de ce processus. Ce compte de stockage est un compte d’administrateur disposant des autorisations administratives complètes sur tous les conteneurs et objets créés avec le compte de stockage. SQL Server peut utiliser le nom du compte de stockage Azure et sa valeur de clé d’accès pour authentifier et écrire et lire des objets blob dans Stockage Blob Azure, ou utiliser un jeton de signature d’accès partagé généré sur des conteneurs spécifiques lui accordant des droits de lecture et d’écriture. Pour plus d’informations sur les comptes Azure Storage, voir À propos des comptes de stockage Azure et, pour plus d’informations sur les signatures d’accès partagé, voir Signatures d’accès partagé, partie 1 : présentation du modèle SAP. Les informations d’identification SQL Server stockent ces informations d’authentification et les utilisent durant les opérations de sauvegarde ou de restauration.

Stockage Azure et stockage compatible S3

SQL Server 2022 (16.x) introduit la possibilité d’écrire des sauvegardes vers un stockage d’objets compatible S3, avec une fonctionnalité de sauvegarde et de restauration conceptuellement similaire à la sauvegarde vers une URL utilisant Azure Blob Storage comme type de périphérique de sauvegarde. SQL Server 2022 (16.x) étend la syntaxe en ajoutant la BACKUP/RESTORE TO/FROM URL prise en charge d’un nouveau connecteur S3 à l’aide de l’API REST.

Cet article contient des informations sur l’utilisation de la sauvegarde sur URL pour le Stockage Blob Azure. Pour en savoir plus sur l’utilisation de la sauvegarde vers l’URL pour le stockage compatible S3, consultez la sauvegarde SQL Server vers l’URL pour le stockage d’objets compatible avec S3.

Sauvegarde sur un objet blob de pages ou un objet blob de blocs Stockage Azure

Il existe deux types d’objets blob qui peuvent être enregistrés dans le Stockage Blob Azure : les objets blob de blocs et les objets blob de pages. Pour la version 2016 et les versions ultérieures de SQL Server, l’objet blob de blocs est préféré.

Si la clé de stockage est utilisée dans l’identifiant d’authentification, le segment page blob est utilisé ; si la signature d’accès partagé est utilisée, le segment block blob est utilisé.

La sauvegarde sur un objet blob de blocs est uniquement disponible dans SQL Server 2016 ou version ultérieure pour une sauvegarde sur le Stockage Blob Azure. Effectuez la sauvegarde vers un block blob plutôt qu’un page blob si vous utilisez SQL Server 2016 ou une version ultérieure.

Les principales raisons sont les suivantes :

  • La signature d’accès partagé est un moyen plus sûr que la clé de stockage pour autoriser l’accès aux objets blob.
  • Vous pouvez sauvegarder sur plusieurs objets blobs de blocs pour obtenir un meilleur niveau de performance de sauvegarde et de restauration et prendre en charge une sauvegarde de base de données plus volumineuse.
  • L’objet blob de blocs est moins cher que l’objet blob de pages.
  • Les clients qui doivent effectuer une sauvegarde vers des objets blob de pages via un serveur proxy doivent utiliser backuptourl.exe.

La sauvegarde d’une grande base de données vers Azure Blob Storage est soumise aux limitations répertoriées dans Différences, limitations et problèmes connus de T-SQL pour Azure SQL Managed Instance.

Si la base de données est trop grande, vous pouvez :

  • Utiliser la compression de la sauvegarde ou
  • Sauvegarde vers plusieurs block blobs

Prise en charge sous Linux, dans des conteneurs, et dans SQL Managed Instance activé par Azure Arc

Si l’instance SQL Server est hébergée sur Linux, notamment :

  • Système d’exploitation autonome
  • Containers
  • SQL Managed Instance activé par Azure Arc
  • Tout autre environnement Linux

La seule sauvegarde sur URL prise en charge pour le Stockage Blob Azure est celle qui s’effectue dans des objets blob de blocs, à l’aide de la Signature d’accès partagé.

Stockage de Blobs Azure

Compte de stockage : Le compte de stockage est le point de départ de tous les services de stockage. Pour accéder au Stockage Blob Azure, commencez par créer un compte de stockage Azure. Pour plus d’informations, voir Créez un compte de stockage.

Conteneur: Un conteneur fournit un regroupement d’un ensemble d’objets blob et peut stocker un nombre illimité d’objets blob. Pour écrire une sauvegarde SQL Server sur le Stockage Blob Azure, au moins un conteneur racine doit être créé. Vous pouvez générer un jeton de signature d’accès partagé sur un conteneur, et accorder l’accès aux objets uniquement sur un conteneur spécifique.

BLOB: Fichier de n’importe quel type et taille. Il existe deux types d’objets blob qui peuvent être enregistrés dans le Stockage Blob Azure : les objets blob de blocs et les objets blob de pages. La sauvegarde SQL Server peut utiliser l’un ou l’autre type de blob, en fonction de la syntaxe Transact-SQL utilisée. Les blobs sont accessibles à l’aide du format d’URL suivant : https://<compte de stockage>.blob.core.windows.net/<conteneur>/<blob>. Pour plus d’informations sur le Stockage Blob Azure, consultez Présentation du Stockage Blob Azure. Pour plus d’informations sur les objets blob de pages et de blocs, voir Présentation des objets blob de blocs, des objets blob d’ajout et des objets blob de pages.

Diagramme des comptes de stockage Azure Blob, des conteneurs et des objets blob.

Instantané Azure : Capture instantanée d’un objet blob Azure pris à un moment donné. Pour plus d’informations, consultez Création d’un instantané d’objet blob. La sauvegarde SQL Server prend désormais en charge les sauvegardes de captures instantanées Azure de fichiers de base de données stockés dans le Stockage Blob Azure. Pour plus d’informations, consultez Sauvegarde d’instantanés de fichiers pour les fichiers de base de données dans Azure.

Composants SQL Server

URL: Une URL spécifie un URI (Uniform Resource Identifier) dans un fichier de sauvegarde unique. L’URL fournit l’emplacement et le nom du fichier de sauvegarde SQL Server. L’URL doit pointer vers un objet blob réel et pas un simple conteneur. Si l’objet blob n’existe pas, il est créé. Si un objet blob existant est spécifié, BACKUP échoue, sauf si l’option WITH FORMAT est spécifiée pour remplacer le fichier de sauvegarde existant dans l’objet blob.

Voici un exemple de valeur d’URL : https://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak.

Note

La sauvegarde vers l’URL à l’aide de HTTP n’est pas prise en charge.

Credential: Les informations d’identification SQL Server sont un objet utilisé pour stocker les informations d’authentification requises pour se connecter à une ressource en dehors de SQL Server. Ici, les processus de sauvegarde et de restauration SQL Server utilisent des informations d’identification pour s’authentifier auprès du Stockage Blob Azure, de son conteneur et de ses objets blob. Les informations d’identification stockent le nom du compte de stockage et les valeurs de clé d’accès du compte de stockage, ou l’URL du conteneur et son jeton de signature d’accès partagé. Une fois les informations d’identification créées, la syntaxe des BACKUP/RESTORE instructions détermine le type d’objet blob et les informations d’identification requises.

Pour savoir comment créer une signature d’accès partagé, consultez les exemples Création d’une signature d’accès partagé plus loin dans cet article. Pour savoir comment créer des informations d’identification SQL Server, consultez les exemples Création d’informations d’identification plus loin dans cet article.

Pour plus d’informations sur les informations d’identification, consultez Informations d’identification (moteur de base de données).

Pour des informations sur d’autres exemples d’utilisation des informations d’identification, voir Créer un proxy de SQL Server Agent.

Prise en charge du stockage immuable Azure

SQL Server 2025 (17.x) introduit la prise en charge du stockage immuable Azure, qui protège contre les attaques par ransomware. Les fichiers écrits dans un stockage immuable ne peuvent pas être modifiés ou supprimés, comme défini par l’immuabilité.

En règle générale, les sauvegardes SQL Server sont créées en deux étapes. Initialement, le .bak fichier de sauvegarde est créé avec des zéros, puis le fichier est mis à jour avec des données. Étant donné que la modification du fichier sur le stockage immuable n’est pas autorisée une fois le fichier écrit et validé, le processus de sauvegarde ignore maintenant l’étape initiale pour créer le fichier de sauvegarde avec des zéros. Au lieu de cela, la sauvegarde entière est créée en une seule étape lors de l’écriture dans des blobs de blocs.

Pour utiliser un stockage immuable avec la sauvegarde SQL Server 2025 (17.x) vers l’URL, procédez comme suit :

  1. Configurez l’immuabilité pour votre conteneur de stockage Azure.

  2. Exécutez la commande BACKUP pour sauvegarder votre base de données dans le conteneur de stockage Azure. Si vous utilisez l’option sur le WITH FORMAT stockage immuable et qu’une sauvegarde existe déjà avec le même nom, vous obtenez une erreur et la sauvegarde échoue.

    BACKUP DATABASE [<Database>] TO URL = '<url>';

Sécurité pour le Stockage Blob Azure

Vous trouverez ci-dessous les considérations de sécurité et la configuration requise pour la sauvegarde vers ou la restauration depuis le Stockage Blob Azure.

  • Lors de la création d’un conteneur pour stockage Blob Azure, nous vous recommandons de définir l’accès privé. La définition d’un accès privé limite l’accès aux seuls utilisateurs ou comptes capables de fournir les informations nécessaires pour s’authentifier auprès du compte Azure.

    Important

    SQL Server nécessite qu’un nom de compte Azure et une authentification par clé d’accès, soit une signature d’accès partagé et un jeton d’accès, soient stockés dans des informations d’identification SQL Server. Ces informations sont utilisées pour l’authentification auprès du compte Azure lors de l’exécution d’opérations de sauvegarde ou de restauration.

    Warning

    Stockage Azure prend en charge la désactivation de l’autorisation de clé partagée pour un compte de stockage. Si l’autorisation de clé partagée est désactivée, la sauvegarde SQL Server vers l’URL ne fonctionnera pas.

  • Le compte d’utilisateur utilisé pour émettre BACKUP ou RESTORE commandes doit se trouver dans le rôle de base de données d’opérateur db_backup avec modifier les autorisations d’informations d’identification .

Limitations de la sauvegarde et de la restauration sur le Stockage Blob Azure

  • SQL Server limite la taille de sauvegarde maximale prise en charge en utilisant un objet blob de pages à 1 To. La taille maximale de sauvegarde prise en charge à l’aide d’objets blob de blocs est limitée à environ 200 Go (50 000 blocs * 4 Mo MAXTRANSFERSIZE). Les block blobs prennent en charge le striping pour permettre des tailles de sauvegarde nettement plus importantes. La limite maximale est de 64 URL, ce qui donne la formule suivante : 64 stripes * 50,000 blocks * 4MB maxtransfersize = 12.8 TB.

    Important

    Bien que la taille maximale de sauvegarde prise en charge par un seul block blob soit de 200 Go, SQL Server peut écrire dans des tailles de bloc plus petites, ce qui peut conduire SQL Server à atteindre la limite de 50 000 blocs avant que l’intégralité de la sauvegarde ne soit transférée. Divisez les sauvegardes en plusieurs fichiers (même si elles sont inférieures à 200 Go) pour éviter la limite du nombre de blocs, en particulier si vous utilisez des sauvegardes différentielles ou non compressées.

  • Vous pouvez émettre des instructions de sauvegarde ou de restauration à l’aide de Transact-SQL, SMO, d’applets de commande PowerShell ou de l’Assistant Sauvegarde ou restauration de SQL Server Management Studio.

  • Lors de la sauvegarde sur un compte de stockage Azure, SQL Server prend uniquement en charge l’authentification avec des jetons de signature d’accès partagé (SAP) ou des clés de compte de stockage. Toutes les autres méthodes d’authentification, y compris l’authentification avec Microsoft Entra ID (anciennement Azure Active Directory), ne sont pas prises en charge.

  • La création d’un nom de périphérique logique n’est pas prise en charge. L’ajout d’une URL comme périphérique de sauvegarde à l’aide de sp_dumpdevice ou via SQL Server Management Studio n’est donc pas pris en charge.

  • L’ajout à des blobs de sauvegarde existants n’est pas pris en charge. Des sauvegardes vers un objet blob existant peuvent être remplacées uniquement à l’aide de l’option WITH FORMAT. Cependant, lorsque vous utilisez les sauvegardes avec instantané de fichier (à l’aide de l’argument WITH FILE_SNAPSHOT), l’argument WITH FORMAT n’est pas autorisé afin d’éviter de laisser des instantanés de fichiers orphelins créés avec la sauvegarde d’instantané d’origine.

  • La sauvegarde vers plusieurs objets blob en une seule opération est prise en charge uniquement en utilisant un jeton de signature d’accès partagé (SAP) au lieu de la clé du compte de stockage pour les informations d’identification SQL.

  • La spécification BLOCKSIZE n’est pas prise en charge pour les blocs de pages.

  • La spécification de MAXTRANSFERSIZE n'est pas prise en charge pour les blobs de pages.

  • Spécification des options d’ensemble de sauvegarde : RETAINDAYS et EXPIREDATE ne sont pas prises en charge.

  • SQL Server est soumis à une limite de 259 caractères pour le nom d'une unité de sauvegarde. L’objet BACKUP TO URL consomme 36 caractères pour les éléments requis utilisés pour spécifier l’URL https://.blob.core.windows.net//.bak, en laissant 223 caractères pour les noms de compte, de conteneur et d’objets blob regroupés.

  • SQL Server 2019 (15.x) et les versions antérieures ont une limite de 256 caractères pour les jetons SAS (Shared Access Signature), ce qui limite le type de jetons qui peuvent être utilisés (par exemple, les jetons de clé de délégation d’utilisateur ne sont pas pris en charge).

  • Si votre serveur accède à Azure via un serveur proxy, vous devez utiliser l’indicateur de trace 1819, puis définir la configuration du proxy WinHTTP via l’une des méthodes suivantes :

    • Utilitaire proxycfg.exe sur Windows XP ou Windows Server 2003 et versions antérieures.
    • Utilitaire netsh.exe sur Windows Vista et Windows Server 2008 ou version ultérieure.

  • Le stockage immuable pour Stockage Blob Azure n’est pas pris en charge. Définissez la stratégie de stockage immuable sur false.

  • La sauvegarde vers l’URL n’est pas prise en charge dans le stockage Premium.

Arguments et instructions pris en charge dans Azure Blob Storage

Prise en charge des instructions de sauvegarde/restauration dans le Stockage Blob Azure

Backup/Restore, instruction Supported Exceptions Comments
BACKUP Yes BLOCKSIZE et MAXTRANSFERSIZE sont pris en charge pour les objets blob de blocs. Ils ne sont pas pris en charge pour les page blobs. BACKUP pour un objet blob de blocs, une signature d’accès partagé est enregistrée dans des informations d’identification SQL Server. BACKUP pour l’objet blob de pages nécessite que la clé de compte de stockage enregistrée dans des informations d’identification SQL Server soit enregistrée et que l’argument WITH CREDENTIAL soit spécifié.
RESTORE Yes Nécessite la définition d’informations d’identification SQL Server et l’argument WITH CREDENTIAL doit être spécifié si les informations d’identification SQL Server sont définies à l’aide de la clé de compte de stockage comme secret
RESTORE FILELISTONLY Yes Nécessite la définition d’informations d’identification SQL Server et l’argument WITH CREDENTIAL doit être spécifié si les informations d’identification SQL Server sont définies à l’aide de la clé de compte de stockage comme secret
RESTORE HEADERONLY Yes Nécessite la définition d’informations d’identification SQL Server et l’argument WITH CREDENTIAL doit être spécifié si les informations d’identification SQL Server sont définies à l’aide de la clé de compte de stockage comme secret
RESTORE LABELONLY Yes Nécessite la définition d’informations d’identification SQL Server et l’argument WITH CREDENTIAL doit être spécifié si les informations d’identification SQL Server sont définies à l’aide de la clé de compte de stockage comme secret
RESTORE VERIFYONLY Yes Nécessite la définition d’informations d’identification SQL Server et l’argument WITH CREDENTIAL doit être spécifié si les informations d’identification SQL Server sont définies à l’aide de la clé de compte de stockage comme secret
RESTORE REWINDONLY No

Pour plus d’informations sur la syntaxe et les informations générales sur les instructions de sauvegarde, consultez BACKUP.

Pour plus d’informations sur la syntaxe et les informations générales sur les instructions de restauration, consultez Instructions RESTORE.

Prise en charge des arguments de sauvegarde dans le Stockage Blob Azure

Argument Supported Exception Comments
DATABASE Yes
LOG Yes
TO (URL) Yes Contrairement DISK à et TAPE, l’URL ne prend pas en charge la spécification ou la création d’un nom logique. Cet argument est utilisé pour spécifier le chemin d'accès de l'URL du fichier de sauvegarde.
MIRROR TO Yes
WITH Options:
CREDENTIAL Yes WITH CREDENTIAL est uniquement pris en charge lors de l’utilisation BACKUP TO URL de l’option de sauvegarde dans stockage Blob Azure et uniquement si les informations d’identification SQL Server sont définies à l’aide de la clé de compte de stockage comme secret
FILE_SNAPSHOT Yes
ENCRYPTION Yes Lorsque l’argument WITH ENCRYPTION est spécifié, SQL Server File-Snapshot Backup garantit que l’intégralité de la base de données a été chiffrée par TDE avant d’effectuer la sauvegarde et, le cas échéant, chiffre le fichier de sauvegarde d’instantané de fichier lui-même à l’aide de l’algorithme spécifié pour TDE sur la base de données. Si toutes les données de la base de données dans la base de données entière ne sont pas chiffrées, la sauvegarde échoue (par exemple, le processus de chiffrement n’est pas encore terminé).
DIFFERENTIAL Yes
COPY_ONLY Yes
COMPRESSION|NO_COMPRESSION Yes Non prise en charge pour une sauvegarde de capture instantanée de fichier.
DESCRIPTION Yes
NAME Yes
EXPIREDATE | RETAINDAYS No
NOINIT | INIT No L’ajout à des blobs n’est pas possible. Pour remplacer une sauvegarde, utilisez l’argument WITH FORMAT . Toutefois, lors de l’utilisation de sauvegardes d’instantanés de fichiers (à l’aide de l’argument WITH FILE_SNAPSHOT ), l’argument WITH FORMAT n’est pas autorisé à éviter de quitter les instantanés de fichiers orphelins créés avec la sauvegarde d’origine.
NOSKIP | SKIP No
NOFORMAT | FORMAT Yes Une sauvegarde vers un blob existant échoue, sauf si WITH FORMAT est spécifié. L'objet blob existant est remplacé lorsque WITH FORMAT est spécifié. Cependant, lorsque vous utilisez les sauvegardes avec instantané de fichier (à l’aide de l’argument WITH FILE_SNAPSHOT), l’argument FORMAT n’est pas autorisé afin d’éviter de laisser des instantanés de fichiers orphelins créés avec la sauvegarde d’instantané d’origine. Toutefois, lors de l’utilisation de sauvegardes d’instantanés de fichiers (à l’aide de l’argument WITH FILE_SNAPSHOT ), l’argument WITH FORMAT n’est pas autorisé à éviter de quitter les instantanés de fichiers orphelins créés avec la sauvegarde d’origine.
MEDIADESCRIPTION Yes
MEDIANAME Yes
BLOCKSIZE Yes Non pris en charge pour l’objet blob de pages. Prise en charge pour l’objet blob de blocs. Recommande d’optimiser BLOCKSIZE=65536 l’utilisation des 50 000 blocs autorisés dans un objet blob de blocs.
BUFFERCOUNT Yes
MAXTRANSFERSIZE Yes Non pris en charge pour l’objet blob de pages. Prise en charge pour l’objet blob de blocs. La valeur par défaut est 1048576. La valeur peut atteindre 4 Mo par incréments de 65 536 octets.

Recommande d’optimiser MAXTRANSFERSIZE=4194304 l’utilisation des 50 000 blocs autorisés dans un objet blob de blocs.
NO_CHECKSUM | CHECKSUM Yes
STOP_ON_ERROR | CONTINUE_AFTER_ERROR Yes
STATS Yes
REWIND | NOREWIND No
UNLOAD | NOUNLOAD No
NORECOVERY | STANDBY Yes
NO_TRUNCATE Yes

Pour plus d’informations sur les arguments de sauvegarde, consultez BACKUP.

Prise en charge des arguments de restauration dans le Stockage Blob Azure

Argument Supported Exceptions Comments
DATABASE Yes
LOG Yes
FROM (URL) Yes L’argument FROM URL est utilisé pour spécifier le chemin d’URL du fichier de sauvegarde.
WITH Options:
CREDENTIAL Yes WITH CREDENTIAL est uniquement pris en charge lors de l’utilisation RESTORE FROM URL de l’option de restauration à partir du Stockage Blob Azure.
PARTIAL Yes
RECOVERY | NORECOVERY | STANDBY Yes
LOADHISTORY Yes
MOVE Yes
REPLACE Yes
RESTART Yes
RESTRICTED_USER Yes
FILE No
PASSWORD Yes
MEDIANAME Yes
MEDIAPASSWORD Yes
BLOCKSIZE Yes
BUFFERCOUNT No
MAXTRANSFERSIZE No
CHECKSUM | NO_CHECKSUM Yes
STOP_ON_ERROR | CONTINUE_AFTER_ERROR Yes
FILESTREAM Yes Non prise en charge pour la sauvegarde de capture instantanée.
STATS Yes
REWIND | NOREWIND No
UNLOAD | NOUNLOAD No
KEEP_REPLICATION Yes
KEEP_CDC Yes
ENABLE_BROKER | ERROR_BROKER_CONVERSATIONS | NEW_BROKER Yes
STOPAT | STOPATMARK | STOPBEFOREMARK Yes

Pour plus d’informations sur les arguments RESTORE, veuillez consulter la section Instructions RESTORE - Arguments.

Sauvegarder avec SSMS

Vous pouvez sauvegarder une base de données vers une URL par le biais de la tâche de sauvegarde dans SQL Server Management Studio à l’aide des informations d’identification SQL Server.

Note

Pour créer une sauvegarde de capture instantanée de fichiers SQL Server ou remplacer un support multimédia existant, vous devez utiliser Transact-SQL, PowerShell ou C# plutôt que la tâche de sauvegarde dans SQL Server Management Studio.

Les étapes suivantes décrivent les modifications apportées à la tâche Sauvegarder la base de données dans SQL Server Management Studio pour autoriser la sauvegarde vers le stockage Azure :

  1. Dans l’ Explorateur d’objets, connectez-vous à une instance du moteur de base de données SQL Server et développez-la.

  2. Développez Bases de données, cliquez avec le bouton droit sur la base de données souhaitée, pointez sur Tâches, puis sélectionnez Sauvegarder....

  3. Dans la page Général de la section Destination, l’option URL est disponible dans la liste déroulante Sauvegarder jusqu’à : L’option d’URL est utilisée pour créer une sauvegarde dans le stockage Azure. Sélectionnez Ajouter, puis la boîte de dialogue Sélectionner la destination de sauvegarde s’ouvre :

    1. Conteneur de stockage Azure : Nom du conteneur de stockage Azure pour stocker les fichiers de sauvegarde. Sélectionnez un conteneur existant dans la liste déroulante ou entrez manuellement le conteneur.

    2. Stratégie d’accès partagé : Entrez la signature d’accès partagé pour un conteneur entré manuellement. Ce champ n’est pas disponible si un conteneur existant a été choisi.

    3. Fichier de sauvegarde : Nom du fichier de sauvegarde.

    4. Nouveau conteneur : Utilisé pour inscrire un conteneur existant pour lequel vous n’avez pas de signature d’accès partagé. Veuillez consulter la section Connexion à un abonnement Microsoft Azure (Backup TO URL).

Note

Ajouter prend en charge plusieurs fichiers de sauvegarde et conteneurs de stockage pour un seul jeu de supports.

Lorsque vous sélectionnez l’URL comme destination, certaines options de la page Options multimédias sont désactivées. Les articles suivants contiennent d’autres informations sur la boîte de dialogue Sauvegarder la base de données :

Sauvegarder avec un plan de maintenance

Comme pour la tâche de sauvegarde décrite précédemment, l’Assistant Plan de maintenance dans SQL Server Management Studio inclut l’URL comme l’une des options de destination et d’autres objets de prise en charge nécessaires à la sauvegarde dans le stockage Azure, comme les informations d’identification SQL. Pour plus d’informations, voir la section Définir les tâches de sauvegarde dans Using Maintenance Plan Wizard.

Note

Pour créer un jeu de sauvegarde distribué, une sauvegarde de capture instantanée de fichier SQL Server ou des informations d’identification SQL utilisant un jeton d’accès partagé, vous devez utiliser Transact-SQL, PowerShell ou C# plutôt que la tâche Sauvegarder dans l’Assistant Plan de Maintenance.

Restauration avec SSMS

La tâche Restaurer la base de données inclut l’URL d’un appareil à partir duquel effectuer la restauration. Les étapes suivantes décrivent l’utilisation de la tâche Restaurer pour une restauration à partir du Stockage Blob Azure :

  1. Cliquez avec le bouton droit sur Bases de données et sélectionnez Restaurer la base de données....

  2. Dans la page Général , sélectionnez Appareil sous la section Source .

  3. Sélectionnez le bouton Parcourir (...) pour ouvrir la boîte de dialogue Sélectionner les unités de sauvegarde.

  4. Sélectionnez l’URL dans la liste déroulante Type de média de sauvegarde : Sélectionnez Ajouter pour ouvrir la boîte de dialogue Sélectionner un emplacement de fichier de sauvegarde .

    1. Conteneur de stockage Azure : Nom complet du conteneur de stockage Azure qui contient les fichiers de sauvegarde. Sélectionnez un conteneur existant dans la liste déroulante ou entrez manuellement le nom complet du conteneur.

    2. Signature d’accès partagé : Utilisé pour entrer la signature d’accès partagé pour le conteneur désigné.

    3. Ajouter: Utilisé pour inscrire un conteneur existant pour lequel vous n’avez pas de signature d’accès partagé. Veuillez consulter la section Connexion à un abonnement Microsoft Azure (Backup TO URL).

    4. D’ACCORD: SQL Server se connecte au stockage Azure à l’aide des informations d’identification SQL que vous avez fournies et ouvre la boîte de dialogue Localiser le fichier de sauvegarde dans Microsoft Azure . Les fichiers de sauvegarde résidant dans le conteneur de stockage s’affichent dans cette page. Sélectionnez le fichier que vous souhaitez utiliser pour restaurer et sélectionnez OK. Vous revenez à la boîte de dialogue Sélectionner les appareils de sauvegarde , puis en sélectionnant OK dans cette boîte de dialogue, vous revenez à la boîte de dialogue de restauration principale, où vous pouvez effectuer la restauration.

Exemples de code

Cette section contient les exemples suivants :

Note

Pour obtenir un didacticiel sur l’utilisation de SQL Server 2016 avec Stockage Blob Azure, consultez Tutoriel : Utiliser Stockage Blob Azure avec SQL Server

Créer une signature d’accès partagé

L’exemple suivant crée des signatures d’accès partagé utilisables pour créer des informations d’identification SQL Server sur un conteneur nouvellement créé. Le script crée une signature d’accès partagé associée à une stratégie d’accès stockée. Pour plus d’informations, voir Signatures d’accès partagé, partie 1 : présentation du modèle SAP. Le script écrit également la commande T-SQL requise pour créer les informations d’identification sur SQL Server.

Note

L’exemple nécessite Azure PowerShell. Pour plus d’informations sur l’installation et l’utilisation d’Azure PowerShell, consultez Comment installer et configurer Azure PowerShell. Ces scripts ont été vérifiés à l’aide d’Azure PowerShell 5.1.15063.

Signature d’accès partagé associée à une stratégie d’accès stockée

# Define global variables for the script
$prefixName = '<a prefix name>'  # used as the prefix for the name for various objects
$subscriptionName = '<your subscription name>'   # the name of subscription name you will use
$locationName = '<a data center location>'  # the data center region you will use
$storageAccountName = $prefixName + 'storage' # the storage account name you will create or use
$containerName = $prefixName + 'container'  # the storage container name to which you will attach the SAS policy with its SAS token
$policyName = $prefixName + 'policy' # the name of the SAS policy

# Set a variable for the name of the resource group you will create or use
$resourceGroupName = $prefixName + 'rg'

# adds an authenticated Azure account for use in the session
Connect-AzAccount

# set the tenant, subscription and environment for use in the rest of
Set-AzContext -SubscriptionName $subscriptionName

# create a new resource group - comment out this line to use an existing resource group
New-AzResourceGroup -Name $resourceGroupName -Location $locationName

# Create a new ARM storage account - comment out this line to use an existing ARM storage account
New-AzStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -Type Standard_RAGRS -Location $locationName

# Get the access keys for the ARM storage account
$accountKeys = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName

# Create a new storage account context using an ARM storage account
$storageContext = New-AzStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $accountKeys[0].value

# Creates a new container in Azure Blob Storage
$container = New-AzStorageContainer -Context $storageContext -Name $containerName
$cbc = $container.CloudBlobContainer

# Sets up a Stored Access Policy and a Shared Access Signature for the new container
$policy = New-AzStorageContainerStoredAccessPolicy -Container $containerName -Policy $policyName -Context $storageContext -ExpiryTime $(Get-Date).ToUniversalTime().AddYears(10) -Permission "rwld"
$sas = New-AzStorageContainerSASToken -Policy $policyName -Context $storageContext -Container $containerName
Write-Host 'Shared Access Signature= '$($sas.TrimStart('?'))''

# Outputs the Transact SQL to the clipboard and to the screen to create the credential using the Shared Access Signature
Write-Host 'Credential T-SQL'
$tSql = "CREATE CREDENTIAL [{0}] WITH IDENTITY='Shared Access Signature', SECRET='{1}'" -f $cbc.Uri, $sas.TrimStart('?')
$tSql | clip
Write-Host $tSql

Après avoir exécuté le script, copiez la commande CREATE CREDENTIAL dans un outil de requête, connectez-vous à une instance de SQL Server et exécutez la commande pour créer les informations d’identification avec la signature d’accès partagé.

Créer des informations d’identification

Les exemples suivants créent des informations d’identification SQL Server pour l’authentification auprès du Stockage Blob Azure. Effectuez l’une des opérations suivantes.

  1. Utilisation d’une signature d’accès partagé

    Si vous avez exécuté le script précédent pour créer la signature d’accès partagé, copiez CREATE CREDENTIAL dans un éditeur de requête connecté à votre instance de SQL Server et exécutez la commande.

    Le code T-SQL suivant est un exemple qui crée les informations d’identification pour utiliser une signature d’accès partagé.

    IF NOT EXISTS (SELECT *
               FROM sys.credentials
               WHERE name = 'https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>')
    CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>]
        WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = '<SAS_TOKEN>';

  2. Utilisation d’une identité de compte de stockage et d’une clé d’accès

    IF NOT EXISTS (SELECT *
               FROM sys.credentials
               WHERE name = '<mycredentialname>')
    CREATE CREDENTIAL [<mycredentialname>]
        WITH IDENTITY = '<mystorageaccountname>', SECRET = '<mystorageaccountaccesskey>';

Effectuer une sauvegarde complète de la base de données

Les exemples suivants effectuent une sauvegarde complète de la base de données AdventureWorks2025 dans le Stockage Blob Azure. Utilisez l’un des échantillons suivants :

  1. Vers une URL en utilisant une signature d’accès partagé

    BACKUP DATABASE AdventureWorks2022
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak';
GO

  2. Vers une URL en utilisant une identité de compte de stockage et une clé d’accès

    BACKUP DATABASE AdventureWorks2022
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak'
WITH CREDENTIAL = '<mycredentialname>',
COMPRESSION, STATS = 5;
GO

Restaurer à un point dans le temps en utilisant STOPAT

L’exemple suivant restaure la base de données exemple AdventureWorks2025 dans l’état où elle était à un point dans le temps, et illustre une opération de restauration.

À partir d’une URL en utilisant une signature d’accès partagé

RESTORE DATABASE AdventureWorks2022
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022_2015_05_18_16_00_00.bak'
    WITH MOVE 'AdventureWorks2022_data' TO 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2022.mdf',
    MOVE 'AdventureWorks2022_log' TO 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2022.ldf',
    NORECOVERY, REPLACE, STATS = 5;
GO

RESTORE LOG AdventureWorks2022
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022_2015_05_18_18_00_00.trn'
    WITH RECOVERY, STOPAT = 'May 18, 2015 5:35 PM';
GO

Contenu connexe

  • Last updated on