Freigeben über

RESTORE (Transact-SQL)

  • Artikel

Stellt Sicherungen wieder her, die mit dem BACKUP-Befehl erstellt wurden. Mit diesem Befehl können Sie das folgende Wiederherstellungsszenario durchführen:

  • Wiederherstellen einer ganzen Datenbank aus einer vollständigen Datenbanksicherung (vollständige Wiederherstellung).

  • Wiederherstellen eines Teils einer Datenbank (teilweise Wiederherstellung).

  • Wiederherstellen bestimmter Dateien oder Dateigruppen einer Datenbank (Dateiwiederherstellung).

  • Wiederherstellen bestimmter Seiten einer Datenbank (Seitenwiederherstellung).

  • Wiederherstellen eines Transaktionsprotokolls in einer Datenbank (Transaktionsprotokollwiederherstellung).

  • Wiederherstellen einer Datenbank auf den Zeitpunkt, der über eine Datenbankmomentaufnahme erfasst wurde.

Weitere Informationen zu SQL Server-Wiederherstellungsszenarien finden Sie unter Übersicht über Wiederherstellungsvorgänge (SQL Server). Weitere Informationen zu Beschreibungen der Argumente finden Sie unter RESTORE-Argumente (Transact-SQL).

Hinweis

Weitere Informationen zum Wiederherstellen des Windows Azure-BLOB-Speicherdiensts finden Sie unter SQL Server-Sicherung und -Wiederherstellung mit dem Windows Azure-BLOB-Speicherdienst.

Gilt für: SQL Server (SQL Server 2008 bis aktuelle Version).

Themenlink (Symbol) Transact-SQL-Syntaxkonventionen

Syntax

--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 | URL } = { 'physical_backup_device_name' |
      @physical_backup_device_name_var } 
} 
Note: URL is the format used to specify the location and the file name for the Windows Azure Blob. Although Windows Azure storage is a service, the implementation is similar to disk and tape to allow for a consistent and seemless restore experince for all the three devices. 
<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 
 | CREDENTIAL

--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'] 
   }

Argumente

Beschreibungen der Argumente finden Sie unter RESTORE-Argumente (Transact-SQL).

Info zu Wiederherstellungsszenarien

SQL Server unterstützt eine Vielzahl von Wiederherstellungsszenarien:

Weitere Überlegungen zu RESTORE-Optionen

Nicht mehr unterstützte RESTORE-Schlüsselwörter

Die folgenden Schlüsselwörter werden in SQL Server 2008 nicht mehr unterstützt:

Nicht mehr unterstütztes Schlüsselwort

Ersetzt durch...

Beispiel für Ersetzungsschlüsselwort

LOAD

RESTORE

RESTORE DATABASE

TRANSACTION

LOG

RESTORE LOG

DBO_ONLY

RESTRICTED_USER

RESTORE DATABASE ... WITH RESTRICTED_USER

RESTORE LOG

RESTORE LOG kann eine Dateiliste einschließen, um das Erstellen von Dateien bei einem Rollforward zu ermöglichen. Diese wird verwendet, wenn die Protokollsicherung Protokolleinträge enthält, die erstellt wurden, als der Datenbank eine Datei hinzugefügt wurde.

Hinweis

Bei einer Datenbank, die das Modell der vollen oder massenprotokollierten Wiederherstellung verwendet, ist in den meisten Fällen die Sicherung des Protokollfragments erforderlich, bevor die Datenbank wiederhergestellt wird.Wenn eine Datenbank ohne vorherige Sicherung des Protokollfragments wiederhergestellt wird, tritt ein Fehler auf. Dies gilt nicht, wenn die RESTORE DATABASE-Anweisung die WITH REPLACE- oder die WITH STOPAT-Klausel enthält, in der eine Zeit oder Transaktion nach dem Ende der Datensicherung angegeben sein muss.Weitere Informationen zu Sicherungen des Protokollfragments finden Sie unter Protokollfragmentsicherungen (SQL Server).

