BACKUP (Transact-SQL)

Article
12/28/2023

Sauvegarde une base de données SQL.

Sélectionner un produit

Sur la ligne suivante, sélectionnez le nom du produit qui vous intéresse afin d’afficher uniquement les informations qui le concernent.

Pour plus d’informations sur les conventions de la syntaxe, consultez Conventions de la syntaxe Transact-SQL.

* SQL Server *

SQL Managed Instance

Analytics Platform
System (PDW)

SQL Server

Sauvegarde une base de données SQL Server complète pour créer une sauvegarde de la base de données, ou un ou plusieurs fichiers ou groupes de fichiers de la base de données pour créer une sauvegarde de fichiers (BACKUP DATABASE). De plus, en mode de restauration complète ou en mode de récupération utilisant les journaux de transactions, sauvegarde le journal des transactions de la base de données afin de créer une sauvegarde de journal (BACKUP LOG).

Syntaxe

--Back up a whole database
BACKUP DATABASE { database_name | @database_name_var }
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL
           | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up specific files or filegroups
BACKUP DATABASE { database_name | @database_name_var }
 <file_or_filegroup> [ ,...n ]
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]

--Create a partial backup
BACKUP DATABASE { database_name | @database_name_var }
 READ_WRITE_FILEGROUPS [ , <read_only_filegroup> [ ,...n ] ]
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up the transaction log (full and bulk-logged recovery models)
BACKUP LOG
  { database_name | @database_name_var }
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { <general_WITH_options> | <log_specific_options> } [ ,...n ] ]
[;]

--Back up all the databases on an instance of SQL Server (a server)

ALTER SERVER CONFIGURATION
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON
[;]

BACKUP SERVER
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { METADATA_ONLY
           | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up a group of databases
ALTER DATABASE <database>
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON

ALTER DATABASE <...>
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON
...

BACKUP GROUP {<database> [,... ]}
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { METADATA_ONLY
           | <general_WITH_options> [ ,...n ] } ]
[;]

<backup_device>::=
 {
  { logical_device_name | @logical_device_name_var }
 | {   DISK
     | TAPE
     | URL } =
     { 'physical_device_name' | @physical_device_name_var | 'NUL' }
 }

<MIRROR TO clause>::=
 MIRROR TO <backup_device> [ ,...n ]

<file_or_filegroup>::=
 {
   FILE = { logical_file_name | @logical_file_name_var }
 | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
 }

<read_only_filegroup>::=
FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

<general_WITH_options> [ ,...n ]::=
--Backup Set Options
   COPY_ONLY
 | [ COMPRESSION [ ALGORITHM = { MS_XPRESS | accelerator_algorithm } ] | NO_COMPRESSION ]
 | DESCRIPTION = { 'text' | @text_variable }
 | NAME = { backup_set_name | @backup_set_name_var }
 | CREDENTIAL
 | ENCRYPTION
 | FILE_SNAPSHOT
 | { EXPIREDATE = { 'date' | @date_var }
        | RETAINDAYS = { days | @days_var } }
 | { METADATA_ONLY | SNAPSHOT }

--Media Set Options
   { NOINIT | INIT }
 | { NOSKIP | SKIP }
 | { NOFORMAT | FORMAT }
 | MEDIADESCRIPTION = { 'text' | @text_variable }
 | MEDIANAME = { media_name | @media_name_variable }
 | BLOCKSIZE = { blocksize | @blocksize_variable }

--Data Transfer Options
   BUFFERCOUNT = { buffercount | @buffercount_variable }
 | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

--Error Management Options
   { NO_CHECKSUM | CHECKSUM }
 | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

--Compatibility Options
   RESTART

--Monitoring Options
   STATS [ = percentage ]

--Tape Options
   { REWIND | NOREWIND }
 | { UNLOAD | NOUNLOAD }

--Encryption Options
 ENCRYPTION (ALGORITHM = { AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY } , encryptor_options ) <encryptor_options> ::=
   SERVER CERTIFICATE = Encryptor_Name | SERVER ASYMMETRIC KEY = Encryptor_Name

<log_specific_options> [ ,...n ]::=
--Log-specific Options
   { NORECOVERY | STANDBY = undo_file_name }
 | NO_TRUNCATE

Arguments

DATABASE

Spécifie une sauvegarde complète de la base de données. Si une liste de fichiers et de groupes de fichiers est spécifiée, seuls ceux-ci sont sauvegardés. Au cours d'une sauvegarde de base de données complète ou différentielle, SQL Server sauvegarde une portion suffisante du journal des transactions afin d'assurer la cohérence de la base de données lors de la restauration de la sauvegarde.

Lorsque vous restaurez une sauvegarde créée par BACKUP DATABASE (une sauvegarde de données), l’ensemble de la sauvegarde est restauré. Seule une sauvegarde du fichier journal peut être restaurée à un moment ou une transaction spécifique au sein de la sauvegarde.

Notes

Seule une sauvegarde complète peut être effectuée sur la base de données master.

LOG

Indique que la sauvegarde ne doit porter que sur le journal des transactions. Le journal est sauvegardé à partir de la dernière sauvegarde réussie du fichier journal et jusqu'à sa fin actuelle. Avant de pouvoir créer la première sauvegarde du fichier journal, vous devez créer une sauvegarde complète.

Vous pouvez restaurer une sauvegarde du fichier journal jusqu’à une date et heure précises ou une transaction spécifique en spécifiant WITH STOPAT,STOPATMARK ou STOPBEFOREMARK dans votre instruction RESTORE LOG.

Notes

Après une sauvegarde de fichier journal standard, certains enregistrements du journal des transactions deviennent inactifs, sauf si vous spécifiez WITH NO_TRUNCATE ou COPY_ONLY. Le journal est tronqué une fois que tous les enregistrements d'un ou de plusieurs fichiers journaux virtuels sont devenus inactifs. Si le journal n'est pas tronqué après des sauvegardes normales du journal, il se peut que quelque chose retarde la troncation du journal. Pour plus d’informations, consultez Facteurs pouvant retarder la troncation du journal.

GROUP (<database>,...n)

Introduite dans SQL Server 2022 (16.x).

Sauvegarde un groupe de bases de données. Utilise la sauvegarde d’instantané. Nécessite WITH METADATA_ONLY. Consultez Créer une sauvegarde d’instantané Transact-SQL.

SERVER

Introduite dans SQL Server 2022 (16.x).

Sauvegarde toutes les bases de données sur une instance de SQL Server. Utilise la sauvegarde d’instantané. Nécessite WITH METADATA_ONLY. Consultez Créer une sauvegarde d’instantané Transact-SQL.

METADATA_ONLY

Introduite dans SQL Server 2022 (16.x).

Obligatoire pour la sauvegarde d’instantanés. BACKUP SERVER ou BACKUP GROUP... Consultez Créer une sauvegarde d’instantané Transact-SQL.

METADATA_ONLY est synonyme de SNAPSHOT. VDI (Virtual Device Interface) utilise SNAPSHOT. Pour plus d’informations, consultez les informations de référence sur VDI (Virtual Device Interface).

{ database_name | @database_name_var }

Correspond à la base de données à partir de laquelle va être opérée la sauvegarde du journal des transactions, c'est à dire la sauvegarde complète ou partielle. S’il est fourni comme variable (@database_name_var), ce nom peut être spécifié comme constante de chaîne (@database_name_var=database name) ou comme variable de type de données chaîne de caractères, sauf pour les types de données ntext ou text.

Notes

La base de données miroir d'un partenariat de mise en miroir de bases de données ne peut pas être sauvegardée.

<> file_or_filegroup [ ,...n ]

Utilisé uniquement avec BACKUP DATABASE, cet argument spécifie un fichier ou groupe de fichiers de base de données à inclure dans une sauvegarde de fichiers ou spécifie un fichier ou groupe de fichiers en lecture seule à inclure dans une sauvegarde partielle.

FILE = { logical_file_name | @logical_file_name_var }

Nom logique d'un fichier ou variable dont la valeur correspond au nom logique d'un fichier à inclure dans la sauvegarde.

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

Nom logique d'un groupe de fichiers ou variable dont la valeur correspond au nom logique d'un groupe de fichiers à inclure dans la sauvegarde. En mode de récupération simple, la sauvegarde d'un groupe de fichiers n'est autorisée que pour un groupe de fichiers en lecture seule.

Notes

Pensez à utiliser des sauvegardes de fichiers lorsque la taille de la base de données et les exigences en matière de performances rendent la sauvegarde de la base de données totalement inadaptée. L’appareil NULL peut être utilisé pour tester les performances des sauvegardes, mais il ne doit pas être utilisé dans les environnements de production.

n
Espace réservé indiquant qu'il est possible de spécifier plusieurs fichiers et groupes de fichiers dans une liste séparée par des virgules. Le nombre est illimité.

Pour plus d’informations, consultez les articles Sauvegardes de fichiers complètes et Sauvegarder des fichiers et des groupes de fichiers.

READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } [ ,...n ] ]

Spécifie une sauvegarde partielle. Une sauvegarde partielle inclut tous les fichiers en lecture/écriture dans une base de données : le groupe de fichiers primaire, tous les groupes de fichiers secondaires en lecture/écriture, ainsi que les fichiers ou groupes de fichiers en lecture seule qui ont été spécifiés.

READ_WRITE_FILEGROUPS

Spécifie que tous les groupes de fichiers en lecture/écriture doivent être sauvegardés dans la sauvegarde partielle. Si la base de données est en lecture seule, READ_WRITE_FILEGROUPS inclut uniquement le groupe de fichiers primaire.

Important

Si, au lieu d'utiliser READ_WRITE_FILEGROUPS, vous listez de manière explicite les groupes de fichiers en lecture/écriture en utilisant FILEGROUP, vous allez créer une sauvegarde de fichiers.

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

Nom logique d'un groupe de fichiers en lecture seule ou variable dont la valeur correspond au nom logique d'un groupe de fichiers en lecture seule à inclure dans la sauvegarde partielle. Pour plus d’informations, consultez « <file_or_filegroup> » plus haut dans cet article.

n
Espace réservé indiquant qu'il est possible de spécifier plusieurs groupes de fichiers en lecture seule dans une liste séparée par des virgules.

Pour plus d’informations sur les sauvegardes partielles, consultez l’article Sauvegardes partielles.

TO <backup_device> [ ,...n ]

Indique que le jeu d’unités de sauvegarde associé est soit un support de sauvegarde non miroir, soit le premier miroir d’un support de sauvegarde miroir (pour lequel une ou plusieurs clauses MIRROR TO sont déclarées).

<backup_device>
Spécifie l'unité de sauvegarde logique ou physique à utiliser pour l'opération de sauvegarde.

{ logical_device_name | @logical_device_name_var }

S’applique à : SQL Server
Nom logique de l'unité de sauvegarde dans laquelle la base de données est sauvegardée. Le nom logique doit se conformer aux règles en vigueur pour les identificateurs. Fourni comme variable (@logical_device_name_var), le nom logique de l’unité de sauvegarde peut être spécifié sous la forme d’une constante de chaîne (@logical_device_name_var=) ou d’une variable de type chaîne de caractères, sauf pour les types de données ntext ou text.

{ DISK | TAPE | URL} = { 'physical_device_name' | @physical_device_name_var | 'NUL' }

S’applique à : SQL Server (URL à compter de SQL Server 2012 (11.x) SP1 CU2)

Spécifie un fichier de disque ou un périphérique de bande, ou une URL.

Le format d’URL est utilisé pour créer des sauvegardes dans le Stockage Blob Microsoft Azure ou le stockage d’objets compatible S3. Pour plus d’informations et d’exemples, consultez :

Sauvegarde et restauration SQL Server avec le Stockage Blob Microsoft Azure. Pour obtenir un tutoriel, consultez Tutoriel : Sauvegarde et restauration SQL Server dans le Stockage Blob Microsoft Azure.
La sauvegarde et la restauration dans le stockage compatible S3 ont été introduites dans SQL Server 2022 (16.x). Consultez Sauvegarde et restauration SQL Server avec le stockage d’objets compatible S3. Passez également en revue l’option de sauvegarde SQL Server vers l’URL pour le stockage d’objets compatible S3.

Notes

L’unité de disque NUL supprime toutes les informations qui lui sont envoyées et ne devrait être utilisée qu’à des fins de test. À ne pas utiliser en production.

Important

De SQL Server 2012 (11.x) SP1 CU2 à SQL Server 2014 (12.x), la sauvegarde sur URL n’est possible que sur une seule unité pour le Stockage Blob Azure. Pour effectuer une sauvegarde sur plusieurs unités lorsque vous sauvegardez vers une URL, vous devez utiliser SQL Server 2016 (13.x) et versions ultérieures, ainsi que des jetons de signature d’accès partagé. Pour obtenir des exemples de signatures d’accès partagé, consultez Sauvegarde SQL Server vers une URL et Simplifying creation of SQL Credentials with Shared Access Signature (SAS) tokens on Azure Storage with PowerShell.

Une unité de disque n'est pas tenue d'exister pour pouvoir être spécifiée dans une instruction BACKUP. Si l'unité physique existe et si l'option INIT n'est pas spécifiée dans l'instruction BACKUP, la sauvegarde est ajoutée à l'unité.

Notes

L’unité NUL va supprimer toutes les entrées envoyées à ce fichier. Toutefois, la sauvegarde continue de marquer toutes les pages comme étant sauvegardées.

Pour plus d’informations, consultez l’article Unités de sauvegarde.

Notes

L'option TAPE sera supprimée dans une future version de SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité.

n
Espace réservé qui indique que jusqu’à 64 périphériques de sauvegarde peuvent être spécifiés dans une liste séparée par des virgules.

MIRROR TO <backup_device> [ ,...n ]

Spécifie un jeu constitué au maximum de trois unités de sauvegarde, dont chacune est le miroir des unités de sauvegarde spécifiées dans la clause TO. La clause MIRROR TO doit spécifier le même type et le même nombre d’unités de sauvegarde que la clause TO. Vous pouvez spécifier jusqu'à trois clauses MIRROR TO.

Cette option est disponible uniquement dans l'édition Enterprise de SQL Server.

Notes

Pour MIRROR TO = DISK, BACKUP détermine automatiquement la taille de bloc appropriée des unités de disques, en fonction de la taille du secteur. Si le disque MIRROR TO est formaté avec une taille de secteur différente de celle du disque spécifié comme unité de sauvegarde principale, la commande de sauvegarde échoue. Pour mettre en miroir les sauvegardes sur les appareils qui ont des tailles de secteur différentes, le paramètre BLOCKSIZE doit être spécifié et doit être défini sur la taille de secteur la plus élevée parmi tous les appareils cibles. Pour plus d’informations sur la taille de bloc, consultez « BLOCKSIZE » plus loin dans cette rubrique.

<backup_device>
Reportez-vous à « <backup_device> », plus haut dans cette section.

n
Espace réservé qui indique que jusqu’à 64 périphériques de sauvegarde peuvent être spécifiés dans une liste séparée par des virgules. Le nombre d'unités spécifiées dans la clause MIRROR TO doit être égal au nombre d'unités spécifiées dans la clause TO.

Pour plus d’informations, consultez « Familles de supports de sauvegarde miroirs » dans la section Remarques, plus loin dans cet article.

[ next-mirror-to ]
Espace réservé indiquant qu'une instruction BACKUP peut contenir jusqu'à trois clauses MIRROR TO, en plus de la clause TO.

Options WITH

Spécifie les options à utiliser avec une opération de sauvegarde.

CREDENTIAL

S’applique à : SQL Server (à compter de SQL Server 2012 (11.x) SP1 CU2).

Utilisé uniquement lors de la création d’une sauvegarde sur Stockage Blob Azure.

FILE_SNAPSHOT

S’applique à : SQL Server (à compter de SQL Server 2016 (13.x)).

S’utilise pour créer un instantané Azure des fichiers de base de données lorsque tous les fichiers de base de données SQL Server sont stockés à l’aide du Stockage Blob Azure. Pour plus d’informations, consultez Fichiers de données SQL Server dans Microsoft Azure. La sauvegarde d’instantanés SQL Server crée des instantanés Azure des fichiers de base de données (données et fichiers journaux) dont l’état est cohérent. Un ensemble cohérent d’instantanés Azure constitue une sauvegarde, qui est enregistrée dans le fichier de sauvegarde. La seule différence entre BACKUP DATABASE TO URL WITH FILE_SNAPSHOT et BACKUP LOG TO URL WITH FILE_SNAPSHOT est que ce dernier tronque le journal des transactions. Avec la sauvegarde d’instantanés SQL Server, une fois effectuée la sauvegarde complète initiale dont a besoin SQL Server pour établir la chaîne de sauvegarde, seule une sauvegarde de fichier journal est nécessaire pour restaurer une base de données vers le point dans le temps correspondant à la sauvegarde de fichier journal. En outre, seules deux sauvegardes de fichier journal sont nécessaires pour restaurer une base de données vers un point dans le temps situé entre les deux sauvegardes de fichier journal.

DIFFERENTIAL

Utilisé uniquement avec BACKUP DATABASE, ce paramètre spécifie que la sauvegarde de base de données ou de fichier ne doit porter que sur les parties de la base de données ou du fichier qui ont été modifiées depuis la dernière sauvegarde complète. Une sauvegarde différentielle occupe en général moins d'espace qu'une sauvegarde complète. Utilisez cette option de façon à ne pas avoir à appliquer toutes les sauvegardes successives du journal effectuées depuis la dernière sauvegarde complète.

Notes

Par défaut, BACKUP DATABASE crée une sauvegarde complète.

Pour plus d’informations, consultez l’article Sauvegardes différentielles.

ENCRYPTION

Utilisé pour spécifier le chiffrement d'une sauvegarde. Vous pouvez spécifier un algorithme de chiffrement pour chiffrer la sauvegarde ou spécifier NO_ENCRYPTION pour ne pas chiffrer la sauvegarde. Il est recommandé d'utiliser le chiffrement pour sécuriser les fichiers de sauvegarde. Liste des algorithmes possibles :

AES_128
AES_192
AES_256
TRIPLE_DES_3KEY
NO_ENCRYPTION

Si vous choisissez de chiffrer, vous devez également spécifier le chiffreur à l'aide des options de chiffreur :

SERVER CERTIFICATE = Encryptor_Name
SERVER ASYMMETRIC KEY = Encryptor_Name

SERVER CERTIFICATE et SERVER ASYMMETRIC KEY correspondent à un certificat et à une clé asymétrique créés dans une base de données master. Pour plus d’informations, consultez respectivement CREATE CERTIFICATE et CREATE ASYMMETRIC KEY.

Avertissement

Lorsque le chiffrement est utilisé conjointement à l’argument FILE_SNAPSHOT, le fichier de métadonnées est chiffré à l’aide de l’algorithme de chiffrement spécifié, et le système vérifie qu’un chiffrement TDE (Transparent Data Encryption) a été effectué pour la base de données. Aucun autre chiffrement n’est effectué pour les données. La sauvegarde échoue si la base de données n’a pas été chiffrée ou si le chiffrement n’a pas été exécuté avant l’émission de l’instruction BACKUP.

Options du jeu de sauvegarde

Ces options s'appliquent au jeu de sauvegarde qui est créé par cette opération de sauvegarde.

Notes

Pour spécifier un jeu de sauvegarde pour une opération de restauration, utilisez l’option FILE = <backup_set_file_number>. Pour plus d’informations sur la façon de spécifier un jeu de sauvegarde, consultez la section « Spécification d’un jeu de sauvegarde » dans l’article Instructions RESTORE – Arguments.

COPY_ONLY

Spécifie que la sauvegarde est une sauvegarde en copie seule qui n’a aucun impact sur la séquence normale des sauvegardes. Une sauvegarde en copie seule est créée indépendamment de vos sauvegardes régulières standard. Ce type de sauvegarde n'a aucun effet sur les procédures globales de sauvegarde et de restauration de la base de données.

Les sauvegardes en copie seule doivent être utilisées dans les cas où une sauvegarde est effectuée dans un but particulier, par exemple pour sauvegarder le journal avant une restauration de fichiers en ligne. En règle générale, une sauvegarde de fichier journal en copie seule est utilisée une fois, puis supprimée.

Lorsqu’elle est utilisée avec BACKUP DATABASE, l’option COPY_ONLY crée une sauvegarde complète qui ne peut pas servir de base différentielle. La bitmap différentielle n'est pas mise à jour et les sauvegardes différentielles se comportent comme si la sauvegarde en copie seule n'existait pas. Les sauvegardes différentielles ultérieures utilisent la dernière sauvegarde complète standard en tant que base.

Important

Si DIFFERENTIAL et COPY_ONLY sont utilisés ensemble, COPY_ONLY est ignoré, et une sauvegarde différentielle est créée.
Lorsqu’elle est utilisée avec BACKUP LOG, l’option COPY_ONLY crée une sauvegarde de fichier journal en copie seule qui ne tronque pas le journal des transactions. La sauvegarde de journal en copie seule n'a aucun effet sur la séquence de journaux de transactions consécutifs et les autres sauvegardes de journal se comportent comme si la sauvegarde en copie seule n'existait pas.

Pour plus d’informations, consultez l’article Sauvegardes de type copie seule.

[ COMPRESSION [ ALGORITHM = ( { MS_XPRESS | accelerator_algorithm } ) ] | NO_COMPRESSION ]

Spécifie si la compression de la sauvegarde est effectuée sur cette sauvegarde, remplaçant la valeur par défaut au niveau du serveur.

Lors de l'installation, le comportement par défaut exclut toute compression des sauvegardes. Toutefois, ce paramétrage par défaut peut être modifié en définissant l’option de configuration du serveur Compression par défaut des sauvegardes. Pour plus d’informations sur l’affichage de la valeur actuelle de cette option, consultez l’article Afficher ou modifier des propriétés de serveur.

Pour plus d’informations sur l’utilisation de la compression de sauvegarde avec des bases de données où Transparent Data Encryption (TDE) est activé, consultez la section Remarques.

COMPRESSION
Active explicitement la compression des sauvegardes.

NO_COMPRESSION
Désactive explicitement la compression des sauvegardes.

SQL Server 2022 (16.x) introduit ALGORITHM, qui identifie un algorithme de compression pour l’opération. Par défaut, il s’agit de MS_XPRESS. Si vous avez configuré l’accélération et le déchargement intégrés, vous pouvez utiliser un accélérateur fourni par la solution. Par exemple, si vous avez configuré Intel® QuickAssist Technology (QAT) pour SQL Server, l’exemple suivant termine la sauvegarde avec la solution accélérateur, avec la bibliothèque QATzip à l’aide QZ_DEFLATE du niveau de compression 1.

BACKUP DATABASE <database_name> TO DISK WITH COMPRESSION (ALGORITHM = QAT_DEFLATE)

DESCRIPTION = { 'text' | @text_variable }

Spécifie le texte de format libre servant à décrire le jeu de sauvegarde. La chaîne peut compter jusqu'à 255 caractères.

NAME = { backup_set_name | @backup_set_var }

Spécifie le nom du jeu de sauvegarde. Les noms peuvent contenir jusqu'à 128 caractères. Si l'option NAME n'est pas spécifiée, le nom reste vide.

{ EXPIREDATE ='date' | RETAINDAYS = days }

Spécifie la date à laquelle le jeu de sauvegarde de cette sauvegarde peut être écrasé. Si ces options sont toutes les deux utilisées, RETAINDAYS l'emporte sur EXPIREDATE.

Si aucune de ces options n’est spécifiée, la date d’expiration est déterminée par le paramètre de configuration media retention. Pour plus d’informations, consultez l’article Options de configuration du serveur.

Important

Ces options empêchent seulement SQL Server d'écraser un fichier. Le contenu des bandes peut être écrasé par d'autres méthodes, et les fichiers sur disque peuvent être supprimés à partir du système d'exploitation. Pour plus d'informations sur le contrôle du délai d'expiration, consultez SKIP et FORMAT dans cette rubrique.

