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

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.

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

Pour plus d'informations, consultez Utilisation des sauvegardes différentielles.

Options du jeu de sauvegarde

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

Remarque :
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 manière de spécifier un jeu de sauvegarde, consultez Arguments RESTORE (Transact-SQL).

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 ont été introduites dans SQL Server 2005 pour ê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 les options DIFFERENTIAL et COPY_ONLY sont utilisées ensemble, COPY_ONLY est ignorée 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 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 Sauvegardes de type copie seule.

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 }

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.

PASSWORD = { password | @password_variable }

Définit le mot de passe utilisé avec le jeu de sauvegarde. PASSWORD est une chaîne de caractères. Si un mot de passe est défini pour le jeu de sauvegarde, il doit être fourni lors de chaque opération de restauration SQL Server à partir du jeu. Un mot de passe de jeu de sauvegarde ne protège pas le fichier de sauvegarde contre l'écrasement. Pour ce faire, utilisez un mot de passe de support de sauvegarde à la place (voir l'option MEDIAPASSWORD ultérieurement dans ce tableau). (Pour plus d'informations sur l'utilisation des mots de passe, reportez-vous à « Autorisations », plus loin dans cette rubrique.)

Remarque relative à la sécurité :

Le niveau de protection de ce mot de passe est faible. Son but est d'éviter que des utilisateurs autorisés ou non autorisés effectuent une restauration incorrecte à l'aide des outils SQL Server 2005. Ce niveau de protection n'est pas suffisant pour empêcher la lecture des données sauvegardées par d'autres moyens ou le remplacement du mot de passe. La méthode conseillée en matière de protection des sauvegardes consiste à stocker les bandes de sauvegarde dans un emplacement sûr ou à sauvegarder les données sur des fichiers disque protégés par une liste de contrôle d'accès (ACL) appropriée. La liste de contrôle d'accès doit être définie à la racine du répertoire dans lequel les sauvegardes sont effectuées.

Remarque :
L'option PASSWORD sera supprimée dans une future version de SQL Server.

[ EXPIREDATE = date | RETAINDAYS = date ]

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 Définition des options de configuration de 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é. Si elle est fournie en tant que variable (@date_var), cette date doit suivre le format système configuré datetime et prendre l'une des formes suivantes :

• Une 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).
  
• Une variable de type smalldatetime.
  
• Une variable de type datetime.
  

Par exemple :

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

Pour plus d'informations sur la manière de spécifier des valeurs datetime, consultez Format de date alphabétique et Format de date numérique.

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 que le jeu de supports de sauvegarde puisse être écrasé. S'il est fourni en tant que variable (@days_var), sa valeur doit être un entier.

NO_LOG

Dans le contexte d'une instruction BACKUP DATABASE, spécifie qu'une sauvegarde ne contiendra aucun journal. Cela correspond à la manière dont les sauvegardes de fichiers étaient créées avant SQL Server 2005. Une sauvegarde de base de données créée avec l'option NO_LOG équivaut à un jeu complet de sauvegardes de fichiers ne contenant aucun enregistrement de journal.

En mode de restauration complète, l'option NO_LOG est utile si vous devez sauvegarder rapidement des données et que vous disposez d'une série complète de sauvegardes de journal pour ces données.

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.

Remarque :
Pour plus d'informations sur les interactions entre les options { NOINIT | INIT } et { NOSKIP | SKIP }, reportez-vous à « 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 jeu de supports, il doit être fourni. NOINIT est la valeur par défaut.

Pour plus d'informations, consultez Ajouter un jeu de sauvegarde à des jeux de sauvegardes existants.

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.

Remarque :

Si le support de sauvegarde est protégé par mot de passe, SQL Server n'écrit pas sur le support, sauf si le mot de passe du support est fourni. Ce contrôle n'est pas ignoré par l'option SKIP. Le support protégé par mot de passe ne peut être écrasé qu'en étant reformaté, ce qui supprime toutes les sauvegardes qui s'y trouvent. Pour plus d'informations sur le mot de passe du support, reportez-vous à « MEDIAPASSWORD », plus haut dans cette rubrique. Pour plus d'informations sur le reformatage du support, reportez-vous à « FORMAT », plus haut dans cette rubrique.

Pour plus d'informations, consultez Remplacement de 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.

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

NOSKIP

