RESTORE (Transact-SQL)

SQL Server prend en charge un large éventail de scénarios de restauration :

• Restauration de base de données complète

  Restaure l'ensemble de la base de données ; commence par une sauvegarde de base de données complète, qui peut être suivie par la restauration d'une sauvegarde de base de données différentielle (et des sauvegardes du journal). Pour plus d'informations, consultez Réalisation d'une restauration de base de données complète (mode de récupération simple) ou Exécution d'une restauration de base de données complète (mode de restauration complète).

• Restauration de fichiers

  Restaure un fichier ou un groupe de fichiers dans une base de données de plusieurs groupes de fichiers. Notez qu'en mode de récupération simple, le fichier doit appartenir à un groupe de fichiers en lecture seule. Une fois que la restauration complète des fichiers a été effectuée, une sauvegarde différentielle des fichiers peut être restaurée. Pour plus d'informations, consultez Restauration de fichiers (mode de restauration complète) et Restauration de fichiers (mode de récupération simple).

• Restauration de pages

  Restaure des pages individuelles. La restauration de pages n'est disponible qu'en mode de récupération complète et en mode de récupération utilisant les journaux de transactions. Pour plus d'informations, consultez Restauration de pages.

• Restauration fragmentaire

  Restaure la base de données par étape ; commence avec le groupe de fichiers primaire et se poursuit avec un ou plusieurs des groupes de fichiers secondaires. Une restauration fragmentaire commence par une instruction RESTORE DATABASE utilisant l'option PARTIAL et spécifiant un ou plusieurs groupes de fichiers à restaurer. Pour plus d'informations, consultez Exécution d'une restauration fragmentaire.

• Récupération uniquement

  Récupère les données déjà cohérentes avec la base de données et qui doivent être disponibles. Pour plus d'informations, consultez Récupération d'une base de données sans restauration des données.

• Restauration du journal des transactions

  En mode de récupération complète ou en mode de récupération utilisant les journaux de transactions, la restauration des sauvegardes du journal est nécessaire pour atteindre le point de récupération souhaité. Pour plus d'informations sur la restauration des sauvegardes du journal, consultez Application de sauvegardes du journal des transactions.

• Créer une base de données miroir

  Pour plus d'informations, consultez Procédure : préparer une base de données miroir pour la mise en miroir (Transact-SQL).

• Créer et maintenir un serveur de secours. Pour plus d'informations sur les serveurs de secours, consultez Utilisation des serveurs de secours à chaud.

Les mots clés suivants ont été supprimés dans SQL Server 2008 :

Pour restaurer une base de données chiffrée, vous devez avoir accès au certificat ou à la clé asymétrique qui a servi à chiffrer la base de données. Sans le certificat et la clé asymétrique, la base de données ne peut pas être restaurée. En conséquence, le certificat utilisé pour chiffrer la clé de chiffrement de base de données doit être conservé tant que la sauvegarde est utile. Pour plus d'informations, consultez Certificats et clés asymétriques SQL Server.

Les sauvegardes et les restaurations fonctionnent correctement avec le format de stockage vardecimal. Pour plus d'informations sur le format de stockage vardecimal, consultez Stockage des données décimales sous forme de colonne de longueur variable.

La restauration est contrôlée par l'instruction RESTORE et les options [ RECOVERY | NORECOVERY ] :

• NORECOVERY indique que la restauration ne s'effectue pas. Cela permet la poursuite de la restauration par progression avec l'instruction suivante de la séquence.

  Dans ce cas, la séquence de restauration restaure d'autres sauvegardes, puis les restaure par progression.

• RECOVERY (valeur par défaut) indique que la restauration doit être effectuée après la restauration par progression de la sauvegarde actuelle.

  Pour récupérer la base de données, le jeu de données complet restauré (le jeu de restauration par progression) doit être cohérent par rapport à la base de données. Si la restauration par progression du jeu de restauration par progression n'est pas allée assez loin pour être cohérente par rapport à la base de données et si l'option RECOVERY est spécifiée, le Moteur de base de données génère une erreur.

Il n'est pas possible d'annuler les effets d'une restauration. Cependant, vous pouvez annuler les effets de la copie et de la restauration par progression des données en recommençant fichier par fichier. Pour recommencer, restaurez le fichier approprié et réeffectuez la restauration par progression. Par exemple, si vous avez accidentellement restauré trop de sauvegardes du journal et dépassé le point d'arrêt voulu, redémarrez la séquence.

Une séquence de restauration peut être annulée et redémarrée en restaurant l'ensemble du contenu des fichiers concernés.