Vergleich zwischen RECOVERY und NORECOVERY

Ein Rollback wird von der RESTORE-Anweisung über die Optionen [ RECOVERY | NORECOVERY ] gesteuert:

  • NORECOVERY gibt an, dass kein Rollback erfolgt. Damit kann das Rollforward die nächste Anweisung in der Sequenz fortsetzen.

    In diesem Fall können über die Wiederherstellungssequenz andere Sicherungen wiederhergestellt werden, und für diese kann ein Rollforward ausgeführt werden.

  • RECOVERY (die Standardeinstellung) gibt an, dass das Rollback erst dann ausgeführt werden kann, wenn das Rollforward für die aktuelle Sicherung abgeschlossen ist.

    Das Wiederherstellen der Datenbank erfordert, dass die gesamte Gruppe der wiederhergestellten Daten (Rollforwardgruppe) mit der Datenbank konsistent ist. Wenn das Rollforward für die Rollforwardgruppe nicht weit genug ausgeführt wurde, um die Konsistenz mit der Datenbank herzustellen, und wenn RECOVERY angegeben ist, dann gibt Database Engine (Datenbankmodul) einen Fehler aus.

Kompatibilitätsunterstützung

Sicherungen der master-, model- und msdb-Datenbank, die mit einer früheren Version von SQL Server erstellt wurden, können von SQL Server 2014 nicht wiederhergestellt werden.

Hinweis

Es wird keine SQL Server-Sicherung in einer Version von SQL Server hergestellt, die älter als die Version ist, mit der die Sicherung erstellt wurde.

Jede Version von SQL Server verwendet im Vergleich zu früheren Versionen jedoch einen anderen Standardpfad. Daher muss zum Wiederherstellen einer Datenbank, die am Standardort für Sicherungen in früheren Versionen erstellt wurde, die MOVE-Option verwendet werden. Informationen zum neuen Standardpfad finden Sie unter Dateispeicherorte für Standard- und benannte Instanzen von SQL Server.

Nachdem Sie eine Datenbank einer früheren Version nach SQL Server 2014 wiederherstellen, wird die Datenbank automatisch aktualisiert. In der Regel ist die Datenbank sofort verfügbar. Wenn eine SQL Server 2005-Datenbank jedoch Volltextindizes aufweist, werden diese beim Upgrade entweder importiert, zurückgesetzt oder neu erstellt, abhängig von der Einstellung der upgrade_option-Servereigenschaft. Wenn die Upgradeoption auf Importieren (upgrade_option = 2) oder Neuerstellen (upgrade_option = 0) festgelegt ist, sind die Volltextindizes während des Upgrades nicht verfügbar. Je nach Menge der indizierten Daten kann der Importvorgang mehrere Stunden dauern; die Neuerstellung sogar bis zu zehnmal länger. Wenn die Upgradeoption auf Importieren festgelegt ist und kein Volltextkatalog verfügbar ist, werden die zugehörigen Volltextindizes neu erstellt. Um die Einstellung der Servereigenschaft upgrade_option zu ändern, verwenden Sie sp_fulltext_service.

Wird eine Datenbank zum ersten Mal an eine neue Instanz von SQL Server angefügt oder wiederhergestellt, ist noch keine Kopie des Datenbank-Hauptschlüssels (verschlüsselt vom Diensthauptschlüssel) auf dem Server gespeichert. Der Datenbank-Hauptschlüssel (Database Master Key, DMK) muss mithilfe der OPEN MASTER KEY-Anweisung entschlüsselt werden. Nachdem der Datenbank-Hauptschlüssel entschlüsselt wurde, können Sie für die Zukunft die automatische Entschlüsselung aktivieren, indem Sie die ALTER MASTER KEY REGENERATE-Anweisung verwenden. Auf diese Weise können Sie eine Kopie des mit dem Diensthauptschlüssel (Service Master Key, SMK) verschlüsselten Datenbank-Hauptschlüssels für den Server bereitstellen. Wenn eine Datenbank von einer früheren Version aktualisiert wurde, sollte der DMK neu generiert werden, damit er den neueren AES-Algorithmus verwendet. Weitere Informationen zum Neugenerieren des DMK finden Sie unter ALTER MASTER KEY (Transact-SQL). Die zum Neugenerieren des DMK zum Upgrade auf AES erforderliche Zeit hängt von der Anzahl der Objekte ab, die durch den DMK geschützt werden. Der DMK muss nur einmal auf AES aktualisiert und neu generiert werden. Dies hat keine Auswirkungen auf zukünftige Neugenerierungen im Rahmen einer Schlüsselrotationsstrategie.

