BACKUP (Transact-SQL)

 

CETTE RUBRIQUE S’APPLIQUE À :ouiSQL Server (à partir de la version 2008)nonAzure SQL DatabasenonAzure SQL Data WarehousenonParallel Data Warehouse

Sauvegarde complète SQL Server base de données pour créer une sauvegarde de base de données, un ou plusieurs fichiers ou groupes de fichiers de la base de données pour créer une sauvegarde de fichier (base de données de sauvegarde). 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).

Topic link icon Conventions de la syntaxe Transact-SQL

  
Backing 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 ] } ]  
[;]  
  
Backing 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 ] } ]  
[;]  
  
Creating 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 ] } ]  
[;]  
  
Backing 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_optionspec> } [ ,...n ] ]  
[;]  
  
<backup_device>::=   
 {  
   { logical_device_name | @logical_device_name_var }   
 | { DISK | TAPE | URL} =   
     { 'physical_device_name' | @physical_device_name_var }  
 }   
  
<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 | 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 } }   
  
--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 }   
  
--Log-specific Options  
   { NORECOVERY | STANDBY = undo_file_name }  
 | NO_TRUNCATE  
  
--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   

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 la sauvegarde de la base de données (un sauvegarde des données), l’ensemble de la sauvegarde est restaurée. Seule une sauvegarde du fichier journal peut être restaurée à un moment ou une transaction spécifique au sein de la sauvegarde.

System_CAPS_ICON_note.jpg Remarque


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

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 journal à un moment spécifique ou d’une transaction au sein de la sauvegarde en spécifiant WITH STOPAT, STOPATMARK ou STOPBEFOREMARK dans votre RESTORE LOG instruction.

System_CAPS_ICON_note.jpg Remarque


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

{ 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. Fourni comme variable (@var_nom_base_de_données), ce nom peut être spécifié comme une constante de chaîne (@var_nom_base_de_données=nom de base de données) ou comme une variable de type chaîne de caractères, à l’exception de la ntext ou texte les types de données.

System_CAPS_ICON_note.jpg Remarque


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 ]</file_or_filegroup>
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.

Groupe de fichiers ** = ** { nom_groupe_fichiers_logique| @var_nom_groupe_fichiers_logique }
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.

System_CAPS_ICON_note.jpg Remarque


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.

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 : complète des sauvegardes de fichiers (SQL Server) et sauvegarde de fichiers et groupes de fichiers (SQL Server).