Commande à 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 paramètre 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 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 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 et les jeux de sauvegardes existants sont écrasés.

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 jeu de supports (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 sauvegardes. Si elle n'est pas spécifiée, ou bien si l'option SKIP l'est, aucune vérification du nom de support n'est effectuée.

MEDIAPASSWORD = { mediapassword | @mediapassword_variable }

Définit le mot de passe utilisé avec le jeu de supports. MEDIAPASSWORD est une chaîne de caractères.

Si un mot de passe est défini pour le support de sauvegarde, il doit être fourni avant la création d'un jeu de sauvegarde sur le support de sauvegarde. En outre, ce mot de passe doit également être fourni lors de chaque opération de restauration à partir du support de sauvegarde. Le support protégé par mot de passe ne peut être écrasé que par une opération de reformatage. Pour plus d'informations, reportez-vous à l'option FORMAT. (Pour plus d'informations sur l'utilisation des mots de passe, consultez la section « Autorisations » ultérieurement dans cette rubrique.)

Remarque relative à la sécurité :

Le niveau de protection de ce mot de passe est faible. Son but est d'éviter que des utilisateurs autorisés ou non autorisés effectuent une restauration incorrecte à l'aide des outils SQL Server 2005. Ce niveau de protection n'est pas suffisant pour empêcher la lecture des données sauvegardées par d'autres moyens ou le remplacement du mot de passe. La méthode conseillée en matière de protection des sauvegardes consiste à stocker les bandes de sauvegarde dans un emplacement sûr ou à sauvegarder les données sur des fichiers disque protégés par une liste de contrôle d'accès (ACL) appropriée. La liste de contrôle d'accès doit être définie à la racine du répertoire dans lequel les sauvegardes sont effectuées.

Remarque :
L'option MEDIAPASSWORD sera supprimée dans une future version de SQL Server.

BLOCKSIZE = { blocksize | @blocksize_variable }

Indique, en octets, la taille maximale de 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.

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 tampons est déterminé par : buffercount * maxtransfersize.

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

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 paramètre par défaut.

CHECKSUM

Active les sommes de contrôle de sauvegarde, ce qui permet à BACKUP d'effectuer les opérations suivantes :

1. Avant d'écrire une page sur le support de sauvegarde, BACKUP vérifie la page (somme de contrôle de page ou page endommagée) si ces informations sont disponibles.
   
2. Que la somme de contrôle de la page soit disponible ou non, BACKUP génère une somme de contrôle de sauvegarde séparée pour le flux de sauvegardes. Les opérations de restauration peuvent éventuellement utiliser cette somme de contrôle pour vérifier que la sauvegarde n'est pas endommagée. La somme de contrôle de sauvegarde est stockée sur le support de sauvegardes et non pas dans les pages de base de données. Elle peut en option être utilisée lors de la restauration.
   

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

{ 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

Commande à 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

Commande à 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 à sauvegarder 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 fichier journal après défaillance en spécifiant CONTINUE_AFTER_ERROR au lieu de NO_TRUNCATE.

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 [ = percentage ]

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 que 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 des périphériques à bandes

Ces options ne sont utilisées que dans le cas de périphériques TAPE. 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.

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 l'affichage de la liste des bandes ouvertes et sur leur fermeture, consultez Unités de sauvegarde.

{ UNLOAD | NOUNLOAD }

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.

Remarque :
Dans le cas d'une sauvegarde sur un périphérique à bandes, 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.

Remarque :
Si vous ne voulez pas effectuer de sauvegarde du journal, utilisez le mode de récupération simple. Pour plus d'informations, consultez Sauvegarde selon le mode de récupération simple.

{ NORECOVERY | STANDBY = undo_file_name }

NORECOVERY

Sauvegarde 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'enregistrement 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.

STANDBY = standby_file_name

Sauvegarde 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 de secours, 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 de secours 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 de secours 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, la base de données doit être en ligne.

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.

[ NO_LOG | TRUNCATE_ONLY ]

Remarque :
Cette option sera supprimée dans une future version de SQL Server. Évitez de l'employer pour de nouvelles tâches de développement et envisagez de modifier les applications qui l'utilisent.

Utilisée uniquement dans les instructions BACKUP LOG, cette option effectue un point de contrôle pour forcer manuellement la troncation du journal des transactions. NO_LOG et TRUNCATE_ONLY sont synonymes. Il n'est pas nécessaire de spécifier une unité de sauvegarde étant donné que le journal n'est pas sauvegardé.

En mode de récupération simple, un point de vérification supprime la partie inactive du journal sans en faire une sauvegarde. Cette opération tronque le journal en ne conservant que sa partie active. Cette option permet de libérer de l'espace, mais elle peut entraîner un risque de perte de données. Une fois le journal tronqué en utilisant NO_LOG ou TRUNCATE_ONLY, les modifications enregistrées dans la partie tronquée du journal ne sont pas récupérables avant la prochaine sauvegarde de base de données. Par conséquent, lorsque vous avez utilisé l'une de ces options, exécutez immédiatement BACKUP DATABASE pour réaliser une sauvegarde complète ou différentielle de la base de données, en vue de la récupérer ultérieurement.

Attention :

Nous vous recommandons de ne jamais utiliser les options NO_LOG ou TRUNCATE_ONLY pour tronquer manuellement le journal des transactions car la séquence de journaux de transactions consécutifs serait alors rompue. Jusqu'à la prochaine sauvegarde complète ou différentielle, la base de données n'est pas protégée contre une défaillance du support. N'utilisez la troncation manuelle du journal que dans des circonstances très précises et sauvegardez immédiatement les données.

SQL Server recourt à 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 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 opération de compactage ou de gestion des fichiers, 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.

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.
  

Pour plus d'informations, consultez Création d'un nouveau support 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.
  Base de données partielle	Les sauvegardes partielles couvrent les groupes de fichiers en lecture/écriture et, éventuellement, un ou plusieurs fichiers ou groupes de fichiers en lecture seule.
  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.

• En mode de restauration 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 requises. 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.
  

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

  Pour plus d'informations, consultez Utilisation des sauvegardes de journaux de transactions.
  
• 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 Sauvegardes de type copie seule.
  

Lors d'une sauvegarde de base de données complète dans SQL Server 2005, les données de texte intégral sont sauvegardées avec les autres données de la base de données. L'opération de sauvegarde traite les catalogues de texte intégral comme des fichiers. Par exemple, les catalogues peuvent être sauvegardés en isolation au moyen de la clause FILE= pour sélectionner les catalogues. (Le nom de fichier logique de chaque catalogue de texte intégral est au format sysft_<nom de catalogue>.)

Lors de la sauvegarde, le catalogue est placé en mode lecture seule, de façon à ce que l'activité d'analyse (processus de création et de maintien d'un index de texte intégral) soit suspendue jusqu'à ce que la sauvegarde soit terminée.

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

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.

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

2 L'utilisateur doit appartenir aux rôles de serveur ou de base de données fixes appropriés et fournir le mot de passe de support correct pour effectuer une opération de sauvegarde.

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

• backupfile (Transact-SQL)
  
• backupfilegroup (Transact-SQL)
  
• backupmediafamily (Transact-SQL)
  
• backupmediaset (Transact-SQL)
  
• backupset (Transact-SQL)
  

Si une restauration est effectuée et que le jeu de sauvegarde n'est pas encore enregistré dans la base de données msdb, les tables d'historique de sauvegarde ne seront peut-être pas modifiées.

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 les mots clés suivants pour assurer la compatibilité descendante avec les versions antérieures de SQL Server :

• L'option RESTART est acceptée à des fins de compatibilité, mais n'a aucun effet dans SQL Server 2005.
  
• Pour garantir la compatibilité descendante, vous pouvez utiliser le mot clé DUMP au lieu du mot clé BACKUP dans vos instructions BACKUP. En outre, vous pouvez utiliser le mot clé TRANSACTION au lieu du mot clé LOG. Le moteur de base de données SQL Server interprète DUMP DATABASE ou DUMP TRANSACTION exactement de la même manière que, respectivement, BACKUP DATABASE ou BACKUP LOG.
  

  Important :
  L'instruction DUMP est prise en charge pour des raisons de compatibilité descendante. Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft 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é. Utilisez plutôt BACKUP.

Un jeu de bandes est un ensemble de fichiers disque sur lesquels les données sont divisées en bloc et distribuées dans un ordre figé. 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 suivant écrit une sauvegarde de la base de données AdventureWorks sur un nouveau support de sauvegarde distribuée qui fait appel à trois fichiers disque.

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

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 AdventureWorks
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

L'exemple suivant sauvegarde la base de données AdventureWorks dans un fichier disque.

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

L'exemple suivant sauvegarde l'exemple de base de données AdventureWorks 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 AdventureWorks est modifiée pour utiliser le mode de restauration 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 AdventureWorks
   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', 
'Z:\SQLServerBackups\AdvWorksLog.bak';
GO

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

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.

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

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

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

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

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

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

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

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

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

[Début des exemples]