Allgemeine Hinweise

Wenn bei einer Offlinewiederherstellung die angegebene Datenbank verwendet wird, zwingt RESTORE die Benutzer nach einer kurzen Verzögerung zum Beenden der Datenbankverwendung. Bei der Onlinewiederherstellung einer nicht primären Dateigruppe kann die Datenbank weiter verwendet werden, es sei denn, die zu wiederherstellende Dateigruppe wird offline geschaltet. Alle in der angegebenen Datenbank vorhandenen Daten werden durch die wiederhergestellten Daten ersetzt.

Weitere Informationen zur Datenbankwiederherstellung finden Sie unter Übersicht über Wiederherstellungsvorgänge (SQL Server).

Wiederherstellungsvorgänge über Plattformen hinweg, sogar zwischen unterschiedlichen Prozessortypen, können ausgeführt werden, solange die Sortierung der Datenbank vom Betriebssystem unterstützt wird.

RESTORE kann nach einem Fehler neu gestartet werden. Außerdem können Sie RESTORE anweisen, den Vorgang auch bei Fehlern fortzusetzen und so viele Daten wie möglich wiederherzustellen (siehe die Option CONTINUE_AFTER_ERROR).

RESTORE ist nicht in einer expliziten oder implizierten Transaktion zulässig.

Für das Wiederherstellen einer beschädigten master-Datenbank ist eine spezielle Vorgehensweise erforderlich. Weitere Informationen finden Sie unter Sichern und Wiederherstellen von Systemdatenbanken (SQL Server).

Durch das Wiederherstellen einer Datenbank wird der Plancache für die Instanz von SQL Server gelöscht. Durch das Löschen des Plancaches wird eine Neukompilierung aller nachfolgenden Ausführungspläne verursacht, und möglicherweise entsteht plötzlich eine temporäre Verringerung der Abfrageleistung. Für jeden geleerten Cachespeicher im Plancache enthält das SQL Server-Fehlerprotokoll folgende Meldung zur Information: "SQL Server hat für den '%s'-Cachespeicher (Bestandteil des Plancache) %d Leerungen des Cachespeichers gefunden, die von Datenbankwartungs- oder Neukonfigurierungsvorgängen ausgelöst wurden". Diese Meldung wird alle fünf Minuten protokolliert, solange der Cache innerhalb dieses Zeitintervalls geleert wird.

Um eine Verfügbarkeitsdatenbank wiederherzustellen, stellen Sie zuerst die Datenbank mit der Instanz von SQL Server wieder her, und fügen Sie dann die Datenbank der Verfügbarkeitsgruppe hinzu.

Interoperabilität

Datenbankeinstellungen und -wiederherstellung

Bei einer Wiederherstellung werden die meisten Datenbankoptionen, die mit ALTER DATABASE festgelegt werden können, auf die Werte zurückgesetzt, die am Ende der Sicherung gültig waren.

Durch die Verwendung der Option WITH RESTRICTED_USER wird dieses Verhalten jedoch für die Einstellung der Benutzerzugriffsoption überschrieben. Diese Einstellung wird immer im Anschluss an eine RESTORE-Anweisung festgelegt, die die Option WITH RESTRICTED_USER einschließt.

Wiederherstellen einer verschlüsselten Datenbank