Les données de texte intégral sont restaurées avec d'autres données de base de données lors d'une restauration complète. La syntaxe régulière RESTORE DATABASE database_name FROM backup_device permet de restaurer les fichiers de texte intégral comme des éléments faisant partie intégrante de la restauration de fichiers de base de données.

L'instruction RESTORE permet également d'effectuer des restaurations dans d'autres emplacements, des restaurations différentielles, des restaurations de fichiers et de groupes de fichiers, ainsi que des restaurations de fichiers et groupes de fichiers différentielles de données de texte intégral. En outre, cette instruction permet de restaurer des fichiers de texte intégral uniquement, ainsi que des données de base de données.

Lors d'une restauration, les valeurs de la plupart des options de base de données pouvant être définies avec ALTER DATABASE et en vigueur à la fin de la sauvegarde sont rétablies.

Cependant, l'utilisation de WITH RESTRICTED_USER annule ce comportement pour le paramètre de l'option d'accès utilisateur. Ce paramètre est toujours défini suivant une instruction RESTORE qui inclut l'option WITH RESTRICTED_USER.

SQL Server intègre des tables d'historique de sauvegarde et de restauration qui assurent le suivi des activités de sauvegarde et de restauration pour chaque instance de serveur. Lorsqu'une restauration est effectuée, les tables d'historique de sauvegarde sont également modifiées. Pour plus d'informations sur ces tables, consultez Visualisation des informations concernant les sauvegardes.

RESTORE LOG peut contenir une liste de fichiers pour permettre la création des fichiers lors de la restauration par progression. Elle est utilisée lorsque la sauvegarde du journal contient des enregistrements qui ont été écrits lorsqu'un fichier a été ajouté à la base de données.

Si la restauration en ligne est prise en charge et si la base de données est en ligne, les restaurations de fichiers et de pages s'effectuent automatiquement en ligne, ainsi que les restaurations du groupe de fichiers secondaire une fois la phase initiale de restauration fragmentaire effectuée.

Pour plus d'informations, consultez Réalisation de restauration en ligne.

Cette nouvelle fonctionnalité de SQL Server 2005 améliore la restauration partielle Microsoft SQL Server 2000. La restauration fragmentaire permet de restaurer des groupes de fichiers après avoir effectué une restauration partielle des groupes de fichiers primaires et de certains groupes de fichiers secondaires. Les groupes de fichiers qui ne sont pas restaurés sont marqués comme étant hors connexion et ne sont pas accessibles. Les groupes de fichiers hors connexion peuvent cependant être restaurés ultérieurement via une restauration de fichiers. Pour permettre la restauration de l'ensemble de la base de données par étape à des moments différents, la restauration fragmentaire effectue des contrôles pour garantir la cohérence finale de la base de données.

Si une séquence de restauration partielle exclut tout groupe de fichiers FILESTREAM, la restauration jusqu'à une date et heure n'est pas prise en charge. Vous pouvez imposer à la séquence de restauration de continuer. Toutefois, les groupes de fichiers FILESTREAM omis dans l'instruction RESTORE ne peuvent jamais être restaurés. Pour forcer une limite de restauration dans le temps, spécifiez l'option CONTINUE_AFTER_ERROR avec l'option STOPAT, STOPATMARK ou STOPBEFOREMARKx, que vous devez également spécifier dans vos instructions RESTORE LOG suivantes. Si vous spécifiez l'option CONTINUE_AFTER_ERROR, la séquence de restauration partielle réussit et le groupe de fichiers FILESTREAM devient irrécupérable.

Pour plus d'informations sur la restauration fragmentaire, consultez Exécution d'une restauration fragmentaire.

