Partage via

Unités de sauvegarde (SQL Server)

  • Article

S’applique à : SQL Server

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.

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 supports de sauvegarde, 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).

Les sauvegardes SQL Server peuvent également être écrites dans Stockage Blob Azure, en plus d’un disque ou d’une bande.

Utilisation d’unités de sauvegarde sur disque

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 d’administration SQL Server offrent une excellente souplesse de gestion des unités de sauvegarde sur disque, car 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.

Si les fichiers de base de données et les fichiers de sauvegarde sont placés sur le même périphérique et que ce dernier échoue, la base de données et ses sauvegardes ne sont pas disponibles. De la même manière, le fait de placer les fichiers de base de données et les fichiers de sauvegarde sur des périphériques distincts optimise les performances d'E/S pour l'utilisation en production de la base de données et l'écriture des sauvegardes.

Définir 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 nom_base_de_données

TO DISK = { ’nom_unité_sauvegarde_physique’ | @nom_unité_sauvegarde_physique_var }

Par exemple :

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

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

RESTORE { DATABASE | LOG } nom_base_de_données

FROM DISK = { ’nom_unité_sauvegarde_physique’ | @nom_unité_sauvegarde_physique_var }

Par exemple,

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

Spécifier le chemin d’accès du 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. Ce 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\MSSQL13.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 AdventureWorks2022 dans le répertoire de sauvegarde par défaut.

BACKUP DATABASE AdventureWorks2022   
   TO DISK = 'AdventureWorks2022.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.

Sauvegarder sur un partage de fichiers 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éfinir un nom UNC (Universal Naming Convention)

Pour préciser un partage réseau dans une opération de sauvegarde ou de restauration, utilisez le nom UNC (Universal Naming Convention) complet du fichier de l’unité de sauvegarde. Un nom UNC se présente sous la forme \\nom_système\nom_partage\chemin\nom_fichier.

Par exemple :

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

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 utilisent actuellement cette fonctionnalité.

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éfinir 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 } nom_base_de_données

TO TAPE = { ’nom_unité_sauvegarde_physique’ | @nom_unité_sauvegarde_physique_var }

Par exemple :

BACKUP LOG AdventureWorks2022   
   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 } nom_base_de_données

FROM TAPE = { ’nom_unité_sauvegarde_physique’ | @nom_unité_sauvegarde_physique }

Options BACKUP et RESTORE propres 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 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.

  • { 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 de BACKUP, consultez BACKUP (Transact-SQL). Pour plus d’informations sur la syntaxe et les arguments de RESTORE, consultez respectivement RESTORE (Transact-SQL) et RESTORE, arguments (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 été laissée ouverte par erreur, le moyen le plus rapide de la libérer consiste à utiliser la commande suivante : RESTORE REWINDONLY FROM TAPE =nom_unité_sauvegarde. Pour plus d’informations, consultez RESTORE REWINDONLY (Transact-SQL).

Utilisation du Stockage Blob Azure

Les sauvegardes SQL Server peuvent être écrites dans le Stockage Blob Azure. Pour plus d’informations sur la façon d’utiliser le Stockage Blob Azure pour les sauvegardes, consultez Sauvegarde et restauration SQL Server avec le Stockage Blob Microsoft Azure.

Utiliser une unité logique de sauvegarde

Une unité de sauvegarde logique est un nom facultatif défini par l’utilisateur qui pointe vers 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, un périphérique logique, AdventureWorksBackups, peut être défini pour pointer vers le fichier Z:\SQLServerBackups\AdventureWorks2022.bak ou le lecteur de bande \\.\tape0. Les commandes de sauvegarde et de restauration peuvent alors spécifier AdventureWorksBackups comme unité de sauvegarde, au lieu de DISK = 'Z:\SQLServerBackups\AdventureWorks2022.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 AdventureWorks2022 dans l'unité de sauvegarde logique AdventureWorksBackups .

BACKUP DATABASE AdventureWorks2022   
   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 :

  1. La suppression de l'unité de sauvegarde logique d'origine.

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

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 l’édition Enterprise de SQL Server 2005 et versions ultérieures.

Archiver 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. Le Stockage Blob Azure peut être utilisé comme option d’archivage hors site. Chargez les sauvegardes sur disque ou écrivez directement les sauvegardes dans Stockage Blob Azure.

Une autre 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.

Tâches associées

Pour spécifier une unité de disque (SQL Server Management Studio)

Pour spécifier un périphérique à bandes (SQL Server Management Studio)

Pour définir une unité logique de sauvegarde

Pour utiliser une unité logique de sauvegarde

Pour afficher des informations sur les unités de sauvegarde

Pour supprimer une unité logique de sauvegarde

Voir aussi

SQL Server, objet Backup Device
BACKUP (Transact-SQL)
Plans de maintenance
Jeux de supports, familles de supports et jeux de sauvegarde (SQL Server)
RESTORE (Transact-SQL)
RESTORE LABELONLY (Transact-SQL)
sys.backup_devices (Transact-SQL)
sys.dm_io_backup_tapes (Transact-SQL)
Jeux de supports de sauvegarde en miroir (SQL Server)