Um eine verschlüsselte Datenbank wiederherstellen zu können, muss das Zertifikat oder der asymmetrische Schlüssel verfügbar sein, das oder der zum Verschlüsseln der Datenbank verwendet wurde. Ohne das Zertifikat oder den asymmetrischen Schlüssel kann die Datenbank nicht wiederhergestellt werden. Darum muss das Zertifikat, das zur Verschlüsselung des Verschlüsselungsschlüssels für die Datenbank verwendet wurde, so lange beibehalten werden, wie die Sicherung benötigt wird. Weitere Informationen finden Sie unter SQL Server-Zertifikate und asymmetrische Schlüssel.

Wiederherstellen einer für vardecimal-Speicher aktivierten Datenbank

Sicherungs- und Wiederherstellungsvorgänge können mit dem vardecimal-Speicherformat ordnungsgemäß ausgeführt werden. Weitere Informationen zum vardecimal-Speicherformat finden Sie unter sp_db_vardecimal_storage_format (Transact-SQL).

Wiederherstellen von Volltextdaten

Bei einer vollständigen Wiederherstellung werden Volltextdaten zusammen mit anderen Datenbankdaten wiederhergestellt. Beim Verwenden der normalen Syntax RESTORE DATABASE database_name FROM backup_device erfolgt die Wiederherstellung der Volltextdateien bei der Wiederherstellung der Datenbankdateien.

Die RESTORE-Anweisung kann auch für folgende Wiederherstellungen verwendet werden: Wiederherstellungen auf alternativen Speicherorten, differenzielle Wiederherstellungen, Datei- und Dateigruppenwiederherstellungen sowie differenzielle Datei- und Dateigruppenwiederherstellungen von Volltextdaten. Darüber hinaus können mit RESTORE Volltextdateien ohne oder mit Datenbankdaten wiederhergestellt werden.

Hinweis

Aus SQL Server 2005 importierte Volltextkataloge werden immer noch als Datenbankdateien behandelt.Für diese findet weiterhin die SQL Server 2005-Prozedur zur Sicherung von Volltextkatalogen Anwendung. Das Anhalten und Fortsetzen des Sicherungsvorgangs ist jedoch nicht mehr erforderlich.Weitere Informationen finden Sie unter Sichern und Wiederherstellen von Volltextkatalogen.

Metadaten

SQL Server enthält Tabellen mit Sicherungs- und Wiederherstellungsverlauf, in denen die Sicherungs- und Wiederherstellungsaktivität für jede Serverinstanz nachverfolgt wird. Beim Ausführen einer Wiederherstellung werden auch die Tabellen mit Sicherungsverläufen geändert. Informationen zu diesen Tabellen finden Sie unter Sicherungsverlauf und Headerinformationen (SQL Server).

Auswirkung der REPLACE-Option

REPLACE sollte selten und nur nach sorgfältiger Überlegung verwendet werden. Die Wiederherstellung verhindert normalerweise, dass eine Datenbank versehentlich durch eine andere Datenbank überschrieben wird. Wenn die in einer RESTORE-Anweisung angegebene Datenbank bereits auf dem aktuellen Server vorhanden ist und sich die angegebene GUID der Datenbankfamilie von der im Sicherungssatz aufgezeichneten GUID der Datenbankfamilie unterscheidet, wird die Datenbank nicht wiederhergestellt. Dies ist ein wichtiges Sicherheitselement.