Une opération de rétablissement de base de données (spécifiée avec l'option DATABASE_SNAPSHOT) ramène une base de données source complète à un moment donné dans le temps, en rétablissant la capture instantanée de base de données de cet instant-là, c'est-à-dire en remplaçant la base de données source par les données correspondant à une date et heure précise dans la capture instantanée de base de données spécifiée. Seule la capture instantanée vers laquelle vous effectuez le rétablissement peut exister. Cette opération reconstruit ensuite le journal (par conséquent, vous ne pouvez pas effectuer une restauration par progression d'une base de données rétablie au point d'erreur de l'utilisateur).

La perte de données est limitée aux mises à jour de la base de données depuis la création de la capture instantanée. Les métadonnées d'une base de données rétablie sont identiques aux métadonnées au moment de la création de la capture instantanée. Toutefois, le retour à une capture instantanée supprime tous les catalogues de texte intégral.

Le rétablissement à partir d'une capture instantanée de base de données n'est pas destiné à la récupération des supports. Contrairement à un jeu de sauvegarde classique, l'instantané de base de données est une copie incomplète des fichiers de la base de données. Si la base de données ou la capture instantanée est endommagée, le rétablissement à partir d'une capture instantanée sera probablement impossible. En outre, même lorsque le rétablissement est possible, il est peu probable qu'il permette de corriger le problème en cas de dommages.

Restrictions liées au rétablissement

L'exemple suivant restaure une sauvegarde de base de données complète à partir de l'unité de sauvegarde logique AdventureWorks2008R2Backups. Pour voir un exemple de création de cette unité, consultez Unités de sauvegarde.

RESTORE DATABASE AdventureWorks2008R2 
   FROM AdventureWorks2008R2Backups

[Début des exemples]

L'exemple suivant restaure une sauvegarde de base de données complète, puis une sauvegarde différentielle, à partir de l'unité de sauvegarde Z:\SQLServerBackups\AdventureWorks2008R2.bak qui contient les deux sauvegardes. La sauvegarde de base de données complète à restaurer correspond au sixième jeu de sauvegarde se trouvant sur l'unité (FILE = 6), tandis que la sauvegarde de base de données différentielle correspond au neuvième jeu de sauvegarde se trouvant sur l'unité (FILE = 9). Une fois la sauvegarde différentielle récupérée, la récupération de la base de données est terminée.

RESTORE DATABASE AdventureWorks2008R2
   FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2008R2.bak'
   WITH FILE = 6
      NORECOVERY;
RESTORE DATABASE AdventureWorks2008R2
   FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2008R2.bak'
   WITH FILE = 9
      RECOVERY;

[Début des exemples]

Dans l'exemple suivant, l'option RESTART est utilisée pour redémarrer une opération RESTORE interrompue par une coupure de courant sur le serveur.

-- This database RESTORE halted prematurely due to power failure.
RESTORE DATABASE AdventureWorks2008R2
   FROM AdventureWorks2008R2Backups
-- Here is the RESTORE RESTART operation.
RESTORE DATABASE AdventureWorks2008R2 
   FROM AdventureWorks2008R2Backups WITH RESTART

[Début des exemples]

L'exemple suivant restaure l'intégralité d'une base de données et de son journal des transactions, puis déplace la base de données restaurée vers le répertoire C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Data.

RESTORE DATABASE AdventureWorks2008R2
   FROM AdventureWorks2008R2Backups
   WITH NORECOVERY, 
      MOVE 'AdventureWorks2008R2_Data' TO 
'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Data\NewAdvWorks2008R2.mdf', 
      MOVE 'AdventureWorks2008R2_Log' 
TO 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Data\NewAdvWorks2008R2.ldf'
RESTORE LOG AdventureWorks2008R2
   FROM AdventureWorks2008R2Backups
   WITH RECOVERY

[Début des exemples]

L'exemple suivant utilise à la fois les instructions BACKUP et RESTORE pour effectuer une copie de la base de données AdventureWorks2008R2. L'instruction MOVE entraîne la restauration des données et du fichier journal aux emplacements spécifiés. L'instruction RESTORE FILELISTONLY permet de déterminer le nombre et le nom des fichiers de la base de données en cours de restauration. La nouvelle copie de la base de données s'appelle TestDB. Pour plus d'informations, consultez RESTORE FILELISTONLY (Transact-SQL).

BACKUP DATABASE AdventureWorks2008R2 
   TO AdventureWorks2008R2Backups ;

RESTORE FILELISTONLY 
   FROM AdventureWorks2008R2Backups ;

RESTORE DATABASE TestDB 
   FROM AdventureWorks2008R2Backups 
   WITH MOVE 'AdventureWorks2008R2_Data' TO 'C:\MySQLServer\testdb.mdf',
   MOVE 'AdventureWorks2008R2_Log' TO 'C:\MySQLServer\testdb.ldf';
GO

[Début des exemples]

L'exemple suivant restaure une base de données dans l'état où elle se trouvait le April 15, 2020 à 12:00 AM et décrit une opération de restauration impliquant plusieurs sauvegardes de fichiers journaux. Sur l'unité de sauvegarde AdventureWorks2008R2Backups, la sauvegarde de base de données complète à restaurer correspond au troisième jeu de sauvegarde (FILE = 3), la première sauvegarde de fichier journal correspond au quatrième jeu de sauvegarde (FILE = 4) et la seconde sauvegarde de fichier journal correspond au cinquième jeu de sauvegarde (FILE = 5).

RESTORE DATABASE AdventureWorks2008R2
   FROM AdventureWorks2008R2Backups
   WITH FILE=3, NORECOVERY;

RESTORE LOG AdventureWorks2008R2
   FROM AdventureWorks2008R2Backups
   WITH FILE=4, NORECOVERY, STOPAT = 'Apr 15, 2020 12:00 AM';

RESTORE LOG AdventureWorks2008R2
   FROM AdventureWorks2008R2Backups
   WITH FILE=5, NORECOVERY, STOPAT = 'Apr 15, 2020 12:00 AM';
RESTORE DATABASE AdventureWorks2008R2 WITH RECOVERY; 

[Début des exemples]

L'exemple suivant restaure le journal des transactions jusqu'à la marque dans la transaction marquée nommée ListPriceUpdate.

USE AdventureWorks2008R2;
GO
BEGIN TRANSACTION ListPriceUpdate
   WITH MARK 'UPDATE Product list prices';
GO

UPDATE Production.Product
   SET ListPrice = ListPrice * 1.10
   WHERE ProductNumber LIKE 'BK-%';
GO

COMMIT TRANSACTION ListPriceUpdate;
GO

-- Time passes. Regular database 
-- and log backups are taken.
-- An error occurs in the database.
USE master
GO

RESTORE DATABASE AdventureWorks2008R2
FROM AdventureWorks2008R2Backups
WITH FILE = 3, NORECOVERY;
GO

RESTORE LOG AdventureWorks2008R2
   FROM AdventureWorks2008R2Backups 
   WITH FILE = 4,
   RECOVERY, 
   STOPATMARK = 'UPDATE Product list prices';

[Début des exemples]

L'exemple suivant restaure une sauvegarde de base de données complète à partir d'une unité de sauvegarde TAPE.

RESTORE DATABASE AdventureWorks2008R2 
   FROM TAPE = '\\.\tape0'

[Début des exemples]

L'exemple suivant restaure une base de données nommée MyDatabase qui est composée de deux fichiers, d'un groupe de fichiers secondaire et d'un journal des transactions. La base de données utilise le mode de récupération complète.

La sauvegarde de la base de données est le neuvième jeu de sauvegarde dans le support de sauvegarde sur une unité de sauvegarde logique nommée MyDatabaseBackups. Trois sauvegardes de fichier journal, qui se trouvent dans les trois jeux de sauvegarde suivants (10, 11 et 12) sur l'unité MyDatabaseBackups sont ensuite restaurés à l'aide de WITH NORECOVERY. Une fois restaurée la dernière sauvegarde de fichier journal, la base de données est récupérée.

Dans l'instruction RESTORE DATABASE, il existe deux types d'options FILE. Les options FILE qui précèdent le nom de l'unité de sauvegarde spécifient les noms de fichiers logiques des fichiers de base de données à restaurer à partir du jeu de sauvegarde, par exemple FILE = 'MyDatabase_data_1'. Ce jeu de sauvegarde n'est pas la première sauvegarde de base de données dans le support de sauvegarde. Par conséquent, sa position dans le support de sauvegarde est indiquée via l'option FILE dans la clause WITH, en l'occurrence FILE=9.

RESTORE DATABASE MyDatabase
   FILE = 'MyDatabase_data_1',
   FILE = 'MyDatabase_data_2',
   FILEGROUP = 'new_customers'
   FROM MyDatabaseBackups
   WITH 
      FILE = 9,
      NORECOVERY;
GO
-- Restore the log backups.
RESTORE LOG MyDatabase
   FROM MyDatabaseBackups
   WITH FILE = 10, 
      NORECOVERY;
GO
RESTORE LOG MyDatabase
   FROM MyDatabaseBackups
   WITH FILE = 11, 
      NORECOVERY;
GO
RESTORE LOG MyDatabase
   FROM MyDatabaseBackups
   WITH FILE = 12, 
      NORECOVERY;
GO
--Recover the database:
RESTORE DATABASE MyDatabase WITH RECOVERY;
GO

[Début des exemples]

L'exemple suivant rétablit un instantané de base de données. Il part du principe qu'une seule capture instantanée existe actuellement dans la base de données. Pour obtenir un exemple de création de cette capture instantanée de base de données, consultez Procédure : créer un instantané de base de données (Transact-SQL).

USE master  
RESTORE DATABASE AdventureWorks2008R2 FROM DATABASE_SNAPSHOT = 'AdventureWorks2008R2_dbss1800';
GO

Pour plus d'informations, consultez Retour à une capture instantanée de base de données.

[Début des exemples]