Unités de sauvegarde (SQL Server)

Article
06/25/2013

Au cours d'une opération de sauvegarde sur une base de données SQL Server, les données sauvegardées (la sauvegarde) sont écrites sur une unité de sauvegarde physique. Cette unité de sauvegarde physique est activée dès l'écriture de la première sauvegarde dans un jeu de supports. Les sauvegardes sur un jeu comprenant une ou plusieurs unités de sauvegarde constituent un seul jeu de supports.

[!REMARQUE]

À compter de la mise à jour cumulative 2 de SQL Server 2012 SP1, la sauvegarde SQL Server vers le service de stockage d'objets blob Windows Azure est prise en charge. Pour plus d'informations, consultez Backup and Restore Enhancements et Sauvegarde et restauration SQL Server avec le service de stockage d'objets blob Windows Azure.

Dans cette rubrique :

Termes et définitions
Utilisation d'unités de sauvegarde sur disque
Utilisation de périphériques à bandes
Utilisation d'une unité de sauvegarde logique
Jeux de supports de sauvegarde en miroir
Archivage des sauvegardes SQL Server
Tâches associées

Termes et définitions

disque de sauvegarde
Support de stockage sur disque dur ou autre qui renferme un ou plusieurs fichiers de sauvegarde. Un fichier de sauvegarde est un fichier de système d'exploitation classique.
jeu de supports
Ensemble ordonné de supports de sauvegarde (bandes ou fichiers disque) qui utilise un type et un nombre fixes d'unités de sauvegarde. Pour plus d'informations sur les jeux de supports, consultez Jeux de supports, familles de supports et jeux de sauvegarde (SQL Server).
unité de sauvegarde physique
Soit un lecteur de bande, soit un fichier disque fourni par le système d'exploitation. Vous pouvez réaliser une sauvegarde sur 1 à 64 unités de sauvegarde. Si une sauvegarde nécessite plusieurs unités de sauvegarde, les unités doivent toutes correspondre à un seul type d'unité (disque ou bande).

[Haut de la page]

Utilisation d'unités de sauvegarde sur disque

Dans cette section :

Définition d'un fichier de sauvegarde selon son nom physique (Transact-SQL)
Spécification du chemin d'accès d'un fichier de sauvegarde sur disque
Sauvegarde dans un fichier sur un partage réseau

Si un fichier disque se remplit pendant qu'une opération de sauvegarde ajoute une sauvegarde au jeu de supports, l'opération de sauvegarde échoue. La taille maximale d'un fichier de sauvegarde est fonction de l'espace libre disponible sur l'unité de disque ; la taille appropriée d'une unité de sauvegarde sur disque dépend donc de la taille de vos sauvegardes.

Une unité de sauvegarde sur disque peut être une simple unité de disque, telle qu'un lecteur ATA. Une autre solution envisageable consiste à utiliser une unité de disque échangeable à chaud qui vous permettrait de remplacer de manière transparente un disque saturé sur l'unité par un disque vide. Un disque de sauvegarde peut désigner un disque local sur le serveur ou un disque distant correspondant à une ressource réseau partagée. Pour savoir comment utiliser un disque distant, consultez la section Sauvegarde dans un fichier sur un partage réseau, plus loin dans cette rubrique.

Les outils de gestion de SQL Server offrent une excellente souplesse de gestion des unités de sauvegarde sur disque puisqu'ils génèrent automatiquement un nom horodaté dans le fichier disque.

Important

À titre de recommandation, il est préférable que le disque de sauvegarde ne soit pas le même que les disques de données ou de journal de la base de données. Ce paramètre est primordial pour garantir l'accès aux sauvegardes en cas d'échec du disque de données ou de journal.

Définition d'un fichier de sauvegarde selon son nom physique (Transact-SQL)

La syntaxe BACKUP de base permettant de spécifier un fichier de sauvegarde d'après son nom d'unité physique est la suivante :

BACKUP DATABASE database_name

TO DISK = { 'physical_backup_device_name' | **@**physical_backup_device_name_var }

Par exemple :

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

Pour spécifier une unité de disque physique dans une instruction RESTORE, la syntaxe de base est la suivante :

RESTORE { DATABASE | LOG } database_name

FROM DISK = { 'physical_backup_device_name' | **@**physical_backup_device_name_var }

Par exemple :

RESTORE DATABASE AdventureWorks2012 
   FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2012.bak';

[Haut de la page]

Spécification du chemin d'accès d'un fichier de sauvegarde sur disque

