Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Applies to :SQL Server
Azure SQL Managed Instance
Cet article présente les concepts, les exigences et les 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é managée. Passez en revue Back up to URL with managed identity (préversion) - SQL Server activé par Azure Arc.
Overview
SQL Server 2012 Service Pack 1 CU2 et SQL Server 2014 ont introduit la possibilité de sauvegarder sur 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 Azure stockage. SQL Server 2016 (13.x) a introduit sauvegardes instantanées 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), un moyen sécurisé et simple d'authentifier des certificats dans la stratégie de sécurité de stockage Azure.
Il est important de comprendre les composants et l'interaction entre eux pour effectuer une sauvegarde ou une restauration à partir de Stockage Blob Azure.
La création d’un compte 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 s’authentifier et lire et écrire des objets blob dans Stockage Blob Azure, ou utiliser un jeton de signature d’accès partagé généré pour des conteneurs spécifiques, lui accordant des droits de lecture et d’écriture. Pour plus d’informations sur Comptes de stockage Azure, consultez About Comptes de stockage Azure et pour plus d’informations sur les signatures d’accès partagé, consultez Signatures d’accès partagé, partie 1 : Présentation du modèle SAS. Les informations d’identification SQL Server stockent ces informations d’authentification et sont utilisées pendant 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 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 vers l’URL pour Stockage Blob Azure. Pour en savoir plus sur l’utilisation de la sauvegarde vers l’URL pour le stockage compatible avec S3, consultez SQL Server sauvegarder vers l’URL pour le stockage d’objets compatible avec S3.
Sauvegarde vers stockage Azure objet blob de blocs par rapport à l’objet blob de pages
Il existe deux types d’objets blob qui peuvent être stockés dans Stockage Blob Azure : les objets blob de blocs et de pages. Pour SQL Server 2016 et les versions suivantes, le blob de type block 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 vers un objet blob de blocs n’est disponible que dans SQL Server version 2016 ou ultérieure pour la sauvegarde vers Stockage Blob Azure. Sauvegardez sur un objet blob de blocs plutôt que sur un objet blob de pages 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 base de données volumineuse vers Stockage Blob Azure est soumise aux limitations répertoriées dans Azure SQL Managed Instance différences T-SQL, limitations et problèmes connus.
Si la base de données est trop grande, vous pouvez :
- Utiliser la compression de la sauvegarde ou
- Sauvegarde vers plusieurs block blobs
Support pour Linux, conteneurs et Instances Gérées SQL grâce à Azure Arc
Si l’instance de 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 prise en charge vers l’URL pour Stockage Blob Azure consiste à bloquer des objets blob à l’aide de la signature d’accès partagé.
Stockage Blob Azure
Compte de stockage : Le compte de stockage est le point de départ de tous les services de stockage. Pour accéder à 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 dans Stockage Blob Azure, vous devez avoir au moins le conteneur racine 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 stockés dans Stockage Blob Azure : les objets blob de blocs et de pages. La sauvegarde SQL Server peut utiliser l'un ou l'autre type de blob selon 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 Stockage Blob Azure, consultez Introduction pour 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.
Azure Snapshot : Instantané 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 instantanées Azure de fichiers de base de données stockés dans Stockage Blob Azure. Pour plus d’informations, consultez sauvegardes instantanées 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 est utilisée pour fournir 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 une URL n'est pas prise en charge en utilisant HTTP.
Credential : Les informations d’identification de 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 de SQL Server utilisent des informations d’identification pour s’authentifier auprès d'Stockage Blob Azure et de ses objets conteneur et 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 établies, la syntaxe des instructions BACKUP/RESTORE détermine le type d’objet blob et les informations d’identification requises.
Pour obtenir un exemple sur la création d’une signature d’accès partagé, consultez les exemples de Créer une signature d’accès partagé plus loin dans cet article et, pour créer des informations d’identification SQL Server, voir les exemples de Créer des informations d’identification plus loin dans cet article.
Pour plus d’informations sur les informations d’identification, consultez Credentials (Moteur de base de données).
Pour plus d’informations sur les autres exemples d’informations d’identification utilisés, consultez Create a SQL Server Agent Proxy.
prise en charge du stockage immuable Azure
SQL Server 2025 (17.x) introduit la prise en charge de Azure stockage immuable, 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, SQL Server sauvegardes 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.
Azure stockage fournit deux types d’immuabilité, de niveau conteneur et de niveau de version. Actuellement, seul le stockage immuable au niveau du conteneur est pris en charge.
Pour utiliser un stockage immuable avec SQL Server 2025 (17.x) pour sauvegarde vers une URL, procédez comme suit :
Paramétrez l'immutabilité de votre conteneur de stockage Azure.
Émettez le BACKUP pour sauvegarder votre base de données dans le conteneur de stockage Azure. Si vous utilisez l’option sur le
WITH FORMATstockage 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é des Stockage Blob Azure
Voici quelques considérations et exigences de sécurité lors de la sauvegarde ou de la restauration à partir de Stockage Blob Azure.
Lors de la création d’un conteneur pour Stockage Blob Azure, nous vous recommandons de définir l’accès à private. La définition de l’accès privé restreint l’accès aux utilisateurs ou aux comptes en mesure de fournir les informations nécessaires pour s’authentifier auprès du compte Azure.
Important
SQL Server exige que soient stockés dans des Identifiants SQL Server soit un nom de compte Azure avec une authentification par clé d’accès, soit une signature d'accès partagé avec un jeton d’accès. Ces informations sont utilisées pour s’authentifier 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 URL ne fonctionnera pas.
Le compte d’utilisateur utilisé pour émettre des
BACKUPouRESTOREcommandes doit avoir le rôle de db_backup operator dans la base de données avec des autorisations Modifier les informations d'identification.
Limitations de la sauvegarde/restauration sur Stockage Blob Azure
SQL Server limite la taille de sauvegarde maximale prise en charge à l’aide d’un objet blob de pages à 1 To. La taille maximale de sauvegarde prise en charge avec des blobs de blocs est limitée à environ 195,3 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 objet blob de blocs unique soit d'environ 195,3 Go, il est possible que SQL Server écrive dans des tailles de blocs plus petites, ce qui peut entraîner SQL Server d'atteindre la limite de bloc de 50 000 avant le transfert de la sauvegarde entière. 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.
Les sauvegardes du journal des transactions ignorent le paramètre spécifié par l'utilisateur
MAXTRANSFERSIZElors de la sauvegarde vers plusieurs fichiers de sauvegarde. Au lieu de cela, 64 Ko sont utilisés si plusieurs fichiers sont spécifiés, quelle que soit laMAXTRANSFERSIZEvaleur de la commande de sauvegarde. Par conséquent, la taille maximale d’une sauvegarde du journal des transactions vers l’URL est d’environ 195,3 Go (50 000 blocs * 4 MoMAXTRANSFERSIZE* 1 fichier OR 50 000 blocs * 64 Ko * 64 fichiers). La compression peut permettre la sauvegarde d’un journal des transactions plus volumineux, mais les ratios de compression varient.Vous pouvez émettre des instructions de sauvegarde ou de restauration à l’aide de Transact-SQL, de SMO, d’applets de commande PowerShell ou de l’Assistant sauvegarde ou restauration SQL Server Management Studio.
Lors de la sauvegarde sur un compte 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 (formerly 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. Par conséquent, l'ajout d'une URL en tant que périphérique de sauvegarde en utilisant
sp_dumpdeviceou via SQL Server Management Studio n'est 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’argumentWITH FILE_SNAPSHOT), l’argumentWITH FORMATn’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
BLOCKSIZEn’est pas prise en charge pour les blocs de pages.La spécification de
MAXTRANSFERSIZEn'est pas prise en charge pour les blobs de pages.Spécification des options d’ensemble de sauvegarde :
RETAINDAYSetEXPIREDATEne sont pas prises en charge.SQL Server a une limite maximale de 259 caractères pour un nom d’appareil de sauvegarde. L’objet
BACKUP TO URLconsomme 36 caractères pour les éléments requis utilisés pour spécifier l’URLhttps://.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 SAP (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.
Stockageimmutable pour Stockage Blob Azure n'est pas pris en charge avant SQL Server 2025. Définissez la stratégie de stockage immuable sur false.
Pour obtenir la prise en charge dans SQL Server 2025 et versions ultérieures, consultez prise en charge du stockage immuable Azure.
- Azure stockage fournit deux types d’immuabilité, de niveau conteneur et de niveau de version. Actuellement, seul le stockage immuable au niveau du conteneur est pris en charge.
La sauvegarde vers l’URL n’est pas prise en charge dans le stockage Premium.
Arguments et déclarations prises en charge dans Stockage Blob Azure
Prise en charge des instructions de sauvegarde/restauration dans Stockage Blob Azure
| Backup/Restore, instruction | Supported | Exceptions | Comments |
|---|---|---|---|
BACKUP |
Yes |
BLOCKSIZE et MAXTRANSFERSIZE sont pris en charge pour les blobs de type bloc. Ils ne sont pas pris en charge pour les page blobs. |
BACKUP à un blob de blocs nécessite une signature d'accès partagé enregistrée dans des informations d'identification de SQL Server.
BACKUP vers un blob de pages nécessite que la clé de compte de stockage soit enregistrée dans un identifiant SQL Server et que l’argument WITH CREDENTIAL soit spécifié. |
RESTORE |
Yes | Nécessite la définition des informations d'identification SQL Server et nécessite que l’argument WITH CREDENTIAL soit précisé si les informations d’identification SQL Server sont définies utilisant la clé du compte de stockage comme secret. |
|
RESTORE FILELISTONLY |
Yes | Nécessite des informations d'identification SQL Server à définir et nécessite que l'argument WITH CREDENTIAL soit spécifié si les informations d'identification SQL Server sont définies avec la clé du compte de stockage comme secret. |
|
RESTORE HEADERONLY |
Yes | Nécessite des informations d'identification SQL Server à définir et nécessite que l'argument WITH CREDENTIAL soit spécifié si les informations d'identification SQL Server sont définies avec la clé du compte de stockage comme secret. |
|
RESTORE LABELONLY |
Yes | Nécessite des informations d'identification SQL Server à définir et nécessite que l'argument WITH CREDENTIAL soit spécifié si les informations d'identification SQL Server sont définies avec la clé du compte de stockage comme secret. |
|
RESTORE VERIFYONLY |
Yes | Nécessite des informations d'identification SQL Server à définir et nécessite que l'argument WITH CREDENTIAL soit spécifié si les informations d'identification SQL Server sont définies avec la clé du 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 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 pris en charge uniquement lors de l’utilisation de l’option BACKUP TO URL pour sauvegarder sur 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. | Il est recommandé d’optimiser l’utilisation de BLOCKSIZE=65536 pour les 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. Il est recommandé d'optimiser MAXTRANSFERSIZE=4194304 pour utiliser efficacement les 50 000 blocs autorisés dans un 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 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 pris en charge uniquement lors de l’utilisation de l’option RESTORE FROM URL pour effectuer une restauration à partir de 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 en URL via la tâche de sauvegarde dans SQL Server Management Studio à l’aide d’une SQL Server Credential.
Note
Pour créer une sauvegarde d’instantané de fichier 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 permettre la sauvegarde dans Azure stockage :
Dans Explorateur d'objets, connectez-vous à une instance du Moteur de base de données SQL Server, puis développez cette instance.
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....
Dans la page Général de la section Destination, l’option URL est disponible dans la liste déroulante Sauvegarder jusqu’à : L’option URL est utilisée pour créer une sauvegarde dans Azure stockage. Sélectionnez Ajouter, puis la boîte de dialogue Sélectionner la destination de sauvegarde s’ouvre :
Azure conteneur de stockage : 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.
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.
Fichier de sauvegarde : Nom du fichier de sauvegarde.
Nouveau conteneur : Utilisé pour inscrire un conteneur existant pour lequel vous n’avez pas de signature d’accès partagé. Voir Connect to a Microsoft Azure Subscription (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 la base de données (page Général)
- Sauvegarder la base de données (page Options du média)
- Sauvegarder la base de données (page Options de sauvegarde)
- Créer les informations d’identification - S’authentifier auprès de stockage Azure
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 URL comme l’une des options de destination et d’autres objets de prise en charge nécessaires à la sauvegarde vers le stockage Azure comme les identifiants 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 à bandes, une sauvegarde d’instantané de fichier SQL Server 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.
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 de restauration pour effectuer une restauration à partir de Stockage Blob Azure :
Cliquez avec le bouton droit sur Bases de données et sélectionnez Restaurer la base de données....
Dans la page Général , sélectionnez Appareil sous la section Source .
Sélectionnez le bouton Parcourir (...) pour ouvrir la boîte de dialogue Sélectionner les unités de sauvegarde.
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 .
Azure conteneur de stockage : 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.
Signature d’accès partagé : Utilisé pour entrer la signature d’accès partagé pour le conteneur désigné.
Ajouter: Utilisé pour inscrire un conteneur existant pour lequel vous n’avez pas de signature d’accès partagé. Consultez Connect to a Microsoft Azure Subscription (Backup TO URL).
OK : SQL Server se connecte à Azure Storage à 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 :
- Créer une signature d’accès partagé
- Créer des informations d'identification
- Effectuer une sauvegarde complète de la base de données
- Restaurer à un instant précis en utilisant STOPAT
Note
Pour obtenir un didacticiel sur l’utilisation de SQL Server 2016 avec Stockage Blob Azure, consultez Tutorial : 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é qui peuvent être utilisées pour créer un SQL Server Credential 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 de Azure PowerShell, consultez Comment installer et configurer Azure PowerShell. Ces scripts ont été vérifiés à l’aide de 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 à Stockage Blob Azure. Effectuez l’une des opérations suivantes.
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 CREDENTIALdans 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>';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 à Stockage Blob Azure. Utilisez l’un des échantillons suivants :
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'; GOVers 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