Unités de sauvegarde
Au cours d'une opération de sauvegarde, les données sauvegardées (la sauvegarde) sont écrites sur une unité de sauvegarde physique. Une unité de sauvegarde physique est 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).
[!REMARQUE]
L'unité de sauvegarde physique est activée dès l'écriture de la première sauvegarde dans un support de sauvegarde. Les sauvegardes dans un ensemble d'une ou plusieurs unités de sauvegarde forment un seul support de sauvegarde. Un support de sauvegarde est un ensemble ordonné de supports de sauvegarde, de bandes ou de 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 Supports, familles et jeux de sauvegarde.
Utilisation d'unités de sauvegarde sur disque
Une unité de sauvegarde sur disque est un 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.
Si un fichier disque se remplit pendant qu'une opération de sauvegarde ajoute une sauvegarde au support de sauvegarde, 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
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' | **@**physical_backup_device_name_var }
Par exemple :
BACKUP DATABASE AdventureWorks
TO DISK = 'Z:\SQLServerBackups\AdventureWorks.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' | **@**physical_backup_device_name_var }
Par exemple :
RESTORE DATABASE AdventureWorks
FROM DISK = 'Z:\SQLServerBackups\AdventureWorks.bak';
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. Ce répertoire de sauvegarde par défaut est C:\Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\Backup, où n est le nombre de l'instance du serveur. Par conséquent, pour l'instance du serveur par défaut, le répertoire de sauvegarde par défaut est le suivant : C:\Program Files\Microsoft SQL Server\MSSQL10.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 AdventureWorks dans le fichier de sauvegarde AdventureWorks.bak dans le répertoire de sauvegarde par défaut.
BACKUP DATABASE AdventureWorks
TO DISK = ’AdventureWorks.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.
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 Vérification des sauvegardes.
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 \\nom_système\nom_partage\chemin\nom_fichier.
Par exemple :
BACKUP DATABASE AdventureWorks
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éesmoteur 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.
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 **=**nom_unité_sauvegarde. Pour plus d'informations, consultez RESTORE REWINDONLY (Transact-SQL).
Définition d'une bande de sauvegarde selon son nom physique
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' | **@**physical_backup_device_name_var }
Par exemple :
BACKUP LOG AdventureWorks
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' | **@**physical_backup_device_name_var }
Options BACKUP et RESTORE spécifiques aux bandes
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).
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 sur le fichier Z:\SQLServerBackups\AdventureWorks.bak ou le lecteur de bande \\.\tape0 tape. Les commandes de sauvegarde et de restauration peuvent ensuite spécifier AdventureWorksBackups comme unité de sauvegarde au lieu de DISK = 'Z:\SQLServerBackups\AdventureWorks.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 AdventureWorks dans l'unité de sauvegarde logique AdventureWorksBackups.
BACKUP DATABASE AdventureWorks
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.
Pour définir une unité logique de sauvegarde
BackupDevice (SMO)
Pour supprimer une unité logique de sauvegarde
Pour utiliser une unité logique de sauvegarde (SQL Server Management Studio)
Procédure : sauvegarder une base de données (SQL Server Management Studio)
Procédure : restaurer une sauvegarde à partir d'une unité (SQL Server Management Studio)
Pour utiliser une unité logique de sauvegarde (Transact-SQL)
Supports de sauvegarde en miroir
La mise en miroir des 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 Utilisation de supports de sauvegarde miroirs.
[!REMARQUE]
Les supports de sauvegarde en miroir sont uniquement pris en charge dans SQL Server 2005 Enterprise Edition et versions ultérieures.
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.
Voir aussi