Lorsque vous spécifiez un fichier de sauvegarde, entrez son chemin d'accès complet et le nom du fichier. Si vous spécifiez uniquement le nom du fichier ou un chemin d'accès relatif au moment de la sauvegarde d'un fichier, celui-ci est copié dans le répertoire de sauvegarde par défaut. Le répertoire de sauvegarde par défaut est C:\Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\Backup, où n est le numéro de l'instance du serveur. Par conséquent, pour l'instance de serveur par défaut, le répertoire de sauvegarde par défaut est : C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup.

Pour éviter toute ambiguïté, en particulier dans les scripts, il est recommandé de spécifier explicitement le chemin d'accès du répertoire de sauvegarde dans chaque clause DISK. Cependant, cette exigence prend moins d'importance si vous utilisez l'Éditeur de requête. Dans ce cas, si vous êtes certain que le fichier de sauvegarde réside dans le répertoire de sauvegarde par défaut, vous pouvez omettre le chemin d'accès d'une clause DISK. Par exemple, l'instruction BACKUP suivante sauvegarde la base de données AdventureWorks2012 dans le répertoire de sauvegarde par défaut.

BACKUP DATABASE AdventureWorks2012 
   TO DISK = ’AdventureWorks2012.bak’;
GO

[!REMARQUE]

L'emplacement par défaut est stocké dans la clé de Registre BackupDirectory sous HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.n\MSSQLServer.

[Haut de la page]

Sauvegarde dans un fichier sur un partage réseau

Pour permettre à SQL Server d'accéder au fichier disque distant, le compte de service SQL Server doit bénéficier d'un accès au partage réseau. Cette situation implique que vous disposiez des autorisations nécessaires aux opérations de sauvegarde pour écrire sur le partage réseau et aux opérations de restauration pour lire à partir de ce dernier. La disponibilité des lecteurs réseau et des autorisations dépend du contexte dans lequel le service SQL Server est exécuté :

Pour sauvegarder un lecteur réseau lorsque SQL Server s'exécute via un compte d'utilisateur de domaine, le lecteur partagé doit être mappé sur un lecteur réseau dans la session où SQL Server est exécuté. Si vous démarrez Sqlservr.exe à partir de la ligne de commande, SQL Server voit tous les lecteurs réseau que vous avez mappés dans votre session de connexion.
Lorsque vous exécutez Sqlservr.exe en tant que service, SQL Server s'exécute dans une autre session qui n'a aucun lien avec votre session de connexion. La session dans laquelle un service s'exécute peut avoir ses propres lecteurs mappés (bien que ce ne soit généralement pas le cas).
Il est possible de se connecter au compte de service réseau à l'aide du compte d'ordinateur plutôt qu'avec un compte d'utilisateur de domaine. Pour autoriser des sauvegardes sur un lecteur partagé à partir d'ordinateurs spécifiques, accordez l'accès aux comptes de ces ordinateurs. Tant que le processus Sqlservr.exe chargé d'écrire la sauvegarde bénéficie d'un accès, peu importe si l'utilisateur exécutant la commande BACKUP dispose d'un accès ou non.

Important

La sauvegarde de données sur un réseau peut être sujette à des erreurs du réseau ; c'est pourquoi nous vous conseillons de vérifier l'opération de sauvegarde après l'avoir menée à terme si vous utilisez un disque distant. Pour plus d'informations, consultez RESTORE VERIFYONLY (Transact-SQL).

Définition d'un nom UNC (Universal Naming Convention)

Pour préciser un partage réseau dans une opération de sauvegarde ou de restauration, vous devez utiliser le nom UNC (Universal Naming Convention) complet du fichier de l'unité de sauvegarde. Un nom UNC se présente sous la forme **\\Systemname\ShareName\Path\**FileName.

Par exemple :

BACKUP DATABASE AdventureWorks2012 
   TO DISK = '\\BackupSystem\BackupDisk1\AW_backups\AdventureWorksData.Bak';
GO

[Haut de la page]

Utilisation de périphériques à bandes

[!REMARQUE]

La prise en charge des unités de sauvegarde sur bande sera supprimée dans une prochaine version de SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement et prévoyez de modifier les applications qui l'utilisent actuellement.

Dans cette section :

Définition d'une bande de sauvegarde selon son nom physique (Transact-SQL)
Options BACKUP et RESTORE spécifiques aux bandes (Transact-SQL)
Gestion de bandes ouvertes

