Unités de sauvegarde (SQL Server)

S’applique à :SQL Server

Pendant une opération de sauvegarde sur une base de données SQL Server, les données sauvegardées (la sauvegarde) sont écrites sur un périphérique 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 jeux multimédias, consultez Media Sets, Media Families et Backup Sets (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 du disque ou de la 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 sont très flexibles pour gérer les périphériques de sauvegarde de disque, car ils génèrent automatiquement un nom horodaté sur 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  

Note

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 que SQL Server accède à un fichier de disque distant, le compte de service SQL Server doit avoir 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 s’exécute :

  • Pour sauvegarder un lecteur réseau lorsque SQL Server s’exécute dans un compte d’utilisateur de domaine, le lecteur partagé doit être mappé en tant que lecteur réseau dans la session où SQL Server est en cours d’exécution. Si vous démarrez Sqlservr.exe à partir de la ligne de commande, SQL Server voit 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 session distincte qui n’a aucune relation 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

Note

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 nécessite que le lecteur de bande ou les lecteurs soient 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 analyse vers la fin de la bande montée, puis nécessite de modifier la 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 :

  • L’appareil de bande doit être connecté physiquement à l’ordinateur exécutant une instance de SQL Server. La sauvegarde sur des bandes à distance n'est pas prise en charge.

  • Si un périphérique de sauvegarde sur bande est rempli pendant l’opération de sauvegarde, mais que d’autres données doivent toujours être écrites, SQL Server demande une nouvelle bande et poursuit l’opération de sauvegarde après le 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 conserve la bande reste ouverte après l’opération de sauvegarde ou de restauration ou les mises en production et rembobine la bande après son remplissage. Le comportement par défaut est de rembobiner la bande (REWIND).

Note

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 les arguments RESTORE (Transact-SQL) et RESTORE (Transact-SQL), respectivement.

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 stockage Blob Azure. Pour plus d’informations sur l’utilisation du Stockage Blob Azure pour vos sauvegardes, consultez Sauvegarde et restauration SQL Server avec 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 appareil logique peut AdventureWorksBackupsêtre défini pour pointer vers le fichier ou le Z:\SQLServerBackups\AdventureWorks2022.bak\\.\tape0 lecteur de bande. Les commandes de sauvegarde et de restauration peuvent ensuite spécifier AdventureWorksBackups comme périphérique 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  

Note

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

Note

Les supports de sauvegarde en miroir sont pris en charge uniquement dans SQL Server 2005 Enterprise Edition 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. Stockage Blob Azure peut être utilisé comme option d’archivage hors site. Vous pouvez charger vos sauvegardes de disque ou écrire directement les sauvegardes dans Stockage Blob Azure.

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

Tâches connexes

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)