EXPIREDATE = { 'date' | @date_var }
Indique la date à laquelle le jeu de sauvegarde expire et peut par conséquent être écrasé. Fournie comme variable (@date_var), cette date doit suivre le format datetime configuré par le système et prendre l’une des formes suivantes :

Constante de chaîne (@date_var = date)
Une variable de type chaîne de caractères (à l’exception des types de données ntext ou text)
Un smalldatetime
Une variable datetime

Par exemple :

'Dec 31, 2020 11:59 PM'
'1/1/2021'

Pour plus d’informations sur la spécification des valeurs datetime, consultez Types Date et Time.

Notes

Pour ignorer la date d’expiration, utilisez l’option SKIP.

RETAINDAYS = { days | @days_var }
Indique le nombre de jours qui doivent s'écouler avant de pouvoir remplacer le support de sauvegarde. Fournie comme variable (@days_var), cette valeur doit être un entier.

{ METADATA_ONLY | SNAPSHOT }

S’applique à : SQL Server 2022 (16.x)

METADATA_ONLY et SNAPSHOT sont des synonymes.

Options du support de sauvegarde

Ces options s'appliquent à l'ensemble du support de sauvegarde.

{ NOINIT | INIT }

Détermine si l'opération de sauvegarde ajoute les nouvelles sauvegardes ou si elle remplace les jeux de sauvegardes déjà présents sur le support de sauvegarde. La valeur par défaut (NOINIT) consiste à ajouter les nouvelles sauvegardes après le jeu de sauvegarde le plus récent sur le support.

Notes

Pour plus d’informations sur les interactions entre les options { NOINIT | INIT } et { NOSKIP | SKIP }, reportez-vous à la section Remarques, plus loin dans cette rubrique.

NOINIT
Indique que le jeu de sauvegarde est ajouté au support de sauvegarde spécifié, préservant ainsi les jeux de sauvegardes existants. Si un mot de passe de support est défini pour le support de sauvegarde, il doit être fourni. NOINIT est la valeur par défaut.

Pour plus d’informations, consultez l’article Jeux de supports, familles de supports et jeux de sauvegarde.

INIT
Indique que tous les jeux de sauvegardes doivent être écrasés mais préserve l'en-tête de support. Si INIT est spécifié, tous les jeux de sauvegardes qui se trouvent sur l'unité concernée sont écrasés si les conditions l'autorisent. Par défaut, BACKUP vérifie les conditions ci-après et n'écrase pas le support de sauvegarde si l'une des conditions est vraie :

Un jeu de sauvegarde n'a pas encore expiré. Pour plus d’informations, consultez les options EXPIREDATE et RETAINDAYS.
Le nom du jeu de sauvegarde donné dans l'instruction BACKUP, s'il est fourni, ne correspond pas à celui du support de sauvegarde. Pour plus d'informations, consultez l'option NAME, plus haut dans cette section.

Pour ignorer ces vérifications, utilisez l’option SKIP.

Pour plus d’informations, consultez l’article Jeux de supports, familles de supports et jeux de sauvegarde.

{ NOSKIP | SKIP }

Détermine si une opération de sauvegarde vérifie la date et l'heure d'expiration des jeux de sauvegardes figurant sur le support avant de les écraser.

Notes

Pour plus d’informations sur les interactions entre les options { NOINIT | INIT } et { NOSKIP | SKIP }, reportez-vous à la section « Remarques », plus loin dans cette rubrique.

NOSKIP
Ordonne à l'instruction BACKUP de vérifier la date d'expiration de tous les jeux de sauvegardes qui se trouvent sur le support, avant d'autoriser leur écrasement. Il s'agit du comportement par défaut.

SKIP
Désactive le contrôle de la date d'expiration et du nom qui est habituellement effectué par l'instruction BACKUP pour prévenir un écrasement des jeux de sauvegardes. Pour plus d’informations sur les interactions entre les options { INIT | NOINIT } et { NOSKIP | SKIP }, consultez la section « Remarques », plus loin dans cet article. Pour afficher les dates d’expiration des jeux de sauvegardes, interrogez la colonne expiration_date de la table d’historique backupset.

{ NOFORMAT | FORMAT }

Spécifie si l'en-tête de support doit être écrit sur les volumes utilisés pour cette opération de sauvegarde, en écrasant l'en-tête de support et les jeux de sauvegardes existants.

NOFORMAT
Spécifie que l'opération de sauvegarde conserve l'en-tête de support et les jeux de sauvegardes existants sur les volumes de support utilisés pour cette opération de sauvegarde. Il s'agit du comportement par défaut.

FORMAT
Indique qu'un nouveau support de sauvegarde est créé. Si FORMAT est utilisé, l'opération de sauvegarde écrit un nouvel en-tête de support sur tous les volumes utilisés pour cette opération de sauvegarde. Le contenu précédent du volume devient non valide étant donné que l'en-tête de support et les jeux de sauvegardes existants sont écrasés.

Important

Soyez prudent lorsque vous utilisez FORMAT. Si vous formatez l'un des volumes d'un support de sauvegarde, la totalité du support de sauvegarde devient inutilisable. Par exemple, si une bande appartenant à un support de sauvegarde distribuée existant est initialisée, tout le support de sauvegarde devient inutilisable.

La spécification de FORMAT implique SKIP. SKIP n’a pas besoin d’être explicitement spécifié.

MEDIADESCRIPTION = { text | @text_variable }

Indique le texte de description de format libre du support de sauvegarde (maximum 255 caractères).

MEDIANAME = { media_name | @media_name_variable }

Fournit le nom du support de sauvegarde complet. Le nom du support ne doit pas dépasser 128 caractères. Si MEDIANAME est spécifié, il doit correspondre au nom spécifié précédemment existant sur les volumes de sauvegarde. Si elle n'est pas spécifiée, ou si l'option SKIP l'est, aucune vérification du nom de support n'est effectuée.

BLOCKSIZE = { blocksize | @blocksize_variable }

Indique, en octets, la taille physique du bloc. Les tailles prises en charge sont 512, 1024, 2048, 4096, 8192, 16384, 32768 et 65536 (64 Ko) octets. La valeur par défaut est 65536 pour les périphériques à bandes, 512 sinon. En règle générale, cette option est superflue car BACKUP sélectionne automatiquement une taille de bloc appropriée pour le périphérique. Si vous spécifiez explicitement une taille de bloc, la sélection automatique est annulée et remplacée.

Si vous effectuez une sauvegarde que vous envisagez de copier sur un CD-ROM pour la restaurer à partir de celui-ci, spécifiez BLOCKSIZE=2048.

Notes

En règle générale, cette option n'affecte les performances que si les données sont écrites sur des périphériques à bandes.

Options de transfert de données

BUFFERCOUNT = { buffercount | @buffercount_variable }

Spécifie le nombre total de tampons d'E/S à utiliser pour l'opération de sauvegarde. Vous pouvez spécifier n'importe quel entier positif ; toutefois, un nombre élevé de tampons peut provoquer des erreurs liées à une insuffisance de mémoire. En effet, l'espace d'adressage virtuel peut s'avérer inapproprié dans la tâche Sqlservr.exe.

L’espace total utilisé par les mémoires tampons est déterminé par : BUFFERCOUNT * MAXTRANSFERSIZE.

Notes

Pour des informations importantes sur l’utilisation de l’option BUFFERCOUNT, consultez le blog Incorrect BufferCount data transfer option can lead to OOM condition.

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

Spécifie, en octets, la plus grande unité de transfert à utiliser entre SQL Server et le support de sauvegarde. Les valeurs possibles sont les multiples de 65536 octets (64 Ko), dans la limite de 4194304 octets (4 Mo).

Lors de la création de sauvegardes à l’aide du service SQL Writer, si la base de données est configurée avec FILESTREAM, ou si elle comprend des groupes de fichiers à mémoire optimisée, la valeur de MAXTRANSFERSIZE au moment de la restauration doit être supérieure ou égale à celle du MAXTRANSFERSIZE qui a été utilisée lors de la création de la sauvegarde.

Pour les bases de données comprenant un seul fichier de données et où Transparent Data Encryption (TDE) est activé, la valeur MAXTRANSFERSIZE par défaut est 65 536 (64 Ko). Pour les bases de données non chiffrées à l’aide de TDE, la valeur par défaut MAXTRANSFERSIZE est 1048576 (1 Mo) lors d’une sauvegarde vers DISK, et 65536 (64 Ko) lors d’une sauvegarde vers VDI ou TAPE. Pour plus d’informations sur l’utilisation de la compression de sauvegarde avec des bases de données chiffrées avec TDE, consultez la section Remarques.

Options de gestion des erreurs

Ces options vous permettent de déterminer si les sommes de contrôle de sauvegarde sont activées pour l’opération de sauvegarde, et si l’opération doit s’arrêter en présence d’une erreur.

{ NO_CHECKSUM | CHECKSUM }

Détermine si les sommes de contrôle de sauvegarde sont activées.

NO_CHECKSUM
Désactive explicitement la génération de sommes de contrôle de sauvegarde (et la validation des sommes de contrôle de page). Il s'agit du comportement par défaut.

CHECKSUM
Indique que l’opération de sauvegarde vérifie dans chaque page les informations de somme de contrôle et de page endommagée, si elles sont activées et disponibles, et génère une somme de contrôle pour l’ensemble de la sauvegarde.

L’utilisation des sommes de contrôle de sauvegarde peut affecter la charge de travail et le débit de sauvegarde.

Pour plus d’informations, consultez l’article Erreurs de support possibles pendant les opérations de sauvegarde et de restauration.

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

Détermine si une opération de sauvegarde s'arrête ou continue après avoir rencontré une erreur de somme de contrôle de page.

STOP_ON_ERROR
Ordonne à BACKUP de s'arrêter si une somme de contrôle de page n'est pas validée. Il s'agit du comportement par défaut.

CONTINUE_AFTER_ERROR
Ordonne à BACKUP de continuer en dépit des erreurs rencontrées, telles que des sommes de contrôle de page non valides ou des pages endommagées.

Si vous ne parvenez pas à effectuer une sauvegarde de la fin du journal à l’aide de l’option NO_TRUNCATE lorsque la base de données est endommagée, vous pouvez essayer d’effectuer une sauvegarde de la fin du journal en spécifiant CONTINUE_AFTER_ERROR au lieu de NO_TRUNCATE.

Pour plus d’informations, consultez l’article Erreurs de support possibles pendant les opérations de sauvegarde et de restauration.

Options de compatibilité

RESTART

À compter de SQL Server 2008 (10.0.x), n’a aucun effet. Elle est acceptée par cette version à des fins de compatibilité avec les versions antérieures de SQL Server.

Options de surveillance

STATS [ = pourcentage ]

Affiche un message à chaque fois qu’un autre pourcentage se termine et sert à évaluer l’état d’avancement de l’opération. Si percentage est omis, SQL Server affiche un message à chaque incrément de 10 pour cent.

L'option STATS signale le pourcentage terminé comme seuil de rapport de l'intervalle suivant. C'est-à-dire approximativement le pourcentage spécifié ; par exemple, si STATS=10, et si le pourcentage terminé est 40 pour cent, l'option peut afficher 43 pour cent. Pour les jeux de sauvegardes volumineux, cela n'est pas un problème car le pourcentage terminé varie très lentement entre les appels d'E/S terminés.

Options de bande

Ces options sont utilisées uniquement pour les périphériques À BANDES. S'il ne s'agit pas d'un périphérique à bandes, ces options sont ignorées.

{ REWIND | NOREWIND }

REWIND
Indique que SQL Server libère et rembobine la bande. REWIND est le paramètre par défaut.

NOREWIND
Indique que SQL Server maintient la bande ouverte après l'opération de sauvegarde. Cette option vous permet d'améliorer les performances lorsque vous effectuez plusieurs opérations de sauvegarde sur une bande.

NOREWIND implique NOUNLOAD, et ces options sont incompatibles dans une instruction BACKUP unique.

Notes