La sauvegarde de données SQL Server sur bande exige un lecteur ou des lecteurs de bandes pris en charge par le système d'exploitation Microsoft Windows. Qui plus est, pour le lecteur de bande en question, nous vous conseillons d'utiliser uniquement des bandes recommandées par le fabricant du lecteur. Pour plus d'informations sur l'installation d'un lecteur de bande, veuillez vous reporter à la documentation du système d'exploitation Windows.

Avec un lecteur de bande, une opération de sauvegarde peut remplir une bande et se poursuivre sur une autre. Chaque bande contient un en-tête de support. Le premier support employé est la bande initiale. Chaque bande successive est une bande magnétique de sauvegarde consécutive, dotée d'un numéro de séquence supérieur d'une unité par rapport à la bande précédente. Par exemple, un support de sauvegarde associé à quatre périphériques à bandes contient au moins quatre bandes initiales (et, si la base de données ne tient pas dessus, quatre séries de bandes magnétiques de sauvegarde consécutive). Lorsque vous ajoutez un jeu de sauvegarde, vous devez monter la dernière bande de la série. Si la dernière bande n'est pas montée, le Moteur de base de données cherche jusqu'à la fin de la bande montée puis vous demande de changer de bande. À ce moment-là, montez la dernière bande.

Les unités de sauvegarde sur bande sont utilisées comme les unités de disques avec les exceptions suivantes :

Le périphérique à bandes doit être connecté physiquement à l'ordinateur qui exécute une instance de SQL Server. La sauvegarde sur des bandes à distance n'est pas prise en charge.
Si une unité de sauvegarde sur bande est remplie lors de l'opération de sauvegarde mais que davantage de données restent à écrire, SQL Server vous demande d'insérer une nouvelle bande et de poursuivre l'opération de sauvegarde après chargement d'une nouvelle bande.

Définition d'une bande de sauvegarde selon son nom physique (Transact-SQL)

La syntaxe BACKUP de base permettant de spécifier une bande de sauvegarde selon le nom d'unité physique du lecteur de bande est la suivante :

BACKUP { DATABASE | LOG } database_name

TO TAPE = { 'physical_backup_device_name' | **@**physical_backup_device_name_var }

Par exemple :

BACKUP LOG AdventureWorks2012 
   TO TAPE = '\\.\tape0';
GO

Pour spécifier une unité de bande physique dans une instruction RESTORE, la syntaxe de base est la suivante :

RESTORE { DATABASE | LOG } database_name

FROM TAPE = { 'physical_backup_device_name' | **@**physical_backup_device_name_var }

Options BACKUP et RESTORE spécifiques aux bandes (Transact-SQL)

Pour faciliter la gestion des bandes, l'instruction BACKUP fournit les options de bande suivantes :

{ NOUNLOAD | UNLOAD }

Vous pouvez contrôler si une bande de sauvegarde est déchargée automatiquement à partir du lecteur de bande après une opération de sauvegarde ou de restauration. UNLOAD/NOUNLOAD est un paramètre de session qui persiste pendant toute la durée de la session ou jusqu'à ce qu'elle soit réinitialisée en précisant une solution alternative.
{ REWIND | NOREWIND }

Vous pouvez contrôler si SQL Server laisse la bande ouverte après l'opération de sauvegarde ou de restauration ou bien libère et rembobine la bande une fois qu'elle est remplie. Le comportement par défaut est de rembobiner la bande (REWIND).

[!REMARQUE]

Pour plus d'informations sur la syntaxe et les arguments BACKUP, consultez BACKUP (Transact-SQL). Pour plus d'informations sur la syntaxe et les arguments RESTORE, consultez respectivement RESTORE (Transact-SQL) et Arguments RESTORE (Transact-SQL).

Gestion de bandes ouvertes

Pour afficher une liste des périphériques à bandes ouverts et l'état des demandes de montage, interrogez la vue de gestion dynamique sys.dm_io_backup_tapes. Cette vue affiche toutes les bandes ouvertes. Elle inclut les bandes en cours d'utilisation provisoirement inactives et en attente de la prochaine opération BACKUP ou RESTORE.

Si une bande a accidentellement été laissée ouverte, le moyen le plus rapide de la libérer consiste à utiliser la commande suivante : RESTORE REWINDONLY FROM TAPE = backup_device_name. Pour plus d'informations, consultez RESTORE REWINDONLY (Transact-SQL).

[Haut de la page]

Utilisation d'une unité de sauvegarde logique