Die Option REPLACE überschreibt verschiedene wichtige Sicherheitsprüfungen, die die Wiederherstellung normalerweise ausführt. Folgende Prüfungen werden überschrieben:

  • Wiederherstellung über eine vorhandene Datenbank mit einer von einer anderen Datenbank erstellten Sicherung.

    Mit der Option REPLACE ermöglicht die Wiederherstellung das Überschreiben einer vorhandenen Datenbank mit einer beliebigen im Sicherungssatz enthaltenen Datenbank, selbst wenn der angegebene Datenbankname sich von dem im Sicherungssatz aufgezeichneten Datenbanknamen unterscheidet. Dies kann zur Folge haben, dass eine Datenbank versehentlich durch eine andere Datenbank überschrieben wird.

  • Wiederherstellung über eine Datenbank mithilfe des vollständigen oder massenprotokollierten Wiederherstellungsmodells, wobei keine Sicherung des Protokollfragments erstellt wurde und die Option STOPAT nicht verwendet wird.

    Mit der Option REPLACE können Sie Arbeit verlieren, für die ein Commit ausgeführt wurde, da das zuletzt geschriebene Protokoll nicht gesichert wurde.

  • Überschreiben von vorhandenen Dateien.

    Beispielsweise könnten irrtümlicherweise Dateien des falschen Typs (z. B. XLS-Dateien) oder Dateien, die von einer anderen Datenbank verwendet werden, die zurzeit nicht online ist, überschrieben werden. Willkürliche Datenverluste sind möglich, wenn vorhandene Dateien überschrieben werden, auch wenn die wiederhergestellte Datenbank vollständig ist.

Wiederholen einer Wiederherstellung

Eine Wiederherstellung kann nicht rückgängig gemacht werden. Sie können jedoch die Auswirkungen des Datenkopiervorgangs und des Rollforwards negieren, indem Sie noch einmal beginnen und pro Datei vorgehen. Um noch einmal zu starten, stellen Sie die gewünschte Datei wieder her und führen dann erneut das Rollforward aus. Wenn Sie beispielsweise versehentlich zu viele Protokollsicherungen wiederhergestellt haben und über den beabsichtigten Endpunkt hinausgegangen sind, müssen Sie die Sequenz neu starten.

Eine Wiederherstellungssequenz kann abgebrochen und neu gestartet werden, indem der gesamte Inhalt der betroffenen Dateien wiederhergestellt wird.

Wiederherstellen einer Datenbank aus einer Datenbank-Momentaufnahme

Über einen Datenbank-Wiederherstellungsvorgang (angegeben mithilfe der Option DATABASE_SNAPSHOT) wird eine Datenbank mit einer vollständigen Quelle in einen früheren Zustand versetzt, indem sie auf den Zeitpunkt einer Datenbankmomentaufnahme wiederhergestellt wird. Das bedeutet, dass die Quelldatenbank mit Daten von dem Zeitpunkt überschrieben wird, der in der angegebenen Datenbankmomentaufnahme erfasst ist. Derzeit darf nur die Momentaufnahme vorhanden sein, aus der Sie die Datenbank wiederherstellen. Bei diesem Wiederherstellungsvorgang wird das Protokoll neu erstellt (deshalb können Sie für eine wiederhergestellte Datenbank später kein Rollforward bis zum Punkt des Benutzerfehlers durchführen).

Der Datenverlust beschränkt sich auf Updates der Datenbank, die nach der Erstellung der Momentaufnahme vorgenommen wurden. Die Metadaten einer wiederhergestellten Datenbank sind dieselben wie die Metadaten zum Zeitpunkt der Momentaufnahmeerstellung. Durch das Wiederherstellen einer Momentaufnahme werden jedoch alle Volltextkataloge gelöscht.

Die Wiederherstellung von einer Datenbankmomentaufnahme ist nicht für die Medienwiederherstellung vorgesehen. Im Gegensatz zu einem normalen Sicherungssatz ist die Datenbankmomentaufnahme eine unvollständige Kopie der Datenbankdateien. Wenn die Datenbank oder die Datenbankmomentaufnahme beschädigt ist, ist die Wiederherstellung von einer Momentaufnahme vermutlich unmöglich. Zudem ist es eher unwahrscheinlich, dass das Problem durch eine Wiederherstellung im Falle einer Beschädigung behoben wird, selbst wenn eine Wiederherstellung möglich ist.

Einschränkungen zur Wiederherstellung

Die Wiederherstellung wird unter folgenden Bedingungen nicht unterstützt:

  • Die Quelldatenbank enthält schreibgeschützte oder komprimierte Dateigruppen.

  • Mindestens eine Datei ist offline, die beim Erstellen der Momentaufnahme online war.

  • Derzeit ist mehr als eine Momentaufnahme der Datenbank vorhanden.

Weitere Informationen finden Sie unter Wiederherstellen einer Datenbank zu einer Datenbank-Momentaufnahme.

Sicherheit

Bei einem Sicherungsvorgang können optional Kennwörter für einen Mediensatz, einen Sicherungssatz oder für beides angegeben werden. Wurde ein Kennwort für einen Mediensatz oder Sicherungssatz definiert, müssen die richtigen Kennwörter in der RESTORE-Anweisung angegeben werden. Über diese Kennwörter werden nicht autorisierte Wiederherstellungsoptionen und unbefugtes Anfügen von Sicherungssätzen an Medien mithilfe der Tools von SQL Server verhindert. Kennwortgeschützte Medien können nicht mit der Option FORMAT der BACKUP-Anweisung überschrieben werden.

SicherheitshinweisSicherheitshinweis

Dieses Kennwort bietet also nur unzureichenden Schutz.Es soll vermeiden, dass autorisierte wie nicht autorisierte Benutzer mithilfe von SQL Server-Tools fehlerhafte Wiederherstellungen durchführen.Es verhindert jedoch nicht das Lesen der Sicherungsdaten mit anderen Mitteln oder das Ersetzen des Kennworts.Diese Funktion wird in zukünftigen Versionen von Microsoft SQL Server nicht mehr bereitgestellt. Verwenden Sie diese Funktion beim Entwickeln neuer Anwendungen nicht, und planen Sie das Ändern von Anwendungen, in denen es zurzeit verwendet wird. Eine bewährte Methode für den Schutz von Sicherungen ist das Verwahren von Sicherungsbändern an einem sicheren Ort oder das Sichern in Datenträgerdateien, die durch eine adäquate Zugriffssteuerungsliste (ACL, Access Control List) geschützt sind.Die ACLs sollten für den Verzeichnisstamm eingerichtet werden, unter dem die Sicherungen erstellt werden.

Weitere Informationen zur SQL Server-Sicherung und -Wiederherstellung mit dem Windows Azure-BLOB-Speicher finden Sie unter SQL Server-Sicherung und -Wiederherstellung mit dem Windows Azure-BLOB-Speicherdienst.

Berechtigungen

Ist die wiederherzustellende Datenbank nicht vorhanden, muss der Benutzer über CREATE DATABASE-Berechtigungen verfügen, um RESTORE ausführen zu können. Ist die Datenbank vorhanden, werden RESTORE-Berechtigungen standardmäßig den Mitgliedern der festen Serverrollen sysadmin und dbcreator sowie dem Besitzer (dbo) der Datenbank erteilt (für die Option FROM DATABASE_SNAPSHOT ist die Datenbank immer vorhanden).

RESTORE-Berechtigungen werden Rollen erteilt, in denen Mitgliedsinformationen immer für den Server verfügbar sind. Da die Mitgliedschaft in einer festen Datenbankrolle nur überprüft werden kann, wenn die Datenbank unbeschädigt ist und auf sie zugegriffen werden kann, was beim Ausführen von RESTORE nicht immer der Fall ist, verfügen Mitglieder der festen Datenbankrolle db_owner nicht über RESTORE-Berechtigungen.

Beispiele

Bei allen Beispielen wird davon ausgegangen, dass eine vollständige Datenbanksicherung ausgeführt wurde.

Die Beispiele zu RESTORE schließen Folgendes ein:

  • A. Wiederherstellen einer vollständigen Datenbank

  • B. Wiederherstellung von vollständigen und von differenziellen Datenbanksicherungen

  • C. Wiederherstellen einer Datenbank mit der RESTART-Syntax

  • D. Wiederherstellen einer Datenbank und Verschieben von Dateien

  • E. Kopieren einer Datenbank mithilfe von BACKUP und RESTORE

  • F. Wiederherstellen eines bestimmten Zeitpunkts mithilfe von STOPAT

  • G. Wiederherstellen eines Transaktionsprotokolls bis zu einer Markierung

  • H. Wiederherstellen mit der TAPE-Syntax

  • I. Wiederherstellen mithilfe der FILE- und FILEGROUP-Syntax

  • J. Wiederherstellen aus einer Datenbank-Momentaufnahme

  • K. Wiederherstellen aus dem Windows Azure-BLOB-Speicherdienst Beispiele

Hinweis

Weitere Beispiele finden Sie in den in Übersicht über Wiederherstellungsvorgänge (SQL Server) aufgeführten Themen über die Vorgehensweisen zur Wiederherstellung.

A.Wiederherstellen einer vollständigen Datenbank

Im folgenden Beispiel wird eine vollständige Datenbanksicherung vom logischen Sicherungsmedium AdventureWorksBackups wiederhergestellt. Ein Beispiel für das Erstellen dieses Mediums finden Sie unter Sicherungsmedien.

RESTORE DATABASE AdventureWorks2012 
   FROM AdventureWorks2012Backups;

Hinweis

Bei einer Datenbank, die das Modell der vollen oder massenprotokollierten Wiederherstellung verwendet, erfordert SQL Server in den meisten Fällen die Sicherung des Protokollfragments, bevor die Datenbank wiederhergestellt wird.Weitere Informationen finden Sie unter Protokollfragmentsicherungen (SQL Server).

[Anfang der Beispiele]

B.Wiederherstellung von vollständigen und von differenziellen Datenbanksicherungen

Im folgenden Beispiel wird eine vollständige Datenbanksicherung und anschließend eine differenzielle Sicherung vom Z:\SQLServerBackups\AdventureWorks2012.bak-Sicherungsmedium wiederhergestellt, das beide Sicherungen enthält. Die vollständige Datenbanksicherung, die wiederhergestellt werden soll, ist der sechste Sicherungssatz auf dem Medium (FILE = 6). Die differenzielle Sicherung ist der neunte Sicherungssatz auf dem Medium (FILE = 9). Sobald die differenzielle Sicherung wiederhergestellt wird, wird die Datenbank wiederhergestellt.

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;

[Anfang der Beispiele]

C.Wiederherstellen einer Datenbank mit der RESTART-Syntax

Im folgenden Beispiel wird die Option RESTART zum Neustart eines RESTORE-Vorgangs verwendet, der durch einen Stromausfall des Servers unterbrochen wurde.

-- 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;

[Anfang der Beispiele]

D.Wiederherstellen einer Datenbank und Verschieben von Dateien

Im folgenden Beispiel wird eine vollständige Datenbank und ein Transaktionsprotokoll wiederhergestellt. Anschließend wird die wiederhergestellte Datenbank in das Verzeichnis C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Data verschoben.

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

[Anfang der Beispiele]

E.Kopieren einer Datenbank mithilfe von BACKUP und RESTORE

Im folgenden Beispiel werden die Anweisungen BACKUP und RESTORE verwendet, um eine Kopie der AdventureWorks2012 -Datenbank zu erstellen. Die MOVE-Anweisung bewirkt, dass die Daten- und die Protokolldatei an den angegebenen Speicherorten wiederhergestellt werden. Die RESTORE FILELISTONLY-Anweisung wird verwendet, um die Anzahl und die Namen der Dateien der Datenbank zu bestimmen, die wiederhergestellt werden. Die neue Kopie der Datenbank erhält den Namen TestDB. Weitere Informationen finden Sie unter 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

[Anfang der Beispiele]

F.Wiederherstellen eines bestimmten Zeitpunkts mithilfe von STOPAT

Im folgenden Beispiel wird eine Datenbank in den am April 15, 2020 um 12:00 AM bestehenden Status wiederhergestellt und ein Wiederherstellungsvorgang gezeigt, der mehrere Protokollsicherungen umfasst. Auf dem Sicherungsmedium (AdventureWorksBackups) ist die wiederherzustellende vollständige Datenbanksicherung der dritte Sicherungssatz (FILE = 3), die erste Protokollsicherung ist der vierte Sicherungssatz (FILE = 4), und die zweite Protokollsicherung ist der fünfte Sicherungssatz (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;

[Anfang der Beispiele]

G.Wiederherstellen eines Transaktionsprotokolls bis zu einer Markierung

Im folgenden Beispiel wird das Transaktionsprotokoll bis zur Markierung in der markierten Transaktion mit dem Namen ListPriceUpdate wiederhergestellt.

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';

[Anfang der Beispiele]

H.Wiederherstellen mit der TAPE-Syntax

Im folgenden Beispiel wird eine vollständige Datenbanksicherung von einem TAPE-Sicherungsmedium wiederhergestellt.

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

[Anfang der Beispiele]

I.Wiederherstellen mithilfe der FILE- und FILEGROUP-Syntax

Im folgenden Beispiel wird eine Datenbank mit dem Namen MyDatabase wiederhergestellt, die über zwei Dateien, eine sekundäre Dateigruppe und ein Transaktionsprotokoll verfügt. Für die Datenbank wird das vollständige Wiederherstellungsmodell verwendet.

Die Datenbanksicherung ist der neunte Sicherungssatz im Mediensatz auf einem logischen Sicherungsmedium mit dem Namen MyDatabaseBackups. Anschließend werden drei Protokollsicherungen, die sich in den nächsten drei Sicherungssätzen (10, 11 und 12) im Medium MyDatabaseBackups befinden, mit WITH NORECOVERY wiederhergestellt. Nach dem Wiederherstellen der letzten Protokollsicherung wird die Datenbank wiederhergestellt.

Hinweis

Die Wiederherstellung wird in einem separaten Schritt ausgeführt, um zu vermeiden, dass sie zu früh ausgeführt wird, d. h., bevor alle Protokollsicherungen wiederhergestellt wurden.

Beachten Sie, dass in der RESTORE DATABASE-Anweisung zwei Typen von FILE-Optionen vorhanden sind. Mit den FILE-Optionen vor dem Namen des Sicherungsmediums werden die logischen Dateinamen der Datenbankdateien angegeben, die aus dem Sicherungssatz wiederhergestellt werden sollen, beispielsweise FILE = 'MyDatabase_data_1'. Dieser Sicherungssatz ist nicht die erste Datenbanksicherung im Mediensatz. Daher wird seine Position im Mediensatz mit der Option FILE in der WITH-Klausel angegeben: 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

[Anfang der Beispiele]

K.Wiederherstellen aus einer Datenbank-Momentaufnahme

Im folgenden Beispiel wird eine Datenbank aus einer Datenbank-Momentaufnahme wiederhergestellt. In diesem Beispiel wird davon ausgegangen, dass derzeit in der Datenbank nur eine Momentaufnahme vorhanden ist. Ein Beispiel zum Erstellen dieser Datenbankmomentaufnahme finden Sie unter Erstellen einer Datenbankmomentaufnahme (Transact-SQL).

Hinweis

Durch das Wiederherstellen einer Momentaufnahme werden alle Volltextkataloge gelöscht.

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

Weitere Informationen finden Sie unter Wiederherstellen einer Datenbank zu einer Datenbank-Momentaufnahme.

[Anfang der Beispiele]

Siehe auch

Verweis

BACKUP (Transact-SQL)

RESTORE REWINDONLY (Transact-SQL)

RESTORE VERIFYONLY (Transact-SQL)

Konzepte

Sichern und Wiederherstellen von SQL Server-Datenbanken

Sichern und Wiederherstellen von Systemdatenbanken (SQL Server)

Sichern und Wiederherstellen von Volltextkatalogen und Indizes

Sichern und Wiederherstellen von replizierten Datenbanken

Mediensätze, Medienfamilien und Sicherungssätze (SQL Server)

Sicherungsverlauf und Headerinformationen (SQL Server)