Sauvegarde SQL Server sur URL pour Stockage Blob Microsoft Azure

  • Article

S’applique à :SQL ServerAzure SQL Managed Instance

Cet article présente les concepts, les exigences et les composants nécessaires pour utiliser Stockage Blob Microsoft Azure comme destination de sauvegarde. Les fonctionnalités de sauvegarde et de restauration sont identiques ou similaires à l'utilisation de l'option DISK ou TAPE, à quelques différences près. Ces différences et quelques exemples de code sont inclus dans cet article.

Vue d’ensemble

Il est important de comprendre les composants et l’interaction entre eux pour effectuer une sauvegarde ou une restauration à partir de Microsoft 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 soit utiliser le nom du compte de stockage Azure et la valeur de sa clé d’accès pour s’authentifier et écrire/lire des objets blob dans Stockage Blob Microsoft Azure, soit utiliser un jeton de signature d’accès partagé généré sur des conteneurs spécifiques lui octroyant des droits de lecture et d’écriture. Pour plus d’informations sur les comptes de Stockage Azure, 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 2012 Service Pack 1 CU2 et SQL Server 2014 ont introduit la possibilité de sauvegarder vers une URL pointée vers Stockage Blob Azure, à l’aide de la syntaxe T-SQL familière pour écrire des sauvegardes en toute sécurité dans le stockage Azure. SQL Server 2016 (13.x) a introduit les sauvegardes d’instantanés de fichiers pour les fichiers de base de données dans Azure et la sécurité via des clés de signature d’accès partagé (SAS), moyen sécurisé et simple d’authentifier des certificats pour la stratégie de sécurité Stockage Azure. SQL Server 2022 (16.x) introduit la possibilité d’écrire des sauvegardes dans un stockage d’objets compatible avec S3, avec des fonctionnalités de sauvegarde et de restauration conceptuellement similaires à l’utilisation de la sauvegarde à l’URL à l’aide de Stockage Blob Azure en tant que type d’appareil de sauvegarde. SQL Server 2022 (16.x) étend la syntaxe BACKUP/RESTORE TO/FROM URL en ajoutant la 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 sur URL pour le stockage compatible S3, consultez Sauvegarde et restauration SQL Server avec un stockage d’objets compatible S3.

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

Deux types d’objets blob peuvent être stockés dans Stockage Blob Microsoft 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 les informations d’identification, l’objet blob de pages sera utilisé ; si la signature d’accès partagé est utilisée, l’objet blob de blocs sera 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. Sauvegardez sur un objet blob de blocs au lieu d’un objet blob de pages si vous exécutez SQL Server 2016 ou 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 blob de blocs pour obtenir de meilleures performances de sauvegarde et de restauration, et prendre en charge une sauvegarde de base de données plus grande.
  • Un objet blob de blocs est moins cher qu’un objet blob de pages.
  • Les clients qui doivent sauvegarder sur des objets blob de pages via un serveur proxy doivent utiliser backuptourl.exe.

La sauvegarde d’une base de données volumineuse vers Stockage Blob Azure est soumise aux limitations répertoriées dans les différences, limitations et problèmes connus d’Azure SQL Managed Instance.

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

  • Utiliser la compression de la sauvegarde ou
  • Sauvegarder sur plusieurs objets blob de blocs

Prise en charge sur Linux, conteneurs et SQL Managed Instance activés par Azure Arc

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

  • Système d’exploitation autonome
  • conteneurs
  • 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 Blob Microsoft Azure

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

Conteneur : un conteneur permet de regrouper 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.

Objet blob: fichier de tout type et de toute 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 d’objet blob en fonction de la syntaxe Transact-SQL utilisée. Les objets blob sont adressables en utilisant le format d’URL suivant : https://<compte de stockage>.blob.core.windows.net/<conteneur>/<objet 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.

A diagram of Azure Blob Storage accounts, containers, and blobs.

Capture instantanée Azure : capture instantanée d’objet blob Azure effectuée à un point dans le temps. 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) vers 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é, la sauvegarde é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 : http[s]://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak. HTTPS n'est pas obligatoire, mais est recommandé.