READ_WRITE_FILEGROUPS [ , FILEGROUP = { nom_groupe_fichiers_logique| @var_nom_groupe_fichiers_logique } [ ,... 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.

System_CAPS_ICON_important.jpg 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 = { nom_groupe_fichiers_logique| @var_nom_groupe_fichiers_logique }
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, reportez-vous à « <file_or_filegroup> », plus haut dans cette rubrique.

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 les sauvegardes partielles (SQL Server).

TO <backup_device> [ ,... n ]</backup_device>
Indique que l’accompagnement définie de unités de sauvegarde est un jeu de supports non mis en miroir ou le premier miroir d’un support de sauvegarde miroir (pour lequel une ou plusieurs clauses MIRROR TO sont déclarées).

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

{ logical_device_name | @logical_device_name_var }
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 de l’unité de sauvegarde peut être spécifié comme une constante de chaîne (@logical_device_name_var ** = ** nom de l’unité logique de sauvegarde) ou comme une variable de tout type de données de chaîne de caractères à l’exception de la ntext ou texte les types de données.

{DISQUE | BANDE | URL} = { 'physical_device_name' | @physical_device_name_var }
Spécifie un fichier de disque ou périphérique à bandes, ou un service de stockage d'objets blob Windows Azure. Le format d’URL est utilisé pour créer des sauvegardes dans le service de stockage Windows Azure. Pour plus d’informations et d’exemples, consultez SQL Server sauvegarde et restauration avec le Service de stockage d’objets Blob Microsoft Azure. Pour obtenir un didacticiel, consultez didacticiel : SQL Server sauvegarde et restauration au Service de stockage d’objets Blob Windows Azure.

System_CAPS_ICON_warning.jpg Avertissement


Avec SQL Server 2012 SP1 CU2 tant que SQL Server 2016, vous pouvez sauvegarder uniquement à un seul périphérique lorsque vous sauvegardez à l’URL. Pour sur plusieurs unités de sauvegarde lors de la sauvegarde vers URL vous devez utiliser SQL Server 2016 via version actuelle) et vous devez utiliser des jetons de Signature d’accès partagé (SAP). Pour des exemples de création d’une Signature d’accès partagé, consultez SQL Server Backup to URL et en simplifiant la création d’informations d’identification SQL avec des jetons de Signature d’accès partagé (SAS) sur le stockage Azure avec Powershell.

URL : s’applique aux: SQL Server (SQL Server 2012 SP1 CU2 et version actuelle).

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é.

Pour plus d’informations, consultez Backup Devices (SQL Server).

System_CAPS_ICON_note.jpg Remarque


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é indiquant qu'il est possible de spécifier jusqu'à 64 unités de sauvegarde dans une liste séparée par des virgules.

MIRROR TO <backup_device> [ ,... n ]</backup_device>
Spécifie un jeu constitué au maximum de trois unités de sauvegarde, dont chacune sera le miroir des unités de sauvegarde spécifiées dans la clause TO. La clause MIRROR TO doit contenir 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.

System_CAPS_ICON_note.jpg Remarque


Pour MIRROR TO = DISK, BACKUP détermine automatiquement la taille de bloc appropriée des unités de disques. Pour plus d'informations sur la taille de bloc, consultez « BLOCKSIZE » ultérieurement dans ce tableau.

<unité_de_sauvegarde>
Voir « <backup_device> », plus haut dans cette section.

n
Espace réservé indiquant qu'il est possible de spécifier jusqu'à 64 unités de sauvegarde 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 cette rubrique.

[ suivant-miroir-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'utilise uniquement lors de la création d'une sauvegarde dans le service de stockage d'objets blob Windows Azure.

S’applique aux: SQL Server (SQL Server 2012 SP1 CU2 et version actuelle).

FILE_SNAPSHOT
Utilisé pour créer un instantané des fichiers de base de données Azure, lorsque tous les fichiers de base de données SQL Server sont stockées à l’aide du service de stockage d’objets Blob Azure. Pour plus d’informations, consultez fichiers de données SQL Server dans Microsoft Azure. SQL ServerSauvegarde instantanée prend des instantanés Azure des fichiers de base de données (données et fichiers journaux) à un état cohérent. Un ensemble cohérent d’instantanés Azure constituent une sauvegarde et sont enregistrées dans le fichier de sauvegarde. La seule différence entre sauvegarde de base de données aux URL avec FILE_SNAPSHOT et sauvegarde de journal pour URL avec FILE_SNAPSHOT est que ce dernier également tronque le journal des transactions n’est pas le cas de l’ancienne. Avec SQL Server sauvegarde instantané, après la sauvegarde complète initiale requise par SQL Server pour établir la chaîne de sauvegarde, seule une sauvegarde de journal unique est nécessaire pour restaurer une base de données au point dans le temps de la sauvegarde du journal des transactions. En outre, seules deux sauvegardes de journal des transactions sont requis pour restaurer une base de données à un point dans le temps entre le moment où les deux transactions de sauvegardes de journaux.

S’applique aux: SQL Server 2016 via version actuelle).

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.

System_CAPS_ICON_note.jpg Remarque


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

Pour plus d’informations, consultez Sauvegardes différentielles (SQL Server).

ENCRYPTION
Utilisé pour spécifier le chiffrement d'une sauvegarde. Spécifiez un algorithme de chiffrement pour chiffrer la sauvegarde ou spécifiez « 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

    System_CAPS_ICON_warning.jpg Avertissement


    Lorsque le chiffrement est utilisé conjointement avec 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 que le chiffrement transparent des données a été effectuée pour la base de données. Aucun chiffrement supplémentaire se produit pour les données elles-mêmes. La sauvegarde échoue si la base de données n’a pas été chiffré ou si le chiffrement n’a pas été exécutée avant l’instruction de sauvegarde a été émise.

Options de jeu de sauvegarde

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

System_CAPS_ICON_note.jpg Remarque


Pour spécifier une jeu de sauvegarde pour une opération de restauration, utilisez le fichier ** = ** * <backup_set_file_number> * option.</backup_set_file_number> Pour plus d’informations sur la spécification d’un jeu de sauvegarde, consultez « Spécification d’un jeu de sauvegarde » dans Arguments RESTORE (Transact-SQL).

COPY_ONLY
Spécifie que la sauvegarde est un sauvegarde copie seule, qui n’affecte pas 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.

    System_CAPS_ICON_important.jpg Important


    Si les options DIFFERENTIAL et COPY_ONLY sont utilisées ensemble, COPY_ONLY est ignorée et une sauvegarde différentielle est créée.

  • Lorsqu’il est utilisé avec les journaux de sauvegarde, l’option COPY_ONLY crée un sauvegarde du journal de 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 Sauvegardes de copie uniquement (SQL Server).

{ COMPRESSION | NO_COMPRESSION }
Dans SQL Server 2008 Enterprise et versions ultérieures uniquement, spécifie si la compression de 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. Mais cette valeur par défaut peut être modifié en définissant le de sauvegarde par défaut de compression option de configuration de serveur. Pour plus d’informations sur l’affichage de la valeur actuelle de cette option, consultez afficher ou modifier les propriétés de serveur (SQL Server).

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.

{ 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 option n’est spécifiée, la date d’expiration est déterminée par le mediaretention de configuration. Pour plus d’informations, consultez Options de configuration de serveur (SQL Server).

System_CAPS_ICON_important.jpg 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é. Fourni comme variable (@var_date), cette date doit suivre le système configuré datetime formater et être spécifié comme l’une des opérations suivantes :

  • Constante de chaîne (@var_date ** = ** date)

  • Une variable de type chaîne de caractères (à l’exception de la ntext ou texte les types de données)

  • Un smalldatetime

  • A datetime variable

Exemple :

  • 'Dec 31, 2020 11:59 PM'

  • '1/1/2021'

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

System_CAPS_ICON_note.jpg Remarque


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. Fourni comme variable (@days_var), il doit être spécifié sous forme d’entier.

Définie les Options de support

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.

System_CAPS_ICON_note.jpg Remarque


Pour plus d’informations sur les interactions entre { NOINIT | INIT} et { NOSKIP | {SKIP}, consultez 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 Jeux de supports, familles de supports et jeux de sauvegarde (SQL Server).

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, reportez-vous aux 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 contrôles, utilisez l'option SKIP.

Pour plus d’informations, consultez Jeux de supports, familles de supports et jeux de sauvegarde (SQL Server).

{ 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.

System_CAPS_ICON_note.jpg Remarque


Pour plus d’informations sur les interactions entre { NOINIT | INIT} et { NOSKIP | {SKIP}, consultez 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 }, reportez-vous à « Remarques », plus loin dans cette rubrique.

Pour afficher les dates d’expiration des jeux de sauvegarde, interrogez la expiration_date colonne de la backupset table d’historique.

{ 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.

System_CAPS_ICON_important.jpg Important


Utilisez l'option FORMAT avec prudence. 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.

Si l'option FORMAT est spécifiée, l'option SKIP est implicitement prise en compte ; il n'est pas nécessaire de spécifier explicitement l'option SKIP.

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.

System_CAPS_ICON_note.jpg Remarque


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.

System_CAPS_ICON_note.jpg Remarque


Pour plus d’informations sur l’utilisation de l’option BUFFERCOUNT, consultez le Incorrect BufferCount data transfer option risque d’insuffisance blog.

MAXTRANSFERSIZE ** = ** { maxtransfersize | @maxtransfersize_variable }
Spécifie la plus grande unité de transfert en octets à 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).

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 | SOMME DE CONTRÔLE}
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 support possibles erreurs au cours de sauvegarde et de restauration (SQL Server).

{ 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 pouvez pas sauvegarder la fin du journal à l’aide de l’option NO_TRUNCATE option lorsque la base de données est endommagée, vous pouvez tenter une sauvegarde du journal de la fin du journal en spécifiant CONTINUE_AFTER_ERROR au lieu de NO_TRUNCATE.

Pour plus d’informations, consultez support possibles erreurs au cours de sauvegarde et de restauration (SQL Server).

Options de compatibilité

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

Options d’analyse

STATS [ =percentage ]
Affiche un message chaque fois qu’un autre pourcentage se termine et sert à évaluer la progression. Si pourcentage est omis, SQL Server affiche un message après chaque 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érera et rembobinera 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.

System_CAPS_ICON_note.jpg Remarque


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 plus d’informations sur comment faire pour afficher une liste des bandes ouvertes et fermeture, consultez les unités de sauvegarde (SQL Server).

{ UNLOAD | NOUNLOAD}

System_CAPS_ICON_note.jpg Remarque


UNLOAD/NOUNLOAD est un paramètre de session qui reste en vigueur jusqu'à la fin de la session ou tant qu'il n'est pas réinitialisé par le choix de l'option opposée à celle en cours d'utilisation.

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 restera chargée dans le lecteur de bande.

System_CAPS_ICON_note.jpg Remarque


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.

System_CAPS_ICON_note.jpg Remarque


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

{NORECOVERY | Mise en veille ** = ** nom_fichier_annulation }
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, utilisez conjointement les options NO_TRUNCATE et NORECOVERY.

Mise en veille ** = ** 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.

À l’aide du mode veille requiert un fichier d’annulation, spécifié par standby_file_name, dont l’emplacement est stocké 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 n'est pas 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 l'option NO_TRUNCATE peuvent être incomplètes. Cette option permet de sauvegarder le journal 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 la base de données, consultez les États de base de données.

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

Types de sauvegarde

Troncation du journal des transactions

Mise en forme du support de sauvegarde

Utilisation des unités de sauvegarde et des jeux de supports

Restauration de sauvegardes SQL Server

System_CAPS_ICON_note.jpg Remarque


Pour une introduction à la sauvegarde dans SQL Server, consultez présentation de la sauvegarde (SQL Server).

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 sauvegardeTypes de sauvegarde
    Base de données entièreSauvegardes de base de données couvrent la base de données.

    Éventuellement, chaque sauvegarde de base de données peut servir de base d’une série d’un ou plusieurs les sauvegardes différentielles de base de données.
    Base de données partielleLes sauvegardes partielles garde lecture/écriture de groupes de fichiers et, éventuellement, un ou plusieurs fichiers en lecture seule ou groupes de fichiers.

    Éventuellement, chaque sauvegarde partielle peut servir de base d’une série d’un ou plusieurs les sauvegardes différentielles partielles.
    Fichier ou groupe de fichiersSauvegardes de fichiers couvrent un ou plusieurs fichiers ou groupes de fichiers et ne sont pertinentes que pour les 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.

    Éventuellement, chaque sauvegarde de fichiers peut servir de base d’une série d’un ou plusieurs sauvegardes différentielles de fichiers.
  • Sous le modèle de récupération complète ou mode de récupération journalisé en bloc, sauvegardes conventionnelles incluent également séquentiel journal des transactions (ou les sauvegardes du journal), qui sont requis. 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.

    System_CAPS_ICON_note.jpg Remarque


    Avant de pouvoir créer la première sauvegarde du fichier journal, vous devez créer une sauvegarde complète.

  • A sauvegarde copie seule est une sauvegarde complète à usage spécial ou une sauvegarde du journal qui est indépendante de la séquence normale des sauvegardes conventionnelles. Pour créer une sauvegarde en copie seule, spécifiez l'option COPY_ONLY dans votre instruction BACKUP. Pour plus d’informations, consultez Sauvegardes de copie uniquement (SQL Server).

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 Journal des transactions (SQL Server).

System_CAPS_ICON_note.jpg Remarque


Les options BACKUP LOG WITH NO_LOG et WITH TRUNCATE_ONLY ont été supprimées. 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 Afficher ou modifier le mode de récupération d’une base de données (SQL Server).

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.

Utilisation des unités de sauvegarde et des jeux de supports

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

A agrégat est un ensemble de fichiers du disque sur lequel 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é avec FORMAT).

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

BACKUP DATABASE AdventureWorks2012  
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 AdventureWorks2012 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.

Utilisation d'un support de sauvegarde 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 dans 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 AdventureWorks2012  
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  

System_CAPS_ICON_important.jpg 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.

MiroirFamille de supports 1Famille de supports 2Famille de supports 3
0Z:\AdventureWorks1a.bakZ:\AdventureWorks2a.bakZ:\AdventureWorks3a.bak
1Z:\AdventureWorks1b.bakZ:\AdventureWorks2b.bakZ:\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 de supports en miroir, consultez Mirrored Backup Media Sets (SQL Server). Pour plus d’informations sur les jeux de supports et des familles de supports en général, consultez jeux de supports, familles de supports et jeux de sauvegarde (SQL Server).

Restauration de sauvegardes SQL Server

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

Interactions de SKIP, NOSKIP, INIT et NOINIT

Le tableau suivant décrit les interactions entre le { NOINIT | INIT} et { NOSKIP | Options SKIP}.

System_CAPS_ICON_note.jpg Remarque


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.

NOINITINIT
NOSKIPSi 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 à support name.* * l’en-tête du

-Vérifie qu’il n’y a aucun jeux de sauvegarde valide déjà sur le support. 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.
SKIPSi 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 valide * en-tête, remplace les jeux de sauvegarde sur le support en ne gardant seulement l’en-tête de support.

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.
  • Validité inclut le 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.

** L’utilisateur doit appartenir aux fixe de base de données ou serveur de rôles approprié pour effectuer une opération de sauvegarde.

System_CAPS_ICON_caution.jpg 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 pour assurer la compatibilité descendante avec les versions antérieures de SQL Server. Mais RESTART est inopérant.

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.

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.

System_CAPS_ICON_note.jpg Remarque


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 peuvent rapidement s'accumuler, créer des journaux d'erreurs très volumineux et compliquer la recherche d'autres messages. Dans de tels cas, vous pouvez supprimer ces entrées de journal en utilisant l'indicateur de trace 3226 si aucun de vos scripts ne dépend de ces entrées. Pour plus d’informations, consultez Indicateurs de trace (Transact-SQL).

SQL Serverutilise un processus de sauvegarde en ligne pour permettre une sauvegarde de base de données pendant que la base de données est en cours d’utilisation. 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 des fichiers telles que l'instruction ALTER DATABASE employée avec les options ADD FILE et 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 chevauche une gestion de fichiers ou l’opération de compactage, 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.

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

Lorsqu’une restauration est effectuée, si le jeu de sauvegarde n’a pas déjà enregistré dans le msdb de base de données, les tables peuvent être modifiées à l’historique de sauvegarde.

À partir de SQL Server 2012, le mot de passe et MEDIAPASSWORD options sont supprimées pour la création de sauvegardes. Il est encore possible de restaurer des sauvegardes créées avec des mots de passe.

Permissions

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. 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. 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 pour le fichier physique de l'unité de sauvegarde peuvent n'apparaître que lorsque la ressource physique est sollicitée au moment de la sauvegarde ou de la restauration.

Cette section contient les exemples suivants :

System_CAPS_ICON_note.jpg Remarque


Les rubriques de procédures de sauvegarde contiennent des exemples supplémentaires. Pour plus d’informations, consultez Backup Overview (SQL Server).

A. Sauvegarde d'une base de données complète

L’exemple suivant sauvegarde le AdventureWorks2012 base de données dans un fichier disque.

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

B. Sauvegarde de la base de données et du journal

L'exemple suivant sauvegarde l'exemple de base de données AdventureWorks2012 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 AdventureWorks2012 est modifiée pour utiliser le mode de récupération complète.

Ensuite, l’exemple utilise sp_addumpdevice pour créer un opérateur logique unité de sauvegarde de sauvegarde des données, AdvWorksDataet crée une autre unité de sauvegarde logique pour la sauvegarde du 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 AdventureWorks2012  
   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 AdventureWorks2012 database.  
BACKUP DATABASE AdventureWorks2012 TO AdvWorksData;  
GO  
-- Back up the AdventureWorks2012 log.  
BACKUP LOG AdventureWorks2012  
   TO AdvWorksLog;  
GO  

System_CAPS_ICON_note.jpg Remarque


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éation d'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éation d'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éation et sauvegarde dans un support de sauvegarde miroir d'une seule famille

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 AdventureWorks2012 dans ces derniers.

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

F. Création et sauvegarde dans un support de sauvegarde miroir de plusieurs familles

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 AdventureWorks2012 est sauvegardée sur les deux miroirs.

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

G. Sauvegarde dans un support de sauvegarde 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 AdventureWorks2012  
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'  
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'  
WITH   
   NOINIT,  
   MEDIANAME = 'AdventureWorksSet1';  

System_CAPS_ICON_note.jpg Remarque


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

H. Création d'une sauvegarde compressée dans un nouveau support de sauvegarde

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

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

I. Sauvegarde du service de stockage d’objets blob Microsoft Azure

L’exemple effectue une sauvegarde complète de Sales pour le service de stockage d’objets Blob Azure de Microsoft. 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. Le SQL Server information d’identification, https://mystorageaccount.blob.core.windows.net/myfirstcontainer, a été créé à l’aide d’une Signature d’accès partagé qui est associé à la stratégie d’accès stockée. Pour plus d’informations sur SQL Server de sauvegarde pour le service de stockage d’objets Blob de Windows Azure, consultez SQL Server sauvegarde et restauration avec le Service de stockage d’objets Blob Microsoft 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;

Unités de sauvegarde (SQL Server)
Jeux de supports, familles de supports et jeux de sauvegarde (SQL Server)
Sauvegardes de fichier journal (SQL Server)
MODIFIER la base de données (Transact-SQL)
DBCC SQLPERF (Transact-SQL)
RESTAURATION (Transact-SQL)
RESTORE FILELISTONLY (Transact-SQL)
RESTORE HEADERONLY (Transact-SQL)
RESTORE LABELONLY (Transact-SQL)
RESTORE VERIFYONLY (Transact-SQL)
sp_addumpdevice (Transact-SQL)
sp_configure (Transact-SQL)
sp_helpfile (Transact-SQL)
sp_helpfilegroup (Transact-SQL)
Options de Configuration de serveur (SQL Server)
Restauration fragmentaire de bases de données avec des Tables optimisées en mémoire

Ajouts de la communauté

AJOUTER
Afficher: