Partager via

RESTORE (Transact-SQL)

  • Article

Restaure les sauvegardes réalisées à l'aide de la commande BACKUP. Cette commande vous permet d'effectuer les scénarios de restauration suivants :

  • Restaurer une base de données complète à partir d'une sauvegarde de base de données complète (restauration complète)

  • Restaurer une partie d'une base de données (restauration partielle)

  • Restaurer des fichiers ou des groupes de fichiers spécifiques dans une base de données (restauration de fichiers)

  • Restaurer des pages spécifiques dans une base de données (restauration de pages)

  • Restaurer un journal des transactions dans une base de données (restauration de journal des transactions)

  • Rétablir une base de données au point d'instantané de base de données.

Pour plus d'informations sur les scénarios de restauration SQL Server, consultez Vue d'ensemble de la restauration et de la récupération (SQL Server).

[!REMARQUE]

Pour plus d'informations sur les descriptions des arguments, consultez Arguments RESTORE (Transact-SQL).

[!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 Améliorations de la sauvegarde et de la restauration et Sauvegarde et restauration SQL Server avec le service de stockage d'objets blob Windows Azure.

Icône Lien de rubrique Conventions de la syntaxe Transact-SQL

Syntaxe

--To Restore an Entire Database from a Full database backup (a Complete Restore):
RESTORE DATABASE { database_name | @database_name_var } 
 [ FROM <backup_device> [ ,...n ] ]
 [ WITH 
   {
    [ RECOVERY | NORECOVERY | STANDBY = 
        {standby_file_name | @standby_file_name_var } 
       ]
   | ,  <general_WITH_options> [ ,...n ]
   | , <replication_WITH_option>
   | , <change_data_capture_WITH_option>
   | , <FILESTREAM_WITH_option>
   | , <service_broker_WITH options> 
   | , <point_in_time_WITH_options—RESTORE_DATABASE> 
   } [ ,...n ]
 ]
[;]

--To perform the first step of the initial restore sequence 
-- of a piecemeal restore:
RESTORE DATABASE { database_name | @database_name_var } 
   <files_or_filegroups> [ ,...n ]
 [ FROM <backup_device> [ ,...n ] ] 
   WITH 
      PARTIAL, NORECOVERY 
      [  , <general_WITH_options> [ ,...n ] 
       | , <point_in_time_WITH_options—RESTORE_DATABASE> 
      ] [ ,...n ] 
[;]

--To Restore Specific Files or Filegroups: 
RESTORE DATABASE { database_name | @database_name_var } 
   <file_or_filegroup> [ ,...n ]
 [ FROM <backup_device> [ ,...n ] ] 
   WITH 
   {
      [ RECOVERY | NORECOVERY ]
      [ , <general_WITH_options> [ ,...n ] ]
   } [ ,...n ] 
[;]

--To Restore Specific Pages: 
RESTORE DATABASE { database_name | @database_name_var } 
   PAGE = 'file:page [ ,...n ]' 
 [ , <file_or_filegroups> ] [ ,...n ]
 [ FROM <backup_device> [ ,...n ] ] 
   WITH 
       NORECOVERY   
      [ , <general_WITH_options> [ ,...n ] ]
[;]

--To Restore a Transaction Log:
RESTORE LOG { database_name | @database_name_var } 
 [ <file_or_filegroup_or_pages> [ ,...n ] ]
 [ FROM <backup_device> [ ,...n ] ] 
 [ WITH 
   {
     [ RECOVERY | NORECOVERY | STANDBY = 
        {standby_file_name | @standby_file_name_var } 
       ]
    | ,  <general_WITH_options> [ ,...n ]
    | , <replication_WITH_option>
    | , <point_in_time_WITH_options—RESTORE_LOG> 
   } [ ,...n ]
 ] 
[;]

--To Revert a Database to a Database Snapshot:   
RESTORE DATABASE { database_name | @database_name_var } 
FROM DATABASE_SNAPSHOT = database_snapshot_name  

<backup_device>::=
{ 
   { logical_backup_device_name |
      @logical_backup_device_name_var }
 | { DISK | TAPE } = { 'physical_backup_device_name' |
      @physical_backup_device_name_var } 
} 

<files_or_filegroups>::= 
{ 
   FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var } 
 | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } 
 | READ_WRITE_FILEGROUPS
} 

<general_WITH_options> [ ,...n ]::=  
--Restore Operation Options
   MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name' 
          [ ,...n ] 
 | REPLACE 
 | RESTART 
 | RESTRICTED_USER 

--Backup Set Options
 | FILE = { backup_set_file_number | @backup_set_file_number } 
 | PASSWORD = { password | @password_variable } 

--Media Set Options
 | MEDIANAME = { media_name | @media_name_variable } 
 | MEDIAPASSWORD = { mediapassword | @mediapassword_variable } 
 | BLOCKSIZE = { blocksize | @blocksize_variable } 

--Data Transfer Options
 | BUFFERCOUNT = { buffercount | @buffercount_variable } 
 | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

--Error Management Options
 | { CHECKSUM | NO_CHECKSUM } 
 | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR } 

--Monitoring Options
 | STATS [ = percentage ] 

--Tape Options
 | { REWIND | NOREWIND } 
 | { UNLOAD | NOUNLOAD } 
  
<replication_WITH_option>::=
 | KEEP_REPLICATION 

<change_data_capture_WITH_option>::=
 | KEEP_CDC

<FILESTREAM_WITH_option>::=
 | FILESTREAM ( DIRECTORY_NAME = directory_name )


<service_broker_WITH_options>::= 
 | ENABLE_BROKER 
 | ERROR_BROKER_CONVERSATIONS 
 | NEW_BROKER 


<point_in_time_WITH_options—RESTORE_DATABASE>::= 
 | {
   STOPAT = { 'datetime'| @datetime_var } 
 | STOPATMARK = 'lsn:lsn_number'
                 [ AFTER 'datetime'] 
 | STOPBEFOREMARK = 'lsn:lsn_number'
                 [ AFTER 'datetime'] 
   } 

<point_in_time_WITH_options—RESTORE_LOG>::= 
 | {
   STOPAT = { 'datetime'| @datetime_var } 
 | STOPATMARK = { 'mark_name' | 'lsn:lsn_number' }
                 [ AFTER 'datetime'] 
 | STOPBEFOREMARK = { 'mark_name' | 'lsn:lsn_number' }
                 [ AFTER 'datetime'] 
   }

Arguments

Pour obtenir une description des arguments, consultez Arguments RESTORE (Transact-SQL).

À propos des scénarios de restauration

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

Considérations supplémentaires à propos des options RESTORE

Mots clés RESTORE supprimés

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

Mot clé supprimé

Remplacé par…

Exemple de mot clé de remplacement

LOAD

RESTORE

RESTORE DATABASE

TRANSACTION

LOG

RESTORE LOG

DBO_ONLY

RESTRICTED_USER

RESTORE DATABASE ... WITH RESTRICTED_USER

RESTORE LOG

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.

[!REMARQUE]

Pour une base de données en mode de récupération complète ou en mode de récupération utilisant les journaux de transactions, vous devez dans la plupart des cas effectuer une sauvegarde de la fin du journal, avant la restauration de la base de données. Restaurer une base de données sans effectuer une sauvegarde de la fin du journal au préalable entraîne une erreur, sauf si l'instruction RESTORE DATABASE contient la clause WITH REPLACE ou WITH STOPAT, qui doit spécifier une heure ou une transaction qui s'est produite après la fin de la sauvegarde des données. Pour plus d'informations sur les sauvegardes de la fin du journal, consultez Sauvegardes de la fin du journal (SQL Server).

Comparaison entre RECOVERY et NORECOVERY

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.

Prise en charge de la compatibilité

Dans SQL Server 2012, vous pouvez restaurer une base de données utilisateur à partir d'une sauvegarde de base de données créée à l'aide de SQL Server 2005 ou version ultérieure. Cependant, les sauvegardes des bases de données master, model et msdb créées avec SQL Server 2005 ou SQL Server 2008 ne peuvent pas être restaurées par SQL Server 2012. Par ailleurs, les sauvegardes créées dans SQL Server 2012 ne peuvent pas être restaurées par les versions antérieures de SQL Server.

[!REMARQUE]

Aucune sauvegarde SQL Server ne peut restaurée dans une version de SQL Server antérieure à celle sur laquelle la sauvegarde a été créée.

SQL Server 2012 utilise un chemin d'accès par défaut différent de celui des versions précédentes. Par conséquent, pour restaurer une base de données créée à l'emplacement par défaut des sauvegardes SQL Server 2005 ou SQL Server 2008, vous devez utiliser l'option MOVE. Pour plus d'informations sur le nouveau chemin par défaut, consultez Emplacements des fichiers pour les instances par défaut et les instances nommées de SQL Server.

Après avoir restauré une base de données SQL Server 2005 ou SQL Server 2008 dans SQL Server 2012, la base de données est automatiquement mise à niveau. En général, la base de données est immédiatement disponible. Toutefois, si une base de données SQL Server 2005 comprend des index de recherche en texte intégral, la mise à niveau les importe, les réinitialise ou les régénère, selon le paramètre de la propriété de serveur upgrade_option. Si l'option de mise à niveau a la valeur Importer (upgrade_option = 2) ou Reconstruire (upgrade_option = 0), les index de recherche en texte intégral ne seront pas disponibles pendant la mise à niveau. Selon le volume de données indexé, l'importation peut prendre plusieurs heures et la reconstruction jusqu'à dix fois plus longtemps. Notez également que lorsque l'option de mise à niveau est Importer, les index de recherche en texte intégral associés sont reconstruits si aucun catalogue de texte intégral n'est disponible. Pour modifier le paramètre de la propriété de serveur upgrade_option, utilisez sp_fulltext_service.

Lorsqu'une base de données est attachée ou restaurée pour la première fois à une nouvelle instance de SQL Server, une copie de la clé principale de la base de données (chiffrée par la clé principale du service) n'est pas encore stockée sur le serveur. Vous devez utiliser l'instruction OPEN MASTER KEY pour déchiffrer la clé principale de la base de données (DMK). Une fois la clé DMK déchiffrée, vous avez la possibilité d'activer le déchiffrement automatique dans le futur en exécutant l'instruction ALTER MASTER KEY REGENERATE pour fournir au serveur une copie de la clé DMK chiffrée avec la clé principale du service (SMK). Lorsqu'une base de données a été mise à niveau à partir d'une version antérieure, la clé DMK doit être régénérée de façon à utiliser le nouvel algorithme AES. Pour plus d'informations sur la régénération de la clé DMK, consultez ALTER MASTER KEY (Transact-SQL). La durée nécessaire pour régénérer la clé DMK à mettre à niveau vers AES dépend du nombre d'objets protégés par la clé DMK. La régénération de la clé DMK à mettre à niveau vers AES est nécessaire une seule fois et n'a aucune incidence sur les régénérations ultérieures effectuées dans le cadre d'une stratégie de rotation de clés.

Remarques d'ordre général

Lors d'une restauration hors ligne, si la base de données spécifiée est en cours d'utilisation, RESTORE force la déconnexion des utilisateurs après un court délai. Pour la restauration en ligne d'un groupe de fichiers non primaire, la base de données peut rester active, sauf si le groupe de fichiers restaurés est hors ligne. Toutes les données que la base contient sont remplacées par les données restaurées.

Pour plus d'informations sur la récupération d'une base de données, consultez Vue d'ensemble de la restauration et de la récupération (SQL Server).

Les opérations de restauration inter-plateformes, impliquant éventuellement des types de processeurs différents, peuvent être réalisées tant que le classement de la base de données est pris en charge par le système d'exploitation.