Informations d’identification : 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 contiennent soit le nom du compte de stockage et les valeurs de clé d’accès de celui-ci, soit l’URL du conteneur et son jeton de signature d’accès partagé. Une fois les informations d’identification créées, la syntaxe des instructions BACKUP/RESTORE 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 en général, consultez Informations d’identification.

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

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.

  • Quand vous créez un conteneur pour le Stockage Blob Azure, nous vous recommandons de définir l’accès sur 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.

    Avertissement

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

  • Le compte d’utilisateur utilisé pour émettre les commandes BACKUP (sauvegarder) ou RESTORE (restaurer) doit figurer dans le rôle de base de données db_backup operator avec les autorisations Modifier des 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 de sauvegarde prise en charge avec des objets blob de blocs est limitée à environ 200 Go (50 000 blocs * 4 Mo de MAXTRANSFERSIZE). Les objets blob de blocs prennent en charge le striping pour prendre en charge des tailles de sauvegarde beaucoup plus grandes : la limite est de 64 URL maximales, ce qui entraîne 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 objet blob de blocs unique soit de 200 Go, il est possible que SQL Server écrive dans des tailles de blocs plus petites, ce qui peut amener SQL Server à atteindre la limite de bloc de 50 000 avant le transfert de l’intégralité de la sauvegarde. 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, de l’Assistant Sauvegarde ou restauration de SQL Server Management Studio.

  • La sauvegarde vers Stockage Azure compte 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 d'unité logique n'est pas prise en charge. Par conséquent, l'ajout d'une URL comme unité de sauvegarde à l'aide de sp_dumpdevice ou de SQL Server Management Studio n'est pas pris en charge.

  • L'ajout d'objets blob 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 . Toutefois, lors de l’utilisation de sauvegardes de capture instantanée de fichier (avec l’argument WITH FILE_SNAPSHOT ), l’argument WITH FORMAT n’est pas autorisé, pour éviter de laisser orphelines des captures instantanées de fichier qui ont été créées avec la sauvegarde file-snapshot 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 de BLOCKSIZE n’est pas prise en charge pour les objets blob de pages.

  • La spécification de MAXTRANSFERSIZE n’est pas prise en charge pour les objets blob de pages.

  • La spécification des options du jeu de sauvegarde RETAINDAYS et EXPIREDATE n’est pas prise en charge.

  • SQL Server est soumis à une limite de 259 caractères pour le nom d'une unité de sauvegarde. BACKUP TO URL utilise 36 caractères pour les éléments requis utilisés pour spécifier l’URL « https://.blob.core.windows.net//.bak  », ce qui laisse 223 caractères pour les noms de compte, de conteneur et d’objet blob réunis.

  • Les versions de SQL Server antérieures à 2022 ont une limite de 256 caractères pour les jetons de signature d’accès partagé (SAP), 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 :

    • L’utilitaire proxycfg.exe sur Windows XP ou Windows Server 2003 et versions antérieures.
    • L’utilitaire netsh.exe sur Windows Vista et Windows Server 2008 ou versions ultérieures.

  • Le stockage immuable pour Stockage Blob Azure n’est pas pris en charge. Affectez la valeur false à la stratégie Stockage immuable.

Arguments &instructions pris en charge dans Stockage Blob Azure

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

Instruction de sauvegarde/restauration Prise en charge Exceptions Commentaires
BACKUP Y BLOCKSIZE et MAXTRANSFERSIZE sont pris en charge pour les objets blob de blocs. Ils ne sont pas pris en charge pour les objets blob de pages. BACKUP sur un objet blob de blocs nécessite une Signature d’accès partagé enregistrée dans des informations d’identification SQL Server. BACKUP vers l’objet blob de pages nécessite l’enregistrement de la clé de compte de stockage dans les informations d’identification SQL Server et l’argument WITH CREDENTIAL doit être spécifié.
RESTORE Y 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 Y 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 Y 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 Y 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 Y 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 -

Pour plus d’informations sur la syntaxe et les instructions de sauvegarde, consultez BACKUP (Transact-SQL).

Pour plus d’informations sur la syntaxe et les instructions de restauration, consultez RESTORE (Transact-SQL).

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

Argument Prise en charge Exception Commentaires
DATABASE Y
LOG Y
TO (URL) Y Contrairement à DISK et TAPE, 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 Y
WITH OPTIONS :
CREDENTIAL Y L’argument WITH CREDENTIAL est pris en charge uniquement en cas d’utilisation de l’option BACKUP TO URL pour sauvegarder dans le Stockage Blob Azure, et uniquement si les informations d’identification SQL Server sont définies avec comme secret la clé du compte de stockage.
FILE_SNAPSHOT Y
ENCRYPTION Y 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 instantané lui-même à l’aide de l’algorithme spécifié pour TDE sur la base de données. Si des données de la base de données ne sont pas chiffrées (par exemple, si le processus de chiffrement n’est pas encore terminé), la sauvegarde échoue.
DIFFERENTIAL Y
COPY_ONLY Y
COMPRESSION|NO_COMPRESSION Y Non prise en charge pour une sauvegarde de capture instantanée de fichier.
DESCRIPTION Y
NOM O
EXPIRÉ | RETAINDAYS -
NOINIT | INIT - L'ajout aux objets blob n'est pas possible. Pour remplacer une sauvegarde, utilisez l’argument WITH FORMAT. Toutefois, lors de l’utilisation de sauvegardes de capture instantanée de fichier (avec l’argument WITH FILE_SNAPSHOT ), l’argument WITH FORMAT n’est pas autorisé, pour éviter de laisser orphelines des captures instantanées de fichier qui ont été créées avec la sauvegarde d’origine.
NOSKIP | IGNORER -
NOFORMAT | FORMAT Y Une sauvegarde effectuée vers un objet blob existant échoue à moins que l’option WITH FORMAT soit spécifiée. Quand l’option WITH FORMAT est spécifiée, l’objet blob existant est remplacé. Toutefois, lors de l’utilisation de sauvegardes de capture instantanée de fichier (avec l’argument WITH FILE_SNAPSHOT ), l’argument FORMAT n’est pas autorisé, pour éviter de laisser orphelines des captures instantanées de fichier qui ont été créées avec la sauvegarde file-snapshot d’origine. Toutefois, lors de l’utilisation de sauvegardes de capture instantanée de fichier (avec l’argument WITH FILE_SNAPSHOT ), l’argument WITH FORMAT n’est pas autorisé, pour éviter de laisser orphelines des captures instantanées de fichier qui ont été créées avec la sauvegarde d’origine.
MEDIADESCRIPTION Y
MEDIANAME Y
BLOCKSIZE Y Non pris en charge pour l’objet blob de pages. Prise en charge pour l’objet blob de blocs. Nous recommandons BLOCKSIZE=65536 pour optimiser l’utilisation des 50 000 blocs autorisés dans un objet blob de blocs.
BUFFERCOUNT Y
MAXTRANSFERSIZE Y 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 1 048 576. La valeur peut aller jusqu’à 4 Mo, par incréments de 65 536 octets.
Nous recommandons MAXTRANSFERSIZE=4194304 pour optimiser l’utilisation des 50 000 blocs autorisés dans un objet blob de blocs.
NO_CHECKSUM | CHECKSUM Y
STOP_ON_ERROR | CONTINUE_AFTER_ERROR Y
STATS Y
REWIND | NOREWIND -
UNLOAD | NOUNLOAD -
NORECOVERY | VEILLE Y
NO_TRUNCATE Y

Pour plus d’informations sur les arguments de sauvegarde, consultez BACKUP (Transact-SQL).

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