Si vous utilisez NOREWIND, l’instance de SQL Server conserve la propriété du lecteur de bande jusqu’à ce qu’une instruction BACKUP ou RESTORE s’exécutant dans le même processus utilise l’option REWIND ou UNLOAD, ou jusqu’à l’arrêt de l’instance du serveur. Le fait de maintenir la bande ouverte empêche les autres processus d'y accéder. Pour savoir comment afficher la liste des bandes ouvertes et comment fermer ces bandes, consultez l’article Unités de sauvegarde.

{ UNLOAD | NOUNLOAD }

Notes

UNLOAD et NOUNLOAD sont des paramètres de session qui sont conservés jusqu’à la fin de la session ou tant qu’ils ne sont pas réinitialisés par la spécification d’une autre option.

UNLOAD
Indique que la bande est automatiquement rembobinée et démontée lorsque la sauvegarde est terminée. UNLOAD est l'option par défaut au démarrage d'une session.

NOUNLOAD
Indique qu’au terme de l’opération BACKUP, la bande reste chargée dans le lecteur de bande.

Notes

Dans le cas d’une sauvegarde sur une unité de sauvegarde sur bande, l’option BLOCKSIZE affecte les performances de l’opération de sauvegarde. En règle générale, cette option n'affecte les performances que si les données sont écrites sur des périphériques à bandes.

Options spécifiques au journal

Ces options ne sont utilisées qu’avec BACKUP LOG.

Notes

Si vous ne voulez pas effectuer de sauvegarde du journal, utilisez le mode de récupération simple. Pour plus d’informations, voir Modes de récupération.

{ NORECOVERY | STANDBY = undo_file_name }

NORECOVERY
Effectue une sauvegarde de la fin du journal et laisse la base de données en état de restauration (RESTORING). NORECOVERY s'avère utile lors du basculement vers une base de données secondaire ou de l'exécution d'une sauvegarde de la fin du journal avant une opération RESTORE.

Pour effectuer au mieux une sauvegarde du journal qui évite la troncation du journal et place la base de données en état RESTORING de manière atomique, utilisez conjointement les options NO_TRUNCATE et NORECOVERY.

STANDBY = standby_file_name
Effectue une sauvegarde de la fin du journal et laisse la base de données en lecture seule et en état STANDBY. La clause STANDBY écrit les données en attente (annulation avec option de restauration ultérieure). L'option STANDBY est semblable à BACKUP LOG WITH NORECOVERY suivie par RESTORE WITH STANDBY.

Le mode d’attente nécessite un fichier d’annulation, spécifié par standby_file_name, dont l’emplacement figure dans le journal de la base de données. Si le fichier spécifié existe déjà, le Moteur de base de données l'écrase ; sinon, le Moteur de base de données le crée. Le fichier d'annulation devient partie intégrante de la base de données.

Ce fichier contient les modifications annulées, qui doivent être restaurées si des opérations RESTORE LOG sont effectuées ultérieurement. Vous devez disposer d'un espace disque suffisant pour que le fichier d'annulation puisse contenir toutes les pages distinctes de la base de données qui ont été modifiées par suite du rejet des transactions non validées.

NO_TRUNCATE

Indique que le journal des transactions ne doit pas être tronqué et que le Moteur de base de données tente la sauvegarde quel que soit l’état de la base de données. Par conséquent, les métadonnées d’une sauvegarde effectuée avec NO_TRUNCATE peuvent être incomplètes. Cette option permet de sauvegarder le journal des transactions lorsque la base de données est endommagée.

L'option NO_TRUNCATE de BACKUP LOG revient à spécifier COPY_ONLY et CONTINUE_AFTER_ERROR.

Sans l’option NO_TRUNCATE, l’état de la base de données doit avoir la valeur ONLINE. Si l’état de la base de données a la valeur SUSPENDED, vous pouvez créer une sauvegarde en spécifiant NO_TRUNCATE. Toutefois, si l’état de la base de données a la valeur OFFLINE ou EMERGENCY, l’option BACKUP n’est pas autorisée même avec l’option NO_TRUNCATE. Pour plus d’informations sur les états de base de données, consultez États d’une base de données.

À propos de l’utilisation des sauvegardes SQL Server

Cette section présente les concepts de sauvegarde essentiels suivants :

Types de sauvegarde Troncation du journal des transactions Formatage du support de sauvegarde Utilisation des unités de sauvegarde et des supports de sauvegarde Restauration de sauvegardes SQL Server

Notes

Pour découvrir une présentation de la sauvegarde dans SQL Server, consultez l’article Vue d’ensemble de la sauvegarde.

Types de sauvegarde

Les types de sauvegarde pris en charge dépendent du mode de récupération de la base de données conformément à ce qui suit :

Tous les modes de récupération prennent en charge les sauvegardes de données complètes et différentielles.

Étendue de la sauvegarde	Types de sauvegarde
Base de données entière	Les sauvegardes de base de données couvrent l’ensemble de la base de données. Chaque sauvegarde de base de données peut éventuellement servir de base pour une série d’une ou de plusieurs sauvegardes de bases de données différentielles.
Base de données partielle	Les sauvegardes partiellescouvrent les groupes de fichiers en lecture/écriture et, éventuellement, un ou plusieurs fichiers ou groupes de fichiers en lecture seule. Chaque sauvegarde partielle peut éventuellement servir de base pour une série d’une ou de plusieurs sauvegardes partielles différentielles.
Fichier ou groupe de fichiers	Les sauvegardes de fichiers couvrent un ou plusieurs fichiers ou groupes de fichiers et ne conviennent qu’aux bases de données contenant plusieurs groupes de fichiers. En mode de récupération simple, les sauvegardes de fichiers se limitent essentiellement aux groupes de fichiers secondaires en lecture seule. Chaque sauvegarde de fichiers peut éventuellement servir de base pour une série d’une ou de plusieurs sauvegardes de fichiers différentielles.

En mode de récupération complète ou en mode de récupération utilisant les journaux de transactions, les sauvegardes standard incluent également les sauvegardes des journaux de transactions (ou sauvegardes de fichier journal) séquentielles qui sont nécessaires. Chaque sauvegarde de fichier journal couvre la partie du journal des transactions qui est active au moment de la création de la sauvegarde et inclut tous les enregistrements de journal qui n'ont pas été sauvegardés lors d'une précédente sauvegarde de journal.

Pour réduire au maximum les risques de perte de travail, mais avec un coût en termes de charge d'administration, vous devez planifier des sauvegardes de fichier journal fréquentes. La planification de sauvegardes différentielles entre des sauvegardes complètes peut réduire le temps de restauration en diminuant le nombre de sauvegardes de fichier journal à restaurer après la restauration des données.

Nous vous recommandons de placer les sauvegardes de fichier journal sur un autre volume que les sauvegardes de base de données.

Notes

Avant de pouvoir créer la première sauvegarde du fichier journal, vous devez créer une sauvegarde complète.
Une sauvegarde en copie seule est une sauvegarde complète ou une sauvegarde de fichier journal qui est réalisée dans un but précis, et qui est indépendante de la séquence normale des sauvegardes standard. Pour créer une sauvegarde en copie seule, spécifiez l'option COPY_ONLY dans votre instruction BACKUP. Pour plus d’informations, consultez l’article Sauvegardes de type copie seule.

Troncation du journal des transactions

Pour éviter de remplir le journal des transactions d'une base de données, les sauvegardes régulières sont essentielles. En mode de récupération simple, la troncation du journal se produit automatiquement après la sauvegarde de la base de données ; en mode de récupération complète, elle se produit automatiquement après la sauvegarde du journal des transactions. Toutefois, le processus de troncation peut parfois être différé. Pour plus d’informations sur les facteurs susceptibles de retarder la troncation du journal, consultez l’article Journal des transactions.

Notes

Les options BACKUP LOG WITH NO_LOG et WITH TRUNCATE_ONLY ne sont plus disponibles. Si vous utilisez le mode de récupération complète ou le mode de récupération utilisant les journaux de transactions et si vous devez supprimer la chaîne de sauvegarde de fichier journal d'une base de données, passez au mode de récupération simple. Pour plus d’informations, consultez l’article Afficher ou modifier le mode de récupération d’une base de données.

Mise en forme du support de sauvegarde

Le support de sauvegarde est formaté par une instruction BACKUP si, et uniquement si, l'une des conditions suivantes est vraie :

L’option FORMAT est spécifiée.
Le support est vide.
L'opération écrit sur une bande magnétique de sauvegarde consécutive.

Utiliser des périphériques de sauvegarde et des jeux multimédias

Unités de sauvegarde d’un jeu de sauvegarde distribuée (jeu de bandes)

Un jeu de bandes est un ensemble de fichiers disque sur lesquels les données sont divisées en blocs et distribuées dans un ordre fixe. Le nombre d’unités de sauvegarde utilisées dans un jeu de bandes doit rester le même (sauf si le support est réinitialisé avecFORMAT).

L'exemple ci-dessous écrit une sauvegarde de la base de données AdventureWorks2022 sur un nouveau jeu de sauvegarde distribuée qui utilise trois fichiers disque.

BACKUP DATABASE AdventureWorks2022
TO DISK = 'X:\SQLServerBackups\AdventureWorks1.bak',
DISK = 'Y:\SQLServerBackups\AdventureWorks2.bak',
DISK = 'Z:\SQLServerBackups\AdventureWorks3.bak'
WITH FORMAT,
  MEDIANAME = 'AdventureWorksStripedSet0',
  MEDIADESCRIPTION = 'Striped media set for AdventureWorks2022 database';
GO

Lorsqu'une unité de sauvegarde a été définie comme faisant partie d'un jeu de bandes, elle ne peut plus être utilisée pour une sauvegarde d'unité unique, sauf si l'option FORMAT est spécifiée. De la même façon, une unité qui contient des sauvegardes non agrégées ne peut pas être utilisée dans un jeu d'agrégats, sauf si l'option FORMAT est spécifiée. Pour diviser un jeu de sauvegarde par bandes, utilisez l'option FORMAT.

Si ni MEDIANAME ni MEDIADESCRIPTION n’est spécifié lorsqu’un en-tête de support est écrit, le champ d’en-tête de support correspondant à l’élément non spécifié est vide.

Utiliser un support en miroir

En règle générale, les sauvegardes ne sont pas mises en miroir et les instructions BACKUP contiennent simplement une clause TO. Toutefois, il est possible de créer jusqu'à quatre miroirs par support de sauvegarde. Dans le cas d'un support de sauvegarde miroir, l'opération de sauvegarde écrit dans plusieurs groupes d'unités de sauvegarde. Chaque groupe d'unités de sauvegarde constitue un miroir au sein du support de sauvegarde miroir. Chaque miroir doit utiliser le même nombre et le même type d'unités de sauvegarde physiques, lesquelles doivent toutes avoir les mêmes propriétés.

Pour effectuer une sauvegarde dans un support de sauvegarde miroir, tous les miroirs doivent être présents. Pour effectuer une sauvegarde sur un support de sauvegarde miroir, spécifiez la clause TO pour le premier miroir et spécifiez une clause MIRROR TO pour chacun des autres miroirs.

Pour un support de sauvegarde miroir, chaque clause MIRROR TO doit contenir le même nombre et le même type d’unités que la clause TO. L'exemple suivant écrit dans un support de sauvegarde miroir contenant deux miroirs et utilisant trois unités par miroir :

BACKUP DATABASE AdventureWorks2022
TO DISK = 'X:\SQLServerBackups\AdventureWorks1a.bak',
  DISK = 'Y:\SQLServerBackups\AdventureWorks2a.bak',
  DISK = 'Z:\SQLServerBackups\AdventureWorks3a.bak'
MIRROR TO DISK='X:\SQLServerBackups\AdventureWorks1b.bak',
  DISK = 'Y:\SQLServerBackups\AdventureWorks2b.bak',
  DISK = 'Z:\SQLServerBackups\AdventureWorks3b.bak';
GO

Important

Cet exemple vous permet d'effectuer un test sur votre système local. En pratique, effectuer une sauvegarde dans plusieurs unités se trouvant sur le même lecteur nuit aux performances et élimine la redondance pour laquelle les supports de sauvegarde miroirs sont conçus.

Familles de supports de sauvegarde miroirs

Chaque unité de sauvegarde spécifiée dans la clause TO d’une instruction BACKUP correspond à une famille de supports. Par exemple, si la clause TO répertorie trois unités, BACKUP écrit des données dans trois familles de supports. Dans un support de sauvegarde miroir, chaque miroir doit contenir une copie de chacune des familles de supports. C'est pour cette raison que le nombre d'unités doit être identique pour tous les miroirs.

Si plusieurs unités sont spécifiées pour chaque miroir, leur ordre détermine la famille de supports qui est écrite sur chacune d'elles. Par exemple, dans chaque liste d'unités, la deuxième unité correspond à la deuxième famille de supports. Le tableau suivant établit la correspondance entre unités et familles de supports pour les unités de l'exemple ci-dessus.

Miroir	Famille de supports 1	Famille de supports 2	Famille de supports 3
0	`Z:\AdventureWorks1a.bak`	`Z:\AdventureWorks2a.bak`	`Z:\AdventureWorks3a.bak`
1	`Z:\AdventureWorks1b.bak`	`Z:\AdventureWorks2b.bak`	`Z:\AdventureWorks3b.bak`

Une famille de supports doit toujours être sauvegardée sur la même unité à l'intérieur d'un miroir donné. Par conséquent, à chaque fois que vous utilisez un support de sauvegarde existant, répertoriez les unités de chaque miroir dans l'ordre dans lequel elles ont été spécifiées au moment de la création du support de sauvegarde.

Pour plus d’informations sur les jeux multimédias mis en miroir, consultez jeux de supports de sauvegarde en miroir. Pour plus d’informations sur les jeux multimédias et les familles multimédias en général, consultez Jeux multimédias, familles de supports et jeux de sauvegarde.

Restaurer des sauvegardes SQL Server

Pour restaurer une base de données et, éventuellement, la récupérer pour la mettre en ligne, ou pour restaurer un fichier ou un groupe de fichiers, utilisez l’instruction Transact-SQL RESTORE ou les tâches SQL Server Management Studio de restauration. Pour plus d’informations, consultez Vue d’ensemble de la restauration et de la récupération.

Considérations supplémentaires à propos des options BACKUP

Interactions de SKIP, NOSKIP, INIT et NOINIT

Ce tableau décrit les interactions entre les options { NOINIT | INIT } et { NOSKIP | SKIP }.

Notes

Si le support de bande est vide ou que le fichier de sauvegarde sur disque n'existe pas, toutes ces interactions écrivent un en-tête de support, puis se poursuivent. Si le support n'est pas vide et qu'il ne contient pas d'en-tête de support valide, ces opérations signalent qu'il ne s'agit pas d'un support MTF valide et mettent fin à l'opération de sauvegarde.

Option Skip	NOINIT	INIT
NOSKIP	Si le volume contient un en-tête de support valide, vérifie que le nom du support correspond à la valeur de `MEDIANAME`, si elle est spécifiée. Si les deux noms correspondent, ajoute le jeu de sauvegarde en gardant ceux qui existent déjà. Si le volume ne contient pas d'en-tête de support valide, une erreur se produit.	Si le volume contient un en-tête de support valide, effectue les vérifications suivantes : Si `MEDIANAME` a été spécifié, vérifie que le nom indiqué correspond à celui qui est mentionné dans l’en-tête du support.¹ Vérifie qu'il n'y a pas déjà sur le support des jeux de sauvegardes qui ne seraient pas encore arrivés à expiration. S'il y en a, met fin à la sauvegarde. Si toutes ces vérifications sont validées, écrase tous les jeux de sauvegardes présents sur le support en ne conservant que l'en-tête de support. Si le volume ne contient pas d’en-tête de support valide, en génère un en utilisant les valeurs de `MEDIANAME` et `MEDIADESCRIPTION`, si elles sont spécifiées.
SKIP	Si le volume contient un en-tête de support valide, ajoute le jeu de sauvegarde, en gardant ceux qui existent déjà.	Si le volume contient un en-tête de support valide², écrase tous les jeux de sauvegardes présents sur le support en ne gardant que l’en-tête. Si le support est vide, génère un en-tête de support en utilisant les valeurs de `MEDIANAME` et `MEDIADESCRIPTION`, si elles sont spécifiées.

¹ L’utilisateur doit avoir le rôle serveur ou le rôle de base de données fixe approprié pour effectuer une opération de sauvegarde.

² Pour être valide, il doit faire état du numéro de version MTF et d’autres informations d’en-tête. Si la version indiquée n'est pas prise en charge ou pas reconnue, une erreur se produit.

Compatibilité

Attention

Les sauvegardes créées avec une version plus récente de SQL Server ne peuvent pas être restaurées dans les versions antérieures de SQL Server.

BACKUP prend en charge l’option RESTART de compatibilité descendante avec les versions antérieures de SQL Server. Mais RESTART est inopérant.

Notes

Les sauvegardes de base de données ou de fichier journal peuvent être ajoutées à n'importe quel périphérique de disque ou à bandes, ce qui permet de conserver au même emplacement physique la base de données et ses journaux de transactions.

L'instruction BACKUP n'est pas autorisée dans une transaction explicite ou implicite.

Vous ne pouvez pas sauvegarder une base de données dans les états suivants :

Restauration
Standby (Réserve)
Lecture seule

Les opérations de sauvegarde inter-plateformes, impliquant éventuellement des types de processeurs différents, peuvent être réalisées tant que le classement de la base de données est pris en charge par le système d'exploitation.

Avec SQL Server 2016 (13.x) et versions ultérieures, définir MAXTRANSFERSIZE sur une valeur supérieure à 65536 (64 Ko) permet d’utiliser un algorithme de compression optimisé pour les bases de données chiffrées avec Transparent Data Encryption (TDE), qui chiffre d’abord une page, la compresse, puis la chiffre de nouveau. Si MAXTRANSFERSIZE n’est pas spécifiée, ou si MAXTRANSFERSIZE = 65536 (64 Ko) est utilisé, la compression de sauvegarde pour les bases de données chiffrées avec TDE compresse directement les pages chiffrées et peut ne pas fournir de bons taux de compression. Pour plus d’informations, consultez Backup Compression for TDE-enabled Databases.

À partir de SQL Server 2019 (15.x) CU5, la définition de MAXTRANSFERSIZE n’est plus nécessaire pour activer cet algorithme de compression optimisé avec TDE. Si la commande de sauvegarde est spécifiée WITH COMPRESSION ou que la configuration serveur de compression par défaut des sauvegardes est définie sur 1, la valeur MAXTRANSFERSIZE est automatiquement augmentée à 128 Ko pour activer l’algorithme optimisé. Si MAXTRANSFERSIZE elle est spécifiée sur la commande de sauvegarde avec une valeur > 64 K, la valeur fournie est respectée. En d’autres termes, SQL Server ne diminue jamais automatiquement la valeur, mais l’augmente uniquement. Si vous avez besoin de sauvegarder une base de données chiffrée TDE avec MAXTRANSFERSIZE = 65536, vous devez spécifier WITH NO_COMPRESSION ou vous assurer que la configuration serveur de compression par défaut des sauvegardes est définie sur 0.

Notes

Dans certains cas, la valeur par défaut MAXTRANSFERSIZE est supérieure à 64 Ko :

Quand plusieurs fichiers de données sont créés pour la base de données, celle-ci utilise MAXTRANSFERSIZE> 64 Ko.
Lors de la sauvegarde sur URL dans le Stockage Blob Azure, la valeur par défaut MAXTRANSFERSIZE = 1048576 (1 Mo).
Lors de l’exécution d’une sauvegarde vers une URL vers le stockage d’objets compatible avec S3, la valeur par défaut MAXTRANSFERSIZE = 10485760 (10 Mo).

Même si une de ces conditions s’applique, vous devez définir explicitement MAXTRANSFERSIZE sur une valeur supérieure à 64 Ko dans votre commande de sauvegarde afin d’obtenir l’algorithme de compression de sauvegarde optimisé, sauf si vous êtes sur SQL Server 2019 (15.x) CU5 ou version ultérieure.

Par défaut, chaque opération de sauvegarde réussie ajoute une entrée au journal des erreurs SQL Server et au journal des événements système. Si vous sauvegardez très fréquemment le journal, ces messages de réussite s’accumulent rapidement, ce qui crée des journaux d’erreurs volumineux et complique la recherche d’autres messages. Dans ce cas, vous pouvez supprimer ces entrées de journal en utilisant l’indicateur de trace 3226 si ni votre automatisation ni votre monitoring ne dépend de ces entrées. Pour plus d’informations, consultez l’article Indicateurs de trace.

Interopérabilité

SQL Server utilise un processus de sauvegarde en ligne pour permettre qu’une base de données soit sauvegardée alors qu’elle est encore utilisée. Lors d'une sauvegarde, la plupart des opérations sont possibles ; par exemple, les instructions INSERT, UPDATE et DELETE sont autorisées.

Parmi les opérations qui ne peuvent pas être effectuées lors d'une sauvegarde de base de données ou du journal des transactions, citons :

Les opérations de gestion de fichiers telles que l’instruction ALTER DATABASE avec les options ADD FILE ou REMOVE FILE.
Les opérations de compactage de base de données ou de fichier. Cela comprend également les opérations de compactage automatique.

Si une opération de sauvegarde se chevauche avec une gestion de fichiers ou DBCC SHRINK une opération, un conflit se produit. Quelle que soit l'opération effectuée la première, la seconde opération attend que le verrou défini par la première opération expire (le délai d'expiration est contrôlé par un paramètre d'expiration de la session). Si le verrou est libéré au cours du délai d'expiration, la seconde opération se poursuit. Si le verrou expire, la seconde opération échoue.

Métadonnées

SQL Server intègre les tables d'historique de sauvegarde suivantes pour assurer le suivi des activités de sauvegarde :

Si une restauration est effectuée et si le jeu de sauvegarde n’est pas encore enregistré dans la base de données msdb, les tables d’historique de sauvegarde peuvent être modifiées.

Sécurité

À compter de SQL Server 2012 (11.x), les options PASSWORD et MEDIAPASSWORD ne sont plus disponibles pour la création de sauvegardes. Il est encore possible de restaurer des sauvegardes créées avec des mots de passe.

Autorisations

Les autorisations BACKUP DATABASE et BACKUP LOG reviennent par défaut aux membres du rôle serveur fixe sysadmin et des rôles de base de données fixes db_owner et db_backupoperator.

Des problèmes de propriété et d'autorisations sur le fichier physique de l'unité de sauvegarde sont susceptibles de perturber une opération de sauvegarde. Assurez-vous que le compte de démarrage SQL Server dispose des autorisations en lecture et en écriture sur l’unité de sauvegarde et le dossier où les fichiers de sauvegarde sont écrits. Toutefois, sp_addumpdevice, qui ajoute une entrée pour une unité de sauvegarde dans les tables système, ne vérifie pas les autorisations d’accès au fichier. De tels problèmes sur le fichier physique du dispositif de sauvegarde peuvent ne pas apparaître jusqu'à ce que la ressource physique soit accédée lors de la tentative de sauvegarde ou de restauration.

Exemples

Cette section contient les exemples suivants :

A. Sauvegarder une base de données complète
B. Sauvegarder la base de données et le journal
C. Créer une sauvegarde complète des fichiers des groupes de fichiers secondaires
D. Créer une sauvegarde différentielle de fichiers des groupes de fichiers secondaires
E. Créer et sauvegarder sur un support en miroir à famille unique
F. Créer et sauvegarder sur un support multifamiliale mis en miroir
G. Sauvegarder sur un support en miroir existant
H. Créer une sauvegarde compressée dans un nouvel ensemble multimédia
I. Sauvegarder sur Stockage Blob Azure
J. [Sauvegarder dans le stockage d’objets compatible avec S3] ((#j-sauvegarde-à-s3-compatible-object-storage)
K. Suivi de la progression de l’instruction de sauvegarde

Notes

Les rubriques de procédures de sauvegarde contiennent des exemples supplémentaires. Pour plus d’informations, consultez l’article Vue d’ensemble de la sauvegarde.

A. Sauvegarder une base de données complète

L’exemple ci-dessous sauvegarde la base de données AdventureWorks2022 dans un fichier disque.

BACKUP DATABASE AdventureWorks2022
 TO DISK = 'Z:\SQLServerBackups\AdvWorksData.bak'
    WITH FORMAT;
GO

B. Sauvegarder la base de données et le journal

L'exemple suivant sauvegarde l'exemple de base de données AdventureWorks2022 qui utilise par défaut le mode de récupération simple. Pour prendre en charge les sauvegardes de fichier journal, la base de données AdventureWorks2022 est modifiée pour utiliser le mode de récupération complète.

Ensuite, l’exemple utilise sp_addumpdevice pour créer une unité de sauvegarde logique où sauvegarder les données (AdvWorksData), puis crée une autre unité de sauvegarde logique où sauvegarder le journal (AdvWorksLog).

Enfin, l'exemple crée une sauvegarde complète de la base de données dans AdvWorksData et, après la mise à jour, sauvegarde le journal dans AdvWorksLog.

-- To permit log backups, before the full database backup, modify the database
-- to use the full recovery model.
USE master;
GO
ALTER DATABASE AdventureWorks2022
    SET RECOVERY FULL;
GO
-- Create AdvWorksData and AdvWorksLog logical backup devices.
USE master
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksData',
'Z:\SQLServerBackups\AdvWorksData.bak';
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksLog',
'X:\SQLServerBackups\AdvWorksLog.bak';
GO

-- Back up the full AdventureWorks2022 database.
BACKUP DATABASE AdventureWorks2022 TO AdvWorksData;
GO
-- Back up the AdventureWorks2022 log.
BACKUP LOG AdventureWorks2022
    TO AdvWorksLog;
GO

Notes

Pour une base de données de production, sauvegardez régulièrement le journal. Les sauvegardes du journal doivent être suffisamment fréquentes pour assurer une protection contre la perte des données.

C. Créer une sauvegarde de fichiers complète des groupes de fichiers secondaires

L'exemple suivant crée une sauvegarde complète de tous les fichiers se trouvant dans les deux groupes de fichiers secondaires.

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
    FILEGROUP = 'SalesGroup1',
    FILEGROUP = 'SalesGroup2'
    TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck';
GO

D. Créer une sauvegarde de fichiers différentielle des groupes de fichiers secondaires

L'exemple suivant crée une sauvegarde différentielle de tous les fichiers se trouvant dans les deux groupes de fichiers secondaires.

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
    FILEGROUP = 'SalesGroup1',
    FILEGROUP = 'SalesGroup2'
    TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
    WITH
      DIFFERENTIAL;
GO

E. Créer et sauvegarder sur un support en miroir à famille unique

L'exemple ci-dessous illustre la création d'un support de sauvegarde miroir contenant une seule famille de supports et quatre miroirs, ainsi que la sauvegarde de la base de données AdventureWorks2022 dans ces derniers.

BACKUP DATABASE AdventureWorks2022
TO TAPE = '\\.\tape0'
MIRROR TO TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2'
MIRROR TO TAPE = '\\.\tape3'
WITH
    FORMAT,
    MEDIANAME = 'AdventureWorksSet0';

F. Créer et sauvegarder sur un support multifamiliale mis en miroir

L'exemple suivant illustre la création d'un support de sauvegarde miroir dans lequel chaque miroir contient deux familles de supports. La base de données AdventureWorks2022 est sauvegardée sur les deux miroirs.

BACKUP DATABASE AdventureWorks2022
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
    FORMAT,
    MEDIANAME = 'AdventureWorksSet1';

G. Sauvegarder sur un support en miroir existant

L'exemple suivant illustre l'ajout d'un jeu de sauvegarde au support de sauvegarde créé dans l'exemple précédent.

BACKUP LOG AdventureWorks2022
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
    NOINIT,
    MEDIANAME = 'AdventureWorksSet1';

Notes

NOINIT, par défaut, est indiqué ici pour plus de clarté.

H. Créer une sauvegarde compressée dans un nouvel ensemble multimédia

L'exemple suivant illustre le formatage du support, avec création d'un nouveau support de sauvegarde, et la sauvegarde complète compressée de la base de données AdventureWorks2022.

BACKUP DATABASE AdventureWorks2022 TO DISK='Z:\SQLServerBackups\AdvWorksData.bak'
WITH
    FORMAT,
    COMPRESSION;

I. Sauvegarder dans Microsoft Stockage Blob Azure

Cet exemple effectue une sauvegarde complète de la base de données vers Sales Stockage Blob Azure. Le nom du compte de stockage est mystorageaccount. Le conteneur se nomme myfirstcontainer. Une stratégie d’accès stockée a déjà été créée avec des droits de lecture, d’écriture, de suppression et de liste. Les informations d’identification SQL Server (https://mystorageaccount.blob.core.windows.net/myfirstcontainer) ont été créées à l’aide d’une signature d’accès partagé associée à la stratégie d’accès stockée. Pour plus d’informations sur la sauvegarde SQL Server vers Stockage Blob Azure, consultez sauvegarde et restauration SQL Server avec Stockage Blob Azure et la sauvegarde SQL Server vers l’URL.

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales.bak'
WITH STATS = 5;

Vous pouvez également sauvegarder votre base de données dans plusieurs bandes et ressembler à ceci :

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-01.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-02.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-03.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-04.bak'
WITH COPY_ONLY;

J. Sauvegarder dans le stockage d’objets compatible avec S3

S’applique à : SQL Server 2022 (16.x)

L’exemple suivant illustre la sauvegarde complète de la base de données Sales sur une plateforme de stockage d’objets compatible S3. Le nom des informations d’identification n’est pas obligatoire ni dans l’instruction ni pour correspondre au chemin exact de l’URL. Cependant, une recherche des informations d’identification appropriées est effectuée dans l’URL fournie. Pour plus d’informations, consultez Sauvegarde et restauration SQL Server avec stockage d’objets compatible S3.

BACKUP DATABASE Sales
TO      URL = 's3://10.10.10.10:8787/sqls3backups/sales_01.bak'
,       URL = 's3://10.10.10.10:8787/sqls3backups/sales_02.bak'
,       URL = 's3://10.10.10.10:8787/sqls3backups/sales_03.bak'
WITH    FORMAT
,       STATS               = 10
,       COMPRESSION;

K. Suivi de la progression de l’instruction de sauvegarde

La requête suivante retourne des informations sur les instructions de sauvegarde en cours d’exécution :

SELECT query = a.text, start_time, percent_complete,
    eta = dateadd(second,estimated_completion_time/1000, getdate())
FROM sys.dm_exec_requests r
    CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command LIKE 'BACKUP%';

SQL Server

* SQL Managed Instance *

Analytics Platform
System (PDW)

Azure SQL Managed Instance

Sauvegarde une base de données SQL dans Azure SQL Managed Instance. Azure SQL Managed Instance offre des sauvegardes automatiques. Vous pouvez créer des sauvegardes complètes de base de données COPY_ONLY. Les sauvegardes différentielles, de journaux et d’instantanés de fichiers ne sont pas prises en charge.

S’applique également à SQL Managed Instance activé par Azure Arc.

Syntaxe

BACKUP DATABASE { database_name | @database_name_var }
  TO URL = { 'physical_device_name' | @physical_device_name_var }[ ,...n ]
  WITH COPY_ONLY [, { <general_WITH_options> } ]
[;]

<general_WITH_options> [ ,...n ]::=

--Media Set Options
   MEDIADESCRIPTION = { 'text' | @text_variable }
 | MEDIANAME = { media_name | @media_name_variable }
 | BLOCKSIZE = { blocksize | @blocksize_variable }

--Data Transfer Options
   BUFFERCOUNT = { buffercount | @buffercount_variable }
 | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

--Error Management Options
   { NO_CHECKSUM | CHECKSUM }
 | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

--Compatibility Options
   RESTART

--Monitoring Options
   STATS [ = percentage ]

--Encryption Options
 ENCRYPTION (ALGORITHM = { AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY } , encryptor_options ) <encryptor_options> ::=
   SERVER CERTIFICATE = Encryptor_Name | SERVER ASYMMETRIC KEY = Encryptor_Name

Arguments

DATABASE

Spécifie une sauvegarde complète de la base de données. Au cours d’une sauvegarde de base de données, Azure SQL Managed Instance sauvegarde une portion suffisante du journal des transactions afin d’assurer la cohérence de la base de données lors de la restauration de la sauvegarde.

Important

Une sauvegarde de base de données créée sur une instance managée ne peut être restaurée que sur une autre instance Azure SQL Managed Instance ou une instance SQL Server 2022. La raison en est que SQL Managed Instance a une version de base de données interne supérieure à toutes les versions de SQL Server. Pour plus d’informations, consultez Restaurer une sauvegarde de base de données SQL Managed Instance sur SQL Server 2022.

Lorsque vous restaurez une sauvegarde créée par BACKUP DATABASE (une sauvegarde de données), l’ensemble de la sauvegarde est restauré. Pour effectuer une restauration à partir de sauvegardes automatiques SQL Managed Instance, consultez Restauration d’une base de données dans Azure SQL Managed Instance.

{ database_name | @database_name_var }

Correspond à la base de données à partir de laquelle la base de données complète est sauvegardée. S’il est fourni comme variable (@database_name_var), ce nom peut être spécifié comme constante de chaîne (@database_name_var=database name) ou comme variable de type de données chaîne de caractères, sauf pour les types de données ntext ou text.

Pour plus d’informations, consultez les articles Sauvegardes de fichiers complètes et Sauvegarder des fichiers et des groupes de fichiers.

TO URL

Spécifie l’URL à utiliser pour l’opération de sauvegarde. Le format d’URL est utilisé pour créer des sauvegardes dans le service de stockage Microsoft Azure.

Important

Pour sauvegarder vers plusieurs unités quand l’opération s’effectue vers une URL, vous devez utiliser des jetons de signature d’accès partagé (SAP). Pour obtenir des exemples de signatures d’accès partagé, consultez Sauvegarde SQL Server vers une URL et Simplifying creation of SQL Credentials with Shared Access Signature (SAS) tokens on Azure Storage with PowerShell.

n
Espace réservé qui indique que jusqu’à 64 périphériques de sauvegarde peuvent être spécifiés dans une liste séparée par des virgules.

Options WITH

Spécifie les options à utiliser avec une opération de sauvegarde.

ENCRYPTION

AES_128
AES_192
AES_256
TRIPLE_DES_3KEY
NO_ENCRYPTION

Si vous choisissez de chiffrer, vous devez également spécifier le chiffreur à l'aide des options de chiffreur :

SERVER CERTIFICATE = <Encryptor_Name>
SERVER ASYMMETRIC KEY = <Encryptor_Name>

Options de jeu de sauvegarde

COPY_ONLY

Spécifie que la sauvegarde est une sauvegarde en copie seule qui n’a aucun impact sur la séquence normale des sauvegardes. Une sauvegarde en copie seule est créée indépendamment des sauvegardes automatiques Azure SQL Database. Pour plus d’informations, consultez l’article Sauvegardes de type copie seule.

{ COMPRESSION | NO_COMPRESSION }

Spécifie si la compression de la sauvegarde est effectuée sur cette sauvegarde, remplaçant la valeur par défaut au niveau du serveur.

Le comportement par défaut exclut toute compression des sauvegardes. Toutefois, ce paramétrage par défaut peut être modifié en définissant l’option de configuration du serveur Compression par défaut des sauvegardes. Pour plus d’informations sur l’affichage de la valeur actuelle de cette option, consultez l’article Afficher ou modifier des propriétés de serveur.

COMPRESSION
Active explicitement la compression des sauvegardes.

NO_COMPRESSION
Désactive explicitement la compression des sauvegardes.

DESCRIPTION = { 'text' | @text_variable }

Spécifie le texte de format libre servant à décrire le jeu de sauvegarde. La chaîne peut compter jusqu'à 255 caractères.

NAME = { backup_set_name | @_backup| set_var }

Spécifie le nom du jeu de sauvegarde. Les noms peuvent contenir jusqu'à 128 caractères. Si l'option NAME n'est pas spécifiée, le nom reste vide.

MEDIADESCRIPTION = { text | @text_variable }

Indique le texte de description de format libre du support de sauvegarde (maximum 255 caractères).

MEDIANAME = { media_name | @media_name_variable }

BLOCKSIZE = { blocksize | @blocksize_variable }

Options de transfert de données

BUFFERCOUNT = { buffercount | @buffercount_variable }

L’espace total utilisé par les mémoires tampons est déterminé par : BUFFERCOUNT * MAXTRANSFERSIZE.

Remarque

Pour plus d’informations sur l’utilisation de l’option BUFFERCOUNT , consultez le billet de blog incorrect sur le transfert de données BufferCount peut entraîner une condition OOM.

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

Pour les bases de données comprenant un seul fichier de données et où Transparent Data Encryption (TDE) est activé, la valeur MAXTRANSFERSIZE par défaut est 65 536 (64 Ko). Pour les bases de données non chiffrées à l’aide de TDE, la valeur MAXTRANSFERSIZE par défaut est 1 048 576 (1 Mo) lors d’une sauvegarde vers DISK, et 65 536 (64 Ko) lors d’une sauvegarde vers VDI ou TAPE.

Notes

MAXTRANSFERSIZE spécifie la plus grande unité de transfert, sans garantir que chaque opération d’écriture transférera la plus grande taille spécifiée. MAXTRANSFERSIZE pour les opérations d’écriture des sauvegardes du journal de transactions distribuées est défini à 64 Ko.

Options de gestion des erreurs

{ NO_CHECKSUM | CHECKSUM }

Détermine si les sommes de contrôle de sauvegarde sont activées.

NO_CHECKSUM
Désactive explicitement la génération de sommes de contrôle de sauvegarde (et la validation des sommes de contrôle de page). Il s'agit du comportement par défaut.

L’utilisation des sommes de contrôle de sauvegarde peut affecter la charge de travail et le débit de sauvegarde.

Pour plus d’informations, consultez l’article Erreurs de support possibles pendant les opérations de sauvegarde et de restauration.

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

Détermine si une opération de sauvegarde s'arrête ou continue après avoir rencontré une erreur de somme de contrôle de page.

STOP_ON_ERROR
Ordonne à BACKUP de s'arrêter si une somme de contrôle de page n'est pas validée. Il s'agit du comportement par défaut.

CONTINUE_AFTER_ERROR
Ordonne à BACKUP de continuer en dépit des erreurs rencontrées, telles que des sommes de contrôle de page non valides ou des pages endommagées.

Pour plus d’informations, consultez l’article Erreurs de support possibles pendant les opérations de sauvegarde et de restauration.

Options de compatibilité

RESTART

Cette option n'a aucun effet. Elle est acceptée par cette version à des fins de compatibilité avec les versions antérieures de SQL Server.

Options de surveillance

STATS [ = pourcentage ]

Limitations pour SQL Managed Instance

La taille maximale d’une bande de sauvegarde est de 195 Go (taille maximale de l’objet blob). Augmentez le nombre de bandes défini dans la commande de sauvegarde pour réduire la taille de chaque bande et ainsi ne pas dépasser cette limite.

Sécurité

Autorisations

Les autorisations BACKUP DATABASE reviennent par défaut aux membres du rôle serveur fixe sysadmin et des rôles de base de données fixes db_owner et db_backupoperator.

Des problèmes de propriété et d’autorisations sur l’URL sont susceptibles de perturber une opération de sauvegarde. SQL Server doit être en mesure de lire et d'écrire sur l'unité ; le compte sous lequel le service SQL Server s'exécute doit avoir des autorisations d'écriture.

Exemples

L’exemple effectue une sauvegarde COPY_ONLY sur Sales Microsoft Stockage Blob Azure. Le nom du compte de stockage est mystorageaccount. Le conteneur se nomme myfirstcontainer. Une stratégie d’accès stockée a été créée avec des droits de lecture, écriture, suppression et liste. Les informations d’identification SQL Server (https://mystorageaccount.blob.core.windows.net/myfirstcontainer) ont été créées à l’aide d’une signature d’accès partagé associée à la stratégie d’accès stockée. Pour plus d’informations sur la sauvegarde SQL Server vers Stockage Blob Azure, consultez sauvegarde et restauration SQL Server avec Microsoft Stockage Blob Azure et SQL Server Backup to URL.

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_20160726.bak'
WITH STATS = 5, COPY_ONLY;

Vous pouvez également sauvegarder votre base de données dans plusieurs bandes et ressembler à ceci :

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-01.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-02.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-03.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-04.bak'
WITH COPY_ONLY;

Restaurer la base de données

SQL Server

SQL Managed Instance

* Analytics
Platform System (PDW) *

Système de la plateforme d'analyse

Crée une sauvegarde d’une base de données Analytics Platform System (PDW) et stocke la sauvegarde de l’appliance dans un emplacement réseau spécifié par l’utilisateur. Utilisez cette instruction avec RESTORE DATABASE - Analytics Platform System pour la récupération d’urgence, ou pour copier une base de données d’une appliance vers une autre.

Avant de commencer, lisez la section relative à l’acquisition et à la configuration d’un serveur de sauvegarde dans la documentation du produit Analytics Platform System (PDW).

Deux types de sauvegardes sont possibles dans Analytics Platform System (PDW). Une sauvegarde complète de base de données correspond à la sauvegarde de l’intégralité d’une base de données Analytics Platform System (PDW). Une sauvegarde différentielle de base de données contient uniquement les modifications effectuées depuis la dernière sauvegarde complète. Une sauvegarde de base de données utilisateur comprend les utilisateurs de la base de données, ainsi que ses rôles. La sauvegarde de la base de données master comprend les connexions.

Pour plus d’informations sur les sauvegardes de bases de données Analytics Platform System (PDW), consultez la section relative à la sauvegarde et à la restauration dans la Documentation du produit Analytics Platform System (PDW).

Syntaxe

--Create a full backup of a user database or the master database.
BACKUP DATABASE database_name
    TO DISK = '\\UNC_path\backup_directory'
    [ WITH [ ( ]<with_options> [ ,...n ][ ) ] ]
[;]

--Create a differential backup of a user database.
BACKUP DATABASE database_name
    TO DISK = '\\UNC_path\backup_directory'
    WITH [ ( ] DIFFERENTIAL
    [ , <with_options> [ ,...n ] [ ) ]
[;]

<with_options> ::=
    DESCRIPTION = 'text'
    | NAME = 'backup_name'

Arguments

database_name

Nom de la base de données pour laquelle créer une sauvegarde. Il peut s’agir de la base de données master ou d’une base de données utilisateur.

TO DISK = '\\UNC_path\backup_directory'

Chemin réseau et répertoire dans lesquels Analytics Platform System (PDW) doit écrire les fichiers de sauvegarde. Par exemple : \\\xxx.xxx.xxx.xxx\backups\2012\Monthly\08.2012.Mybackup.

Le chemin où se trouve le nom du répertoire de sauvegarde doit déjà exister et être spécifié comme un chemin UNC complet.
Le répertoire de sauvegarde (backup_directory) ne doit pas exister avant l’exécution de la commande de sauvegarde. Analytics Platform System (PDW) crée le répertoire de sauvegarde.
Le chemin du répertoire de sauvegarde ne peut pas être un chemin local ni un emplacement sur un nœud d’appliance Analytics Platform System (PDW).
La longueur maximale du chemin UNC et du nom du répertoire de sauvegarde est de 200 caractères.
Le serveur ou l’hôte doivent être spécifiés comme une adresse IP. Vous ne pouvez pas le spécifier comme le nom de l’hôte ou du serveur.

DESCRIPTION = 'text'

Spécifie une description textuelle de la sauvegarde. La longueur maximale du texte est de 255 caractères.

La description est stockée dans les métadonnées et s’affiche lorsque l’en-tête de sauvegarde est restauré avec RESTORE HEADERONLY.

NAME = 'backup _name'

Spécifie le nom de la sauvegarde. Le nom de la sauvegarde peut être différent de celui de la base de données.

Les noms peuvent contenir jusqu'à 128 caractères.
Ne peut pas inclure un chemin.
Doit commencer par une lettre, un numéro ou un trait de soulignement (_). Les caractères spéciaux autorisés sont le trait de soulignement (_), le trait d’union (-) ou l’espace ( ). Les noms de sauvegarde ne peuvent pas se terminer par un espace.
L’instruction échoue si backup_name existe déjà à l’emplacement spécifié.

Le nom est stocké dans les métadonnées et s’affiche lorsque l’en-tête de sauvegarde est restauré avec RESTORE HEADERONLY.

DIFFERENTIAL

Spécifie l’exécution d’une sauvegarde différentielle pour une base de données utilisateur. Si vous ne spécifiez pas de valeur, une sauvegarde complète est exécutée par défaut. Le nom de la sauvegarde différentielle ne doit pas nécessairement être le même que celui de la sauvegarde complète. Pour effectuer le suivi de la sauvegarde différentielle et de la sauvegarde complète correspondante, il est conseillé d’utiliser le même nom suivi de « complète » et de « diff ».

Par exemple :

BACKUP DATABASE Customer TO DISK = '\\xxx.xxx.xxx.xxx\backups\CustomerFull';

BACKUP DATABASE Customer TO DISK = '\\xxx.xxx.xxx.xxx\backups\CustomerDiff' WITH DIFFERENTIAL;

Autorisations

Nécessite l’autorisation BACKUP DATABASE ou l’appartenance au rôle de base de données fixe db_backupoperator. La base de données master peut uniquement être sauvegardée par un utilisateur standard ayant reçu le rôle de base de données fixe db_backupoperator. La base de données master peut uniquement être sauvegardée par un administrateur système, un administrateur d’infrastructure ou un membre du rôle serveur fixe sysadmin.

Nécessite un compte Windows doté d’un droit d’accès, de création et d’écriture sur le répertoire de sauvegarde. Vous devez aussi stocker le nom de compte et le mot de passe Windows dans Analytics Platform System (PDW). Pour ajouter ces informations d’identification réseau à Analytics Platform System (PDW), utilisez la procédure stockée sp_pdw_add_network_credentials Azure Synapse Analytics.

Pour plus d’informations sur la gestion des informations d’identification dans Analytics Platform System (PDW), consultez la section Sécurité.

Gestion des erreurs

Des erreurs BACKUP DATABASE se produisent dans les conditions suivantes :

Les autorisations de l’utilisateur ne sont pas suffisantes pour effectuer une sauvegarde.
Analytics Platform System (PDW) ne dispose pas des autorisations nécessaires pour accéder à l’emplacement réseau où est stockée la sauvegarde.
La base de données n’existe pas.
Le répertoire cible existe déjà sur le partage réseau.
Le partage réseau cible n’est pas disponible.
Le partage réseau cible n’a pas suffisamment d’espace pour la sauvegarde. La commande BACKUP DATABASE ne vérifie pas la présence d’un espace disque suffisant avant de lancer la sauvegarde, ce qui peut entraîner une erreur d’espace disque insuffisant lors de l’exécution de BACKUP DATABASE. Quand l’espace disque est insuffisant, Analytics Platform System (PDW) annule la commande BACKUP DATABASE. Pour réduire la taille de votre base de données, exécutez DBCC SHRINKLOG (Analytics Platform System (PDW))
Un lancement de sauvegarde a été tenté dans une transaction.

Notes

Avant d’effectuer une sauvegarde de base de données, utilisez DBCC SHRINKLOG (Analytics Platform System (PDW) pour réduire la taille de votre base de données.

Une sauvegarde Analytics Platform System (PDW) est stockée sous la forme d’un ensemble de fichiers regroupés dans un même répertoire.

Généralement, une sauvegarde différentielle prend moins de temps qu’une sauvegarde complète et peut être effectuée plus souvent. Quand plusieurs sauvegardes différentielles sont basées sur une même sauvegarde complète, chaque sauvegarde différentielle inclut l’ensemble des modifications de la dernière sauvegarde différentielle.

Si vous annulez une commande BACKUP, Analytics Platform System (PDW) supprime le répertoire cible et tous les fichiers créés pour la sauvegarde. Si Analytics Platform System (PDW) perd la connexion au partage réseau, l’annulation ne peut pas être effectuée.

Les sauvegardes complètes et les sauvegardes différentielles sont stockées dans des répertoires différents. Les conventions de nommage ne sont pas appliquées lorsque vous associez une sauvegarde complète et une sauvegarde différentielle. Vous pouvez effectuer ce suivi à l’aide de vos propres conventions de nommage. Vous pouvez également effectuer ce suivi à l’aide de l’option WITH DESCRIPTION pour ajouter une description, puis à l’aide de l’instruction RESTORE HEADERONLY pour récupérer la description.

Limites

Vous ne pouvez pas effectuer de sauvegarde différentielle pour la base de données master. Seules les sauvegardes complètes sont possibles avec les bases de données master.

Les sauvegardes de journal des transactions de la base de données système master ne sont pas prises en charge.

Les fichiers de sauvegarde sont stockés dans un format uniquement adapté à la restauration de la sauvegarde vers une appliance Analytics Platform System (PDW) à l’aide de l’instruction RESTORE DATABASE - Analytics Platform System.

La sauvegarde réalisée à l’aide de l’instruction BACKUP DATABASE ne peut pas être utilisée pour transférer des données ou des informations utilisateur vers des bases de données SMP SQL Server. Pour cela, vous pouvez utiliser la fonctionnalité de copie de la table distante. Pour plus d’informations, consultez « Copie de table distante » dans la documentation du produit Analytics Platform System (PDW).

Analytics Platform System (PDW) utilise la technologie de sauvegarde SQL Server pour sauvegarder et restaurer des bases de données. Les options de sauvegarde SQL Server sont préconfigurées pour utiliser la compression de sauvegarde. Vous ne pouvez pas définir des options de sauvegarde comme la compression, la somme de contrôle, la taille des blocs ou le nombre de tampons.

Vous ne pouvez exécuter qu’une seule sauvegarde ou restauration de base de données à la fois sur une même appliance. Analytics Platform System (PDW) met en file d’attente les commandes BACKUP et RESTORE tant que la commande BACKUP ou RESTORE en cours n’est pas terminée.

L’appliance cible pour la restauration de la sauvegarde doit comprendre au moins autant de nœuds de calcul que l’appliance source. L’appliance cible peut avoir plus de nœuds de calcul que l’appliance source, mais pas moins.

Analytics Platform System (PDW) n’effectue pas le suivi de l’emplacement et des noms des sauvegardes, puisque celles-ci ne sont pas stockées sur l’appliance.

Analytics Platform System (PDW) effectue le suivi des sauvegardes de base de données ayant réussi et ayant échoué.

Une sauvegarde différentielle est uniquement autorisée si la dernière sauvegarde complète a réussi. Par exemple, supposons que le lundi vous créez une sauvegarde complète de la Sales base de données et que la sauvegarde se termine correctement. Ensuite, le mardi, vous créez une sauvegarde complète de la Sales base de données et elle échoue. Après cet échec, vous ne pouvez pas créer une sauvegarde différentielle basée sur la sauvegarde complète de lundi. Pour créer une sauvegarde différentielle, une sauvegarde complète réussie est nécessaire.

Métadonnées

Ces vues de gestion dynamique contiennent des informations sur toutes les opérations de sauvegarde, de restauration et de chargement. Ces informations sont conservées après le redémarrage du système.

Performances

Pour effectuer une sauvegarde, Analytics Platform System (PDW) sauvegarde d’abord les métadonnées, puis effectue une sauvegarde parallèle des données de base de données qui sont stockées dans les nœuds de calcul. Les données sont copiées directement de chaque nœud de calcul vers le répertoire de sauvegarde. Pour obtenir de meilleures performances quand vous déplacez des données des nœuds de calcul vers le répertoire de sauvegarde, Analytics Platform System (PDW) permet de contrôler le nombre de nœuds de calcul qui copient des données simultanément.

Verrouillage

Applique un verrou ExclusiveUpdate sur l’objet DATABASE.

Sécurité

Les sauvegardes Analytics Platform System (PDW) ne sont pas stockées sur l’appliance. Il revient donc à votre équipe informatique de gérer tous les aspects liés à la sécurité de la sauvegarde. Cela comprend, par exemple, la gestion de la sécurité des données de sauvegarde, de la sécurité du serveur utilisé pour stocker les sauvegardes et de la sécurité de l’infrastructure réseau qui connecte le serveur de sauvegarde à l’appliance Analytics Platform System (PDW).

Gérer les informations d’identification réseau

L’accès réseau au répertoire de sauvegarde est basé sur la sécurité standard des partages de fichiers du système d’exploitation. Avant d’effectuer une sauvegarde, vous devez créer ou désigner un compte Windows qui sera utilisé pour l’authentification de Analytics Platform System (PDW) auprès du répertoire de sauvegarde. Ce compte Windows doit être doté d’un droit d’accès, de création et d’écriture sur le répertoire de sauvegarde.

Important

Pour réduire les risques de sécurité liés à vos données, il vous est conseillé de désigner un compte Windows qui servira uniquement aux opérations de sauvegarde et de restauration. Autorisez ce compte à accéder à l’emplacement de sauvegarde et à aucun autre emplacement.

Vous devez stocker le nom d’utilisateur et le mot de passe dans Analytics Platform System (PDW) en exécutant la procédure stockée sp_pdw_add_network_credentialsAzure Synapse Analytics. Analytics Platform System (PDW) utilise le Gestionnaire d’informations d’identification Windows pour stocker et chiffrer les noms d’utilisateur et les mots de passe sur le nœud de contrôle et les nœuds de calcul. Les informations d’identification ne sont pas sauvegardées avec la commande BACKUP DATABASE.

Pour supprimer les informations d’identification réseau de Analytics Platform System (PDW), consultez sp_pdw_remove_network_credentialsAzure Synapse Analytics.

Pour répertorier toutes les informations d’identification réseau stockées dans Analytics Platform System (PDW), utilisez la vue de gestion dynamique sys.dm_pdw_network_credentials.

Exemples

R. Ajouter des informations d’identification réseau pour l’emplacement de sauvegarde

Pour créer une sauvegarde, Analytics Platform System (PDW) doit disposer d’autorisations de lecture/écriture pour le répertoire de sauvegarde. L’exemple suivant montre comment ajouter les informations d’identification d’un utilisateur. Analytics Platform System (PDW) va stocker ces informations d’identification et les utiliser pour les opérations de sauvegarde et de restauration.

Important

Pour des raisons de sécurité, nous vous recommandons de créer un compte de domaine qui servira uniquement pour les sauvegardes.

EXEC sp_pdw_add_network_credentials 'xxx.xxx.xxx.xxx', 'domain1\backupuser', '*****';

B. Supprimer les informations d’identification réseau pour l’emplacement de sauvegarde

L’exemple suivant montre comment supprimer de Analytics Platform System (PDW) les informations d’identification d’un utilisateur de domaine.

EXEC sp_pdw_remove_network_credentials 'xxx.xxx.xxx.xxx';

C. Créer une sauvegarde complète d’une base de données utilisateur

L’exemple suivant crée une sauvegarde complète de la base de données utilisateur Invoices. Analytics Platform System (PDW) crée le répertoire Invoices2013 et enregistre les fichiers de sauvegarde dans le répertoire \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full.

BACKUP DATABASE Invoices TO DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full';

D. Créer une sauvegarde différentielle d’une base de données utilisateur

L’exemple suivant crée une sauvegarde différentielle, qui inclut toutes les modifications apportées depuis la dernière sauvegarde complète de la base de données Invoices. Le système de plateforme d’analyse (PDW) crée le \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff répertoire pour stocker les fichiers. La description « Invoices 2013 differential backup » est stockée avec les informations d’en-tête de la sauvegarde.

La sauvegarde différentielle ne peut être effectuée que si la dernière sauvegarde complète d’Invoices a réussi.

BACKUP DATABASE Invoices TO DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff'
    WITH DIFFERENTIAL,
    DESCRIPTION = 'Invoices 2013 differential backup';

E. Créer une sauvegarde complète de la base de données MASTER

L’exemple suivant illustre la création d’une sauvegarde complète de la base de données master et son stockage dans le répertoire \\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master, où IP est une adresse IP réseau.

BACKUP DATABASE master TO DISK = '\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master';

La base de données master stocke les informations de connexion de l’appliance. Pour sauvegarder les informations de connexion de l’appliance, vous devez sauvegarder la master base de données.

L’exemple suivant illustre la création d’une sauvegarde complète de la base de données master.

BACKUP DATABASE master TO DISK = '\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master'
WITH (
    DESCRIPTION = 'Master Backup 20130722',
    NAME = 'login-backup'
)
;

RESTORE DATABASE - Parallel Data Warehouse

Partager via

BACKUP (Transact-SQL)

Sélectionner un produit

SQL Server

Syntaxe

Arguments

DATABASE

LOG

GROUP (<database>,...n)

SERVER

METADATA_ONLY

{ database_name | @database_name_var }

<> file_or_filegroup [ ,...n ]

FILE = { logical_file_name | @logical_file_name_var }

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } [ ,...n ] ]

READ_WRITE_FILEGROUPS

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

TO <backup_device> [ ,...n ]

{ logical_device_name | @logical_device_name_var }

{ DISK | TAPE | URL} = { 'physical_device_name' | @physical_device_name_var | 'NUL' }

MIRROR TO <backup_device> [ ,...n ]

Options WITH

CREDENTIAL

FILE_SNAPSHOT

DIFFERENTIAL

ENCRYPTION

Options du jeu de sauvegarde

COPY_ONLY

[ COMPRESSION [ ALGORITHM = ( { MS_XPRESS | accelerator_algorithm } ) ] | NO_COMPRESSION ]

DESCRIPTION = { 'text' | @text_variable }

NAME = { backup_set_name | @backup_set_var }

{ EXPIREDATE ='date' | RETAINDAYS = days }

{ METADATA_ONLY | SNAPSHOT }

Options du support de sauvegarde

{ NOINIT | INIT }

{ NOSKIP | SKIP }

{ NOFORMAT | FORMAT }

MEDIADESCRIPTION = { text | @text_variable }

MEDIANAME = { media_name | @media_name_variable }

BLOCKSIZE = { blocksize | @blocksize_variable }

Options de transfert de données

BUFFERCOUNT = { buffercount | @buffercount_variable }

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

Options de gestion des erreurs

{ NO_CHECKSUM | CHECKSUM }

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

Options de compatibilité

RESTART

Options de surveillance

STATS [ = pourcentage ]

Options de bande

{ REWIND | NOREWIND }

{ UNLOAD | NOUNLOAD }

Options spécifiques au journal

{ NORECOVERY | STANDBY = undo_file_name }

NO_TRUNCATE

À propos de l’utilisation des sauvegardes SQL Server

Types de sauvegarde

Troncation du journal des transactions

Mise en forme du support de sauvegarde

Utiliser des périphériques de sauvegarde et des jeux multimédias

Unités de sauvegarde d’un jeu de sauvegarde distribuée (jeu de bandes)

Utiliser un support en miroir

Familles de supports de sauvegarde miroirs

Restaurer des sauvegardes SQL Server

Considérations supplémentaires à propos des options BACKUP

Interactions de SKIP, NOSKIP, INIT et NOINIT

Compatibilité

Notes

Interopérabilité

Métadonnées

Sécurité

Autorisations

Exemples

A. Sauvegarder une base de données complète

B. Sauvegarder la base de données et le journal

C. Créer une sauvegarde de fichiers complète des groupes de fichiers secondaires

D. Créer une sauvegarde de fichiers différentielle des groupes de fichiers secondaires

E. Créer et sauvegarder sur un support en miroir à famille unique