La commande RESTORE peut être redémarrée après une erreur. En outre, vous pouvez contraindre la commande RESTORE à poursuivre son traitement en dépit des erreurs. Elle restaure ainsi le plus de données possible (voir l'option CONTINUE_AFTER_ERROR).

La commande RESTORE n'est pas autorisée dans une transaction explicite ou implicite.

La restauration d'une base de données MASTER endommagée est réalisée à l'aide d'une procédure spéciale. Pour plus d'informations, consultez Sauvegarder et restaurer des bases de données système (SQL Server).

La restauration d'une base de données efface le cache de plan pour l'instance de SQL Server. Cette opération entraîne la recompilation de tous les plans d'exécution ultérieurs et peut entraîner une baisse temporaire et brutale des performances des requêtes. Dans le cadre de SQL Server 2005 Service Pack 2, pour chaque mémoire cache effacée du cache du plan, le journal des erreurs de SQL Server contient le message d'information suivant : "SQL Server a rencontré %d occurrence(s) de vidages de mémoire cache pour la mémoire cache '%s' (partie du cache du plan) en raison d'opérations de maintenance ou de reconfiguration de base de données. Ce message est enregistré toutes les cinq minutes si le cache est vidé au cours de cet intervalle de temps.

Pour restaurer une base de données de disponibilité, restaurez d'abord la base de données en tant qu'instance SQL Server, puis ajoutez la base de données au groupe de disponibilité.

Interopérabilité

Paramètres de bases de données et restauration

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.

Restauration d'une base de données chiffrée

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

Restauration d'une base de données activée pour le stockage vardecimal

Les sauvegardes et les restaurations fonctionnent correctement avec le format de stockage vardecimal. Pour plus d'informations sur le format de stockage vardecimal, consultez sp_db_vardecimal_storage_format (Transact-SQL).

Restauration de données de texte intégral

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.

[!REMARQUE]

Les catalogues de texte intégral importés à partir de SQL Server 2005 sont toujours traités en tant que fichiers de base de données. Pour ceux-ci, la procédure SQL Server 2005 de sauvegarde des catalogues de texte intégral reste applicable, mais la suspension et la reprise en cours de sauvegarde ne sont plus nécessaires. Pour plus d'informations, consultez Sauvegarde et restauration de catalogues de texte intégral dans la documentation en ligne de SQL Server 2005.

Métadonnées

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 Historique de sauvegarde et informations d'en-tête (SQL Server).

Impact de l'option REPLACE

L'option REPLACE ne doit être utilisée que rarement et après un examen attentif. Généralement, la restauration empêche le remplacement accidentel d'une base de données par une autre. Si la base de données nommée dans l'instruction RESTORE existe déjà sur le serveur actif et que le GUID de famille de la base de données spécifié ne correspond pas à celui qui est enregistré dans le jeu de sauvegarde, la base de données n'est pas restaurée. Cette mesure de sécurité est très importante,

L'option REPLACE annule d'importants contrôles de sécurité normalement effectués lors d'une restauration. Ces contrôles ignorés sont les suivants :

  • Restauration par remplacement d'une base de données existante par une sauvegarde d'une autre base de données.

    Avec l'option REPLACE, la restauration vous permet de remplacer une base de données existante par la base de données figurant dans le jeu de sauvegarde, même si le nom de base de données spécifié diffère de celui enregistré dans le jeu en question. Cela peut entraîner un remplacement accidentel d'une base de données par une autre.

  • Restauration par remplacement d'une base de données à l'aide du mode de restauration complète ou du mode de récupération utilisant les journaux de transactions quand une sauvegarde de la fin du journal n'a pas été réalisée et quand l'option STOPAT n'est pas employée.

    Avec l'option REPLACE, vous pouvez perdre des transactions déjà validées du fait que le dernier journal écrit n'a pas été sauvegardé.

  • Remplacement des fichiers existants

    Par exemple, une erreur peut entraîner le remplacement des fichiers existants d'un type incorrect (par exemple, fichiers .xls) ou de fichiers actuellement utilisés par une autre base de données qui n'est pas en ligne. Une perte de données arbitraire peut avoir lieu si des fichiers existants sont remplacés, même si la base de données restaurée est complète.

Rétablir une restauration

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.

Restauration d'une base de données vers un instantané de base de données

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 l'instantané 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 l'instantané de base de données spécifié. Seul l'instantané vers lequel 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 l'instantané. 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 l'instantané. Toutefois, le retour à un instantané supprime tous les catalogues de texte intégral.

Le rétablissement à partir d'un instantané de base de données n'est pas destiné à la récupération des supports. Contrairement à un jeu de sauvegarde régulier, 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 l'instantané est endommagé, le rétablissement à partir d'un instantané 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

Le rétablissement n'est pas pris en charge dans les conditions suivantes :

  • La base de données source contient des groupes de fichiers compressés ou en lecture seule.

  • Des fichiers sont hors connexion alors qu'ils étaient en ligne lors de la création de l'instantané.

  • Il existe plus d'un instantané de la base de données.

Pour plus d'informations, consultez Rétablir une base de données dans l'état d'un instantané de base de données.

Sécurité

Une opération de sauvegarde peut éventuellement spécifier des mots de passe pour un support de sauvegarde, un jeu de sauvegarde ou les deux. Si un mot de passe est défini dans un support de sauvegarde ou un jeu de sauvegarde, vous devez spécifier le ou les mots de passe appropriés dans l'instruction RESTORE. Ces mots de passe empêchent les opérations non autorisées de restauration et d'ajouts de jeux de sauvegarde au support par le biais des outils SQL Server. Cependant, les supports protégés par un mot de passe peuvent être remplacés par l'option FORMAT de l'instruction BACKUP.

Remarque relative à la sécuritéRemarque relative à la sécurité

La protection assurée par ce mot de passe est faible. Son but est d'éviter que des utilisateurs autorisés ou non autorisés effectuent une restauration incorrecte à l'aide des outils SQL Server. Elle n'empêche pas la lecture des données de sauvegarde par d'autres moyens, ni le remplacement du mot de passe. Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft 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 méthode conseillé en matière de protection des sauvegardes consiste à stocker les bandes de sauvegarde dans un emplacement sûr ou à sauvegarder les fichiers disque protégés par une liste de contrôle d'accès (ACL). La liste de contrôle d'accès doit être définie à la racine du répertoire dans lequel les sauvegardes sont effectuées.

Autorisations

Si la base de données restaurée n'existe pas, l'utilisateur doit posséder les autorisations CREATE DATABASE afin de pouvoir exécuter RESTORE. Si la base de données existe, les autorisations RESTORE reviennent par défaut aux membres des rôles serveur fixes sysadmin et dbcreator et au propriétaire (dbo) de la base de données (pour l'option FROM DATABASE_SNAPSHOT, la base de données existe toujours).

Les autorisations RESTORE sont attribuées aux rôles dont les informations d'appartenance sont toujours immédiatement accessibles à partir du serveur. Étant donné que l'appartenance au rôle de base de données fixe ne peut être contrôlée que lorsque la base de données est accessible et non endommagée, ce qui n'est pas toujours le cas lorsque RESTORE est exécuté, les membres du rôle de base de données fixe db_owner ne détiennent pas d'autorisations RESTORE.

Exemples

Tous les exemples partent du principe qu'une sauvegarde complète de la base de données a été effectuée.

Parmi les exemples d'instruction RESTORE, citons :

  • A. Restauration d'une base de données complète

  • B. Restauration de sauvegardes complètes et différentielles d'une base de données

  • C. Restauration d'une base de données en utilisant la syntaxe RESTART

  • D. Restauration d'une base de données et déplacement des fichiers

  • E. Copie d'une base de données en utilisant BACKUP et RESTORE

  • F. Restauration jusqu'à une date et heure en utilisant STOPAT

  • G. Restauration du journal des transactions jusqu'à une marque

  • H. Restauration en utilisant la syntaxe TAPE

  • I. Restauration en utilisant la syntaxe FILE et FILEGROUP

  • J. Rétablissement à partir d'un instantané de base de données

[!REMARQUE]

Pour voir d'autres exemples, consultez les rubriques de procédures de restauration qui sont répertoriées dans Vue d'ensemble de la restauration et de la récupération (SQL Server).

A.Restauration d'une base de données complète

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

RESTORE DATABASE AdventureWorks2012 
   FROM AdventureWorks2012Backups;

[!REMARQUE]

Pour une base de données en mode de restauration complète ou en mode de récupération utilisant les journaux de transactions, SQL Server nécessite dans la plupart des cas une sauvegarde de la fin du fichier journal avant la restauration de la base de données. Pour plus d'informations, consultez Sauvegardes de la fin du journal (SQL Server).

[Début des exemples]

B.Restauration de sauvegardes complètes et différentielles d'une base de données

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\AdventureWorks2012.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 AdventureWorks2012
   FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2012.bak'
   WITH FILE = 6
      NORECOVERY;
RESTORE DATABASE AdventureWorks2012
   FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2012.bak'
   WITH FILE = 9
      RECOVERY;

[Début des exemples]

C.Restauration d'une base de données en utilisant la syntaxe RESTART

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 AdventureWorks2012
   FROM AdventureWorksBackups;
-- Here is the RESTORE RESTART operation.
RESTORE DATABASE AdventureWorks2012 
   FROM AdventureWorksBackups WITH RESTART;

[Début des exemples]

D.Restauration d'une base de données et déplacement des fichiers

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\MSSQL11.MSSQLSERVER\MSSQL\Data.

RESTORE DATABASE AdventureWorks2012
   FROM AdventureWorksBackups
   WITH NORECOVERY, 
      MOVE 'AdventureWorks2012_Data' TO 
'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Data\NewAdvWorks.mdf', 
      MOVE 'AdventureWorks2012_Log' 
TO 'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Data\NewAdvWorks.ldf';
RESTORE LOG AdventureWorks2012
   FROM AdventureWorksBackups
   WITH RECOVERY;

[Début des exemples]

E.Copie d'une base de données en utilisant BACKUP et RESTORE

L'exemple suivant utilise à la fois les instructions BACKUP et RESTORE pour effectuer une copie de la base de données AdventureWorks2012 . 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 se nomme TestDB. Pour plus d'informations, consultez RESTORE FILELISTONLY (Transact-SQL).

BACKUP DATABASE AdventureWorks2012 
   TO AdventureWorksBackups ;

RESTORE FILELISTONLY 
   FROM AdventureWorksBackups ;

RESTORE DATABASE TestDB 
   FROM AdventureWorksBackups 
   WITH MOVE 'AdventureWorks2012_Data' TO 'C:\MySQLServer\testdb.mdf',
   MOVE 'AdventureWorks2012_Log' TO 'C:\MySQLServer\testdb.ldf';
GO

[Début des exemples]

F.Restauration jusqu'à une date et heure en utilisant STOPAT

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 AdventureWorksBackups, 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 AdventureWorks2012
   FROM AdventureWorksBackups
   WITH FILE=3, NORECOVERY;

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

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

[Début des exemples]

G.Restauration du journal des transactions jusqu'à une marque

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

USE AdventureWorks2012
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 AdventureWorks2012
FROM AdventureWorksBackups
WITH FILE = 3, NORECOVERY;
GO

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

[Début des exemples]

H.Restauration en utilisant la syntaxe TAPE

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

RESTORE DATABASE AdventureWorks2012 
   FROM TAPE = '\\.\tape0';

[Début des exemples]

I.Restauration en utilisant la syntaxe FILE et FILEGROUP

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.

[!REMARQUE]

La récupération est réalisée séparément afin d'éviter qu'elle n'ait lieu trop tôt, c'est-à-dire avant que la totalité des sauvegardes de fichier journal n'ait été restauré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]

K.Rétablissement à partir d'un instantané de base de données

L'exemple suivant rétablit un instantané de base de données. Il part du principe qu'un seul instantané existe actuellement dans la base de données. Pour obtenir un exemple de création de cet instantané de base de données, consultez Créer un instantané de base de données (Transact-SQL).

[!REMARQUE]

Le rétablissement d'un instantané supprime tous les catalogues de texte intégral.

USE master;  
RESTORE DATABASE AdventureWorks2012 FROM DATABASE_SNAPSHOT = 'AdventureWorks_dbss1800';
GO

Pour plus d'informations, consultez Rétablir une base de données dans l'état d'un instantané de base de données.

[Début des exemples]

Voir aussi

Référence

BACKUP (Transact-SQL)

RESTORE REWINDONLY (Transact-SQL)

RESTORE VERIFYONLY (Transact-SQL)

Concepts

Sauvegarde et restauration des bases de données SQL Server

Sauvegarder et restaurer des bases de données système (SQL Server)

Sauvegarder et restaurer des catalogues et des index de recherche en texte intégral

Sauvegarder et restaurer des bases de données répliquées

Jeux de supports, familles de supports et jeux de sauvegarde (SQL Server)

Historique de sauvegarde et informations d'en-tête (SQL Server)