Argument Prise en charge Exceptions Commentaires
DATABASE Y
LOG Y
FROM (URL) Y L'argument FROM URL est utilisé pour spécifier le chemin d'accès de l'URL du fichier de sauvegarde.
WITH Options:
CREDENTIAL Y L’argument WITH CREDENTIAL est pris en charge uniquement en cas d’utilisation de l’option RESTORE FROM URL pour une restauration à partir du Stockage Blob Microsoft Azure.
PARTIAL Y
RECOVERY | NORECOVERY | VEILLE Y
LOADHISTORY Y
MOVE Y
REPLACE Y
RESTART Y
RESTRICTED_USER Y
FILE -
PASSWORD Y
MEDIANAME Y
MEDIAPASSWORD Y
BLOCKSIZE Y
BUFFERCOUNT -
MAXTRANSFERSIZE -
SOMME DE CONTRÔLE | NO_CHECKSUM Y
STOP_ON_ERROR | CONTINUE_AFTER_ERROR Y
FILESTREAM Y Non prise en charge pour la sauvegarde de capture instantanée.
STATS Y
REWIND | NOREWIND -
UNLOAD | NOUNLOAD -
KEEP_REPLICATION Y
KEEP_CDC Y
ENABLE_BROKER | ERROR_BROKER_CONVERSATIONS | NEW_BROKER Y
STOPAT | STOPATMARK | STOPBEFOREMARK Y

Pour plus d’informations sur les arguments de restauration, consultez Arguments RESTORE (Transact-SQL).

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.

Remarque

Pour créer une sauvegarde de fichiers instantané SQL Server ou remplacer un support 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 Sauvegarde sur . L’option URL sert à créer une sauvegarde dans le stockage Microsoft Azure. Sélectionnez Ajouter pour ouvrir la boîte de dialogue Sélectionner la destination de la sauvegarde :

    1. Conteneur de stockage Azure : nom du conteneur de stockage Microsoft 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 : permet d’enregistrer un conteneur existant pour lequel vous n’avez pas de signature d’accès partagé. Consultez Se connecter à un abonnement Microsoft Azure.

Remarque

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

Quand vous sélectionnez URL comme destination, certaines options de la page Options de support 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 le 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.

Remarque

Pour créer un jeu de sauvegarde à bandes, une sauvegarde de fichiers SQL Server instantané ou des informations d’identification SQL à l’aide du jeton d’accès partagé, vous devez utiliser Transact-SQL, PowerShell ou C# plutôt que la tâche de sauvegarde dans l’Assistant Plan de maintenance.

Restaurer avec SSMS

La tâche Restaurer la base de données propose URL comme unité à partir de laquelle 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 Unité dans 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 URL dans la liste déroulante Type de support 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 Microsoft Azure qui contient les fichiers de sauvegarde. Sélectionnez un conteneur existant dans la liste déroulante ou entrez manuellement le nom qualifié complet du conteneur.

    2. Signature d’accès partagé : permet d’entrer la signature d’accès partagé pour le conteneur spécifié.

    3. Ajouter : permet d’enregistrer un conteneur existant pour lequel vous n’avez pas de signature d’accès partagé. Consultez Se connecter à un abonnement Microsoft Azure.

    4. OK : SQL Server se connecte au stockage Microsoft Azure en utilisant les informations d’identification SQL spécifiées 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 à utiliser pour la restauration, puis sélectionnez OK. Vous revenez ainsi à 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 dans laquelle vous serez en mesure de terminer la restauration.

    Restaurer la base de données (page Général)

    Restaurer la base de données (page Fichiers)

    Restaurer la base de données (page Options)

Exemples de code

Cette section contient les exemples suivants :

Remarque

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

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

L’exemple suivant crée des signatures d’accès partagé qui peuvent être utilisées 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.

Remarque

L’exemple nécessite Microsoft Azure Powershell. Pour plus d’informations sur l’installation et l’utilisation d’Azure Powershell, consultez Installation et configuration d’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

Une fois le script exécuté, copiez la CREATE CREDENTIAL commande 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-le 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 AdventureWorks2022 base de données sur Stockage Blob Azure. Utilisez l’un des exemples 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 l’exemple AdventureWorks2022 de base de données à son état à un moment donné et affiche 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