Une unité de sauvegarde logique est un nom facultatif défini par l'utilisateur qui pointe sur une unité de sauvegarde physique spécifique (un fichier disque ou un lecteur de bande). Une unité de sauvegarde logique vous permet d'utiliser l'indirection au moment de référencer l'unité de sauvegarde physique correspondante.

La définition d'une unité de sauvegarde logique implique d'affecter un nom logique à une unité physique. Par exemple, vous pouvez définir une unité logique, AdventureWorksBackups, afin qu'elle pointe vers le fichier Z:\SQLServerBackups\AdventureWorks2012.bak ou le lecteur de bande \\. \tape0. Les commandes de sauvegarde et de restauration peuvent ensuite spécifier AdventureWorksBackups comme unité de sauvegarde au lieu de DISK = 'Z:\SQLServerBackups\AdventureWorks2012.bak' ou TAPE = '\\. \tape0'.

Le nom d'unité logique doit être unique parmi toutes les unités de sauvegarde logiques résidant sur l'instance de serveur. Pour afficher les noms d'unités logiques existantes, interrogez l'affichage catalogue sys.backup_devices. Cet affichage affiche le nom de chaque unité de sauvegarde logique et décrit le type et le nom de fichier physique ou le chemin d'accès de l'unité de sauvegarde physique correspondante.

Une fois définie une unité de sauvegarde logique, dans une commande BACKUP ou RESTORE, spécifiez l'unité de sauvegarde logique à la place du nom physique de l'unité. Par exemple, l'instruction suivante sauvegarde la base de données AdventureWorks2012 dans l'unité de sauvegarde logique AdventureWorksBackups.

BACKUP DATABASE AdventureWorks2012 
   TO AdventureWorksBackups;
GO

[!REMARQUE]

Dans une instruction BACKUP ou RESTORE spécifique, le nom de l'unité de sauvegarde logique et celui de l'unité de sauvegarde physique sont interchangeables.

Un avantage de l'unité de sauvegarde logique est sa plus grande simplicité d'utilisation par rapport à un chemin d'accès long. Le recours à une unité de sauvegarde logique peut être utile si vous envisagez d'écrire une série de sauvegardes dans le même chemin d'accès ou sur un lecteur de bande. Les unités de sauvegarde logiques s'avèrent particulièrement utiles pour l'identification des unités de sauvegarde sur bande.

Vous pouvez rédiger un script de sauvegarde pour l'utilisation d'une unité de sauvegarde logique spécifique. Vous pouvez ainsi passer à une nouvelle unité de sauvegarde physique sans modifier le script. Ce changement implique le processus suivant :

La suppression de l'unité de sauvegarde logique d'origine.
La définition d'une nouvelle unité de sauvegarde logique qui utilise le nom d'origine de l'unité mais mappe à une unité de sauvegarde physique différente. Les unités de sauvegarde logiques s'avèrent particulièrement utiles pour l'identification des unités de sauvegarde sur bande.

[Haut de la page]

Jeux de supports de sauvegarde en miroir

La mise en miroir des jeux de supports de sauvegarde permet de réduire l'impact des dysfonctionnements des unités de sauvegarde. Ces dysfonctionnements représentent une menace particulièrement sérieuse car une sauvegarde constitue la dernière protection possible contre une perte de données. À mesure que la taille des bases de données augmente, le risque de perte irrécupérable d'une sauvegarde suite à la défaillance d'une unité ou d'un support de sauvegarde se fait plus présent. La mise en miroir des supports de sauvegarde accroît la fiabilité des sauvegardes en permettant la redondance de l'unité de sauvegarde physique. Pour plus d'informations, consultez Jeux de supports de sauvegarde en miroir (SQL Server).

[!REMARQUE]

Les jeux de supports de sauvegarde en miroir sont uniquement pris en charge dans SQL Server 2005 Enterprise Edition et versions ultérieures.

[Haut de la page]

Archivage des sauvegardes SQL Server

Nous vous recommandons de recourir à un utilitaire de sauvegarde système des fichiers pour archiver les sauvegardes sur disque et stocker les archives hors site. L'avantage du disque est que vous pouvez utiliser le réseau pour écrire les sauvegardes archivées sur un disque hors site. Une bande présente l'avantage de pouvoir accumuler une série de sauvegardes archivées jusqu'à ce que vous soyez certain de ne plus en avoir besoin.

Une approche d'archivage courante consiste à écrire des sauvegardes SQL Server sur un disque de sauvegarde local, à les archiver sur des bandes, puis à stocker les bandes hors site.

[Haut de la page]