Freigeben über

BACKUP (Transact-SQL)

  • Artikel

Aktualisiert: 12. Dezember 2006

Sichert eine vollständige Datenbank oder mindestens eine Datei oder Dateigruppe (BACKUP DATABASE). Sichert bei Verwendung des vollständigen oder massenprotokollierten Wiederherstellungsmodells auch das Transaktionsprotokoll (BACKUP LOG).

Themenlink (Symbol)Transact-SQL-Syntaxkonventionen

Syntax

Backing Up a Whole Database 
BACKUP DATABASE { database_name | @database_name_var } 
  TO <backup_device> [ ,...n ] 
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]

Backing Up Specific Files or Filegroups
BACKUP DATABASE { database_name | @database_name_var } 
 <file_or_filegroup> [ ,...n ] 
  TO <backup_device> [ ,...n ] 
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]

Creating a Partial Backup
BACKUP DATABASE { database_name | @database_name_var } 
 READ_WRITE_FILEGROUPS [ , <read_only_filegroup> [ ,...n ] ]
  TO <backup_device> [ ,...n ] 
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]

Backing Up the Transaction Log (full and bulk-logged recovery models)
BACKUP LOG { database_name | @database_name_var } 
  TO <backup_device> [ ,...n ] 
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { <general_WITH_options> | <log-specific_optionspec> } [ ,...n ] ]
[;]

Truncating the Transaction Log (breaks the log chain) 
BACKUP LOG { database_name | @database_name_var } 
  WITH { NO_LOG | TRUNCATE_ONLY } 
[;]

<backup_device>::= 
 {
   { logical_device_name | @logical_device_name_var } 
 | { DISK | TAPE } = 
     { 'physical_device_name' | @physical_device_name_var }
 } 

<MIRROR TO clause>::=
 MIRROR TO <backup_device> [ ,...n ]

<file_or_filegroup>::=
 {
   FILE = { logical_file_name | @logical_file_name_var } 
 | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
 } 

<read_only_filegroup>::=
FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

<general_WITH_options> [ ,...n ]::= 
--Backup Set Options
      COPY_ONLY 
  | DESCRIPTION = { 'text' | @text_variable } 
 | NAME = { backup_set_name | @backup_set_name_var } 
 | PASSWORD = { password | @password_variable } 
 | [ EXPIREDATE = { date | @date_var } 
        | RETAINDAYS = { days | @days_var } ] 
 | NO_LOG 

--Media Set Options
   { NOINIT | INIT } 
 | { NOSKIP | SKIP } 
 | { NOFORMAT | FORMAT } 
 | MEDIADESCRIPTION = { 'text' | @text_variable } 
 | 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
   { NO_CHECKSUM | CHECKSUM }
 | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

--Compatibility Options
   RESTART 

--Monitoring Options
   STATS [ = percentage ] 

--Tape Options
   { REWIND | NOREWIND } 
 | { UNLOAD | NOUNLOAD } 

--Log-specific Options
   { NORECOVERY | STANDBY = undo_file_name }
 | NO_TRUNCATE

Argumente

  • DATABASE
    Gibt eine vollständige Datenbanksicherung an. Wird eine Liste von Dateien und Dateigruppen angegeben, werden nur diese Dateien und Dateigruppen gesichert. Während einer vollständigen oder differenziellen Datenbanksicherung werden von SQL Server auch die erforderlichen Teile des Transaktionsprotokolls gesichert, um eine konsistente Datenbank zu erzeugen, wenn die Sicherung wiederhergestellt wird.

    ms186865.note(de-de,SQL.90).gifHinweis:
    Für die master-Datenbank kann nur eine vollständige Datenbanksicherung ausgeführt werden.

  • LOG
    Gibt an, dass nur das Transaktionsprotokoll gesichert wird. Das Protokoll wird von der letzten erfolgreich ausgeführten Protokollsicherung bis zum aktuellen Ende des Protokolls gesichert. Bevor Sie die erste Protokollsicherung erstellen können, müssen Sie eine vollständige Sicherung erstellen.

    ms186865.note(de-de,SQL.90).gifHinweis:
    Nach einer typischen Protokollsicherung werden einige Datensätze des Transaktionsprotokolls deaktiviert, wenn Sie nicht WITH NO_TRUNCATE oder COPY_ONLY angeben. Das Protokoll wird abgeschnitten, nachdem alle Datensätze innerhalb mindestens einer virtuellen Protokolldatei deaktiviert werden. Wenn das Protokoll nach routinemäßigen Protokollsicherungen nicht abgeschnitten wird, wird das Abschneiden des Protokolls möglicherweise verzögert. Weitere Informationen finden Sie unter Verwalten des Transaktionsprotokolls.

  • { database_name| @database_name_var }
    Die Datenbank, für die ein Transaktionsprotokoll, eine Teildatenbank oder die vollständige Datenbank gesichert wird. Bei der Angabe als Variable (@database_name_var) kann dieser Name entweder als eine Zeichenfolgenkonstante (@database_name_var    =     Name der Datenbank) oder als eine Variable eines Zeichenfolgen-Datentyps (mit Ausnahme der Datentypen ntext oder text) angegeben werden.

    ms186865.note(de-de,SQL.90).gifHinweis:
    Eine Sicherung der Spiegeldatenbank in einer Datenbank-Spiegelungspartnerschaft ist nicht möglich.

  • <file_or_filegroup> [ ,...n ]
    Wird nur mit BACKUP DATABASE verwendet, gibt eine Datenbankdatei oder eine Dateigruppe in einer Datenbank an, die in einer Dateisicherung enthalten sein soll, oder gibt eine schreibgeschützte Datei oder Dateigruppe an, die in einer Teilsicherung enthalten sein soll.

    • FILE ={ logical_file_name| **@**logical_file_name_var }
      Der logische Name einer Datei oder einer Variablen, deren Wert dem logischen Namen einer Datei entspricht, die in der Sicherung enthalten sein soll.

    • FILEGROUP = { logical_filegroup_name| **@**logical_filegroup_name_var }
      Der logische Name einer Dateigruppe oder einer Variablen, deren Wert dem logischen Namen einer Dateigruppe entspricht, die in der Sicherung enthalten sein soll. Beim einfachen Wiederherstellungsmodell wird die Dateigruppensicherung nur für eine schreibgeschützte Dateigruppe unterstützt.

      ms186865.note(de-de,SQL.90).gifHinweis:
      Verwenden Sie Dateisicherungen dann, wenn eine Datenbanksicherung aufgrund der Datenbankgröße und aufgrund von Leistungsanforderungen nicht möglich ist.
    • n
      Ein Platzhalter, der anzeigt, dass mehrere Dateien und Dateigruppen in einer durch Kommas getrennten Liste angegeben werden können. Für die Anzahl gibt es keine Einschränkungen.

    Weitere Informationen finden Sie unter Vollständige Dateisicherungen und Vorgehensweise: Sichern von Dateien und Dateigruppen (Transact-SQL).

  • READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name| **@**logical_filegroup_name_var } [ ,...n ] ]
    Gibt eine Teilsicherung an. Eine Teilsicherung umfasst alle Dateien mit Lese-/Schreibzugriff in einer Datenbank: die primäre Dateigruppe und alle beliebigen sekundären Dateigruppen mit Lese-/Schreibzugriff sowie auch alle angegebenen schreibgeschützten Dateien oder Dateigruppen.

    • READ_WRITE_FILEGROUPS
      Gibt an, dass alle Dateigruppen mit Lese-/Schreibzugriff in der Teilsicherung gesichert werden sollen. Wenn die Datenbank schreibgeschützt ist, umfasst READ_WRITE_FILEGROUPS nur die primäre Dateigruppe.

      ms186865.note(de-de,SQL.90).gifWichtig:
      Durch das explizite Auflisten der Dateigruppem mit Lese-/Schreibzugriff mithilfe von FILEGROUP anstelle von READ_WRITE_FILEGROUPS wird eine Dateisicherung erstellt.
    • FILEGROUP = { logical_filegroup_name| **@**logical_filegroup_name_var }
      Der logische Name einer schreibgeschützten Dateigruppe oder einer Variablen, deren Wert dem logischen Namen einer schreibgeschützten Dateigruppe entspricht, die in der Teilsicherung enthalten sein soll. Weitere Informationen finden Sie unter "<file_or_filegroup>" weiter oben in diesem Thema.
    • n
      Ein Platzhalter, der anzeigt, dass mehrere schreibgeschützte Dateigruppen in einer durch Kommas getrennten Liste angegeben werden können.

    Weitere Informationen zu Teilsicherungen finden Sie unter Teilsicherungen.

  • TO <backup_device> [ ,...n ]
    Gibt an, dass es sich bei dem zugehörigen Satz von Sicherungsmedien entweder um einen nicht gespiegelten Mediensatz handelt oder um den ersten Spiegel innerhalb eines gespiegelten Mediensatzes (für den eine oder mehrere MIRROR TO-Klauseln deklariert sind).

    • <backup_device>
      Gibt ein logisches oder physikalisches Sicherungsmedium an, das für den Sicherungsvorgang verwendet werden soll.

      • { logical_device_name | @logical_device_name_var }
        Der logische Name des Sicherungsmediums (das durch sp_addumpdevice erstellt wurde), auf dem die Datenbank gesichert wird. Der logische Name muss den Regeln für Bezeichner entsprechen. Bei der Angabe als Variable (@logical_device_name_var) kann der Name des Sicherungsmediums entweder als Zeichenfolgenkonstante (@logical_device_name_var        =         Name des logischen Sicherungsmediums) oder als Variable eines Zeichenfolgen-Datentyps (mit Ausnahme der Datentypen ntext oder text) angegeben werden.

      • {DISK | TAPE } = { 'physical_device_name' | **@**physical_device_name_var }
        Gibt eine Datenträgerdatei oder ein Bandmedium an. Das angegebene Medium muss erst dann vorhanden sein, wenn die BACKUP-Anweisung ausgeführt wird. Wenn das physikalische Medium vorhanden ist und die Option INIT in der BACKUP-Anweisung nicht angegeben ist, wird die Sicherung an das Medium angefügt.

        Weitere Informationen finden Sie unter Sicherungsmedien.

    • n
      Ein Platzhalter, der anzeigt, dass in einer durch Kommas getrennten Liste möglicherweise bis zu 64 Sicherungsmedien angegeben werden.

  • MIRROR TO <backup_device> [ ,...n ]
    Gibt einen Satz von mindestens einem Sicherungsmedium an, der die in der TO-Klausel angegebenen Sicherungsmedien spiegelt. Die MIRROR TO-Klausel muss denselben Typ und dieselbe Anzahl von Sicherungsdateien angeben wie die TO-Klausel. Die maximale Anzahl von MIRROR TO-Klauseln lautet drei.

    Diese Option ist nur in SQL Server 2005 Enterprise Edition und höheren Versionen verfügbar.

    ms186865.note(de-de,SQL.90).gifHinweis:
    Für MIRROR TO = DISK legt BACKUP automatisch die geeignete Blockgröße für Festplattenmedien fest. Weitere Informationen zur Blockgröße finden Sie weiter unten in dieser Tabelle unter "BLOCKSIZE".
    • <backup_device>
      Informationen finden Sie unter "<backup_device>" weiter oben in diesem Abschnitt.
    • n
      Ein Platzhalter, der anzeigt, dass in einer durch Kommas getrennten Liste möglicherweise bis zu 64 Sicherungsmedien angegeben werden. Die Anzahl von Medien in der MIRROR TO-Klausel muss der Anzahl von Medien in der TO-Klausel entsprechen.
  • [ next-mirror-to ]
    Ein Platzhalter, der anzeigt, dass eine einzelne BACKUP-Anweisung zusätzlich zu der einzelnen TO-Klausel bis zu drei MIRROR TO-Klauseln enthalten kann.

WITH-Optionen

Gibt die Optionen an, die bei einem Sicherungsvorgang verwendet werden sollen.

  • DIFFERENTIAL
    Gibt bei der Verwendung nur mit BACKUP DATABASE an, dass sich die Datenbank- oder Dateisicherung nur auf die Teile der Datenbank oder Datei beschränken soll, die seit der letzten vollständigen Sicherung geändert wurden. Eine differenzielle Sicherung benötigt in der Regel weniger Speicherplatz als eine vollständige Sicherung. Verwenden Sie diese Option, damit nicht alle seit der letzten vollständigen Sicherung ausgeführten individuellen Protokollsicherungen angewendet werden müssen.

    ms186865.note(de-de,SQL.90).gifHinweis:
    BACKUP DATABASE erstellt standardmäßig eine vollständige Sicherung.

    Weitere Informationen finden Sie unter Verwenden von differenziellen Sicherungen.

Sicherungssatzoptionen

Diese Optionen werden für den durch diesen Sicherungsvorgang erstellten Sicherungssatz verwendet.

ms186865.note(de-de,SQL.90).gifHinweis:
Verwenden Sie die Option FILE =<backup_set_file_number>, um einen Sicherungssatz für einen Wiederherstellungsvorgang anzugeben. Weitere Informationen zum Angeben eines Sicherungssatzes finden Sie unter RESTORE-Argumente (Transact-SQL).

  • COPY_ONLY
    Gibt an, dass die Sicherung eine Kopiesicherung ist, die keine Auswirkungen auf die normale Sicherungssequenz hat. Eine Kopiesicherung wird unabhängig von den regelmäßig geplanten konventionellen Sicherungen erstellt. Eine Kopiesicherung hat keine Auswirkungen auf die allgemeinen Sicherungs- und Wiederherstellungsprozeduren für die Datenbank.

    Kopiesicherungen wurden in SQL Server 2005 für Situationen eingeführt, in denen eine Sicherung für einen besonderen Zweck verwendet wird, z. B. zum Sichern des Protokolls vor einer Onlinedateiwiederherstellung. In der Regel wird eine Kopieprotokollsicherung einmal verwendet und dann gelöscht.

    • Bei Verwendung mit BACKUP DATABASE wird durch die Option COPY_ONLY eine vollständige Sicherung erstellt, die nicht als eine differenzielle Basis verwendet werden kann. Das differenzielle Bitmuster wird nicht aktualisiert, und die differenziellen Sicherungen verhalten sich so, als sei die Kopiesicherung nicht vorhanden. Nachfolgende differenzielle Sicherungen verwenden die neueste, konventionelle vollständige Sicherung als Basis.
      ms186865.note(de-de,SQL.90).gifWichtig:
      Wenn DIFFERENTIAL und COPY_ONLY zusammen verwendet werden, wird COPY_ONLY ignoriert, und eine differenzielle Sicherung wird erstellt.
    • Bei Verwendung mit BACKUP LOG wird durch die Option COPY_ONLY eine Kopieprotokollsicherung erstellt, die das Transaktionsprotokoll nicht abschneidet. Die Kopieprotokollsicherung hat keine Auswirkungen auf die Protokollkette, und andere Protokollsicherungen verhalten sich so, als sei die Kopiesicherung nicht vorhanden.

    Weitere Informationen finden Sie unter Kopiesicherungen.

  • DESCRIPTION = { 'text' | **@**text_variable }
    Gibt den freien Text an, der als Beschreibung des Sicherungssatzes verwendet wird. Die Zeichenfolge kann maximal 255 Zeichen haben.
  • NAME = { backup_set_name| **@**backup_set_var }
    Gibt den Namen des Sicherungssatzes an. Namen können maximal 128 Zeichen haben. Wird NAME nicht angegeben, erhält der Sicherungssatz einen leeren Namen.

  • PASSWORD = { password | **@**password_variable }
    Legt das Kennwort für den Sicherungssatz fest. PASSWORD ist eine Zeichenfolge. Wenn für den Sicherungssatz ein Kennwort definiert ist, muss das Kennwort eingegeben werden, um mit dem Sicherungssatz einen SQL Server-Wiederherstellungsvorgang auszuführen. Mit einem Kennwort für den Sicherungssatz wird die Sicherungsdatei jedoch nicht vor dem Überschreiben geschützt. Verwenden Sie ein Kennwort für den Mediensatz, um zu verhindern, dass eine Sicherungsdatei überschrieben wird (siehe die Option MEDIAPASSWORD weiter unten in dieser Tabelle). (Weitere Informationen zum Verwenden von Kennwörtern finden Sie unter "Berechtigungen" weiter unten in diesem Thema.)

    ms186865.security(de-de,SQL.90).gifSicherheitshinweis:
    Dieses Kennwort bietet also nur unzureichenden Schutz. Es soll vermeiden, dass autorisierte wie nicht autorisierte Benutzer mithilfe von Tools für SQL Server 2005 fehlerhafte Wiederherstellungen ausführen. Es verhindert jedoch nicht das Lesen der Sicherungsdaten mit anderen Mitteln oder das Ersetzen des Kennwortes. 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 (Access Control List oder ACL) geschützt sind. Die ACLs sollten für den Verzeichnisstamm eingerichtet werden, unter dem die Sicherungen erstellt werden.
    ms186865.note(de-de,SQL.90).gifHinweis:
    Die Option PASSWORD wird in einer zukünftigen Version von SQL Server entfernt.

  • [ EXPIREDATE **=**date | RETAINDAYS **=**date ]
    Gibt an, wann der Sicherungssatz für diese Sicherung überschrieben werden kann. Wenn beide Optionen verwendet werden, hat RETAINDAYS Vorrang vor EXPIREDATE.

    Wenn keine der Optionen angegeben wird, wird das Ablaufdatum durch die Konfigurationseinstellung mediaretention bestimmt. Weitere Informationen finden Sie unter Festlegen von Serverkonfigurationsoptionen.

    ms186865.note(de-de,SQL.90).gifWichtig:
    Diese Optionen verhindern nur, dass SQL Server eine Datei überschreibt. Bänder können mit anderen Methoden gelöscht werden, und Dateien auf einem Datenträger können mit entsprechenden Betriebssystembefehlen gelöscht werden. Weitere Informationen zur Prüfung des Ablaufdatums finden Sie unter SKIP und FORMAT in diesem Thema.

    • EXPIREDATE = { date | **@**date_var }
      Gibt an, wann der Sicherungssatz abläuft und überschrieben werden kann. Wenn dieses Datum als Variable (@date_var) bereitgestellt wird, muss es dem konfigurierten datetime-Systemformat genügen und als eines der folgenden Elemente angegeben werden:

      • Eine Zeichenfolgekonstante (@date_var = Datum)
      • Eine Variable mit einem Zeichenfolgen-Datentyp (mit Ausnahme der Datentypen ntext und text)
      • A smalldatetime
      • Eine Variable vom Typ datetime

      Beispiel:

      • 'Dec 31, 2020 11:59 PM'
      • '1/1/2021'

      Weitere Informationen zum Angeben von datetime-Werten finden Sie unter Alphabetisches Datumsformat und Numerisches Datumsformat.

      ms186865.note(de-de,SQL.90).gifHinweis:
      Zum Ignorieren des Ablaufdatums verwenden Sie die Option SKIP.
    • RETAINDAYS = { days| **@days_var }
      Gibt die Anzahl von Tagen an, die verstreichen müssen, bevor dieser Sicherungsmediensatz überschrieben werden kann. Bei der Angabe als Variable (      @**days_var) muss der Wert als ganze Zahl angegeben werden.

  • NO_LOG
    Gibt im Kontext einer BACKUP DATABASE-Anweisung an, dass eine Sicherung kein Protokoll enthalten wird. Dies entspricht der Art und Weise, wie Dateisicherungen vor SQL Server 2005 erstellt wurden. Eine mit NO_LOG erstellte Datenbanksicherung entspricht einem vollständigen Satz von Dateisicherungen, in dem keine Protokolldatensätze enthalten sind.

    Im Modell der vollständigen Wiederherstellung ist NO_LOG hilfreich, wenn Daten schnell gesichert werden sollen und Sie über eine vollständige Sequenz der Protokollsicherungen dieser Daten verfügen.

Mediensatzoptionen

Diese Optionen werden für den Mediensatz insgesamt verwendet.

  • { NOINIT | INIT }
    Steuert, ob der Sicherungsvorgang an die vorhandenen Sicherungssätze auf dem Sicherungsmedium angefügt wird oder diese überschreibt. Er wird standardmäßg an den neuesten Sicherungssatz auf dem Medium (NOINIT) angefügt.

    ms186865.note(de-de,SQL.90).gifHinweis:
    Informationen zu Interaktionen zwischen { NOINIT | INIT } und { NOSKIP | SKIP } finden Sie unter "Hinweise" weiter unten in diesem Thema.

    • NOINIT
      Zeigt an, dass der Sicherungssatz an den angegebenen Mediensatz angehängt wird, wobei vorhandene Sicherungssätze erhalten bleiben. Wenn für den Mediensatz ein Medienkennwort definiert ist, muss dieses Kennwort angegeben werden. NOINIT ist die Standardeinstellung.

      Weitere Informationen finden Sie unter Anfügen an vorhandene Sicherungssätze.

    • INIT
      Gibt an, dass alle Sicherungssätze überschrieben werden sollen, während der Medienheader erhalten bleibt. Wenn INIT angegeben wird, werden alle bereits auf dem Medium vorhandenen Sicherungssätze überschrieben (wenn die Bedingungen dies zulassen). Standardmäßig prüft BACKUP die folgenden Bedingungen und überschreibt die Sicherungsmedien nicht, wenn eine der Bedingungen erfüllt wird:

      • Einer der Sicherungssätze ist noch nicht abgelaufen. Weitere Informationen finden Sie unter den Optionen EXPIREDATE und RETAINDAYS.
      • Der möglicherweise in der BACKUP-Anweisung angegebene Name des Sicherungssatzes stimmt nicht mit dem Namen auf dem Sicherungsmedium überein. Weitere Informationen finden Sie unter der Option NAME weiter oben in diesem Abschnitt.

      Verwenden Sie die Option SKIP, um diese Überprüfungen außer Kraft zu setzen.

      ms186865.note(de-de,SQL.90).gifHinweis:
      Wenn das Sicherungsmedium kennwortgeschützt ist, schreibt SQL Server nur dann auf das Medium, wenn das Medienkennwort angegeben wird. Diese Prüfung wird nicht durch die Option SKIP außer Kraft gesetzt. Kennwortgeschützte Medien können nur überschrieben werden, wenn das Medium neu formatiert wird, wodurch die Sicherungen auf dem Medium gelöscht werden. Weitere Informationen zum Medienkennwort finden Sie unter "MEDIAPASSWORD" weiter oben in diesem Thema. Weitere Informationen zur Neuformatierung von Medien finden Sie unter "FORMAT" weiter oben in diesem Thema.

      Weitere Informationen finden Sie unter Überschreiben von Sicherungssätzen.

  • { NOSKIP | SKIP }
    Steuert, ob ein Sicherungsvorgang das Ablaufdatum und die Ablaufzeit der Sicherungssätze auf dem Medium überprüft, bevor diese überschrieben werden.

    ms186865.note(de-de,SQL.90).gifHinweis:
    Informationen zu Interaktionen zwischen { NOINIT | INIT } und { NOSKIP | SKIP } finden Sie unter "Hinweise" weiter unten in diesem Thema.
    • NOSKIP
      Weist die BACKUP-Anweisung an, das Ablaufdatum aller Sicherungssätze auf den Medien zu prüfen, bevor diese überschrieben werden dürfen. Dies ist das Standardverhalten.

    • SKIP
      Deaktiviert die Prüfung von Ablaufdatum und Namen der Sicherungssätze. Diese Überprüfung wird normalerweise von der BACKUP-Anweisung ausgeführt, damit ein Überschreiben von Sicherungssätzen verhindert wird. Informationen zu Interaktionen zwischen { INIT | NOINIT } und { NOSKIP | SKIP } finden Sie unter "Hinweise" weiter unten in diesem Thema.

      Zum Anzeigen des Ablaufdatums und der Sicherungssätze fragen Sie die expiration_date-Spalte der backupset-Verlaufstabelle ab.

  • { NOFORMAT | FORMAT }
    Gibt an, dass der Medienheader auf alle Datenträger geschrieben werden soll, die für diesen Sicherungsvorgang verwendet werden. Dabei werden vorhandene Medienheader und Sicherungssätze überschrieben.

    • NOFORMAT
      Gibt an, dass der Sicherungsvorgang die vorhandenen Medienheader und Sicherungssätze auf den Mediendatenträgern beibehält, die für diesen Vorgang verwendet werden. Dies ist das Standardverhalten.

    • FORMAT
      Gibt an, dass ein neuer Mediensatz erstellt werden kann. FORMAT bewirkt, dass vom Sicherungsvorgang ein neuer Medienheader auf alle Medienträger geschrieben wird, die für den Sicherungsvorgang verwendet werden. Der vorhandene Inhalt des Datenträgers wird ungültig, da alle vorhandenen Medienheader und Sicherungssätze überschrieben werden.

      ms186865.note(de-de,SQL.90).gifWichtig:
      Verwenden Sie FORMAT mit Vorsicht. Die Formatierung von Datenträgern eines Mediensatzes führt dazu, dass der gesamte Mediensatz nicht mehr verwendet werden kann. Wird beispielsweise ein einzelnes Band initialisiert, das zu vorhandenen Stripesetmedien gehört, führt dies dazu, dass der gesamte Mediensatz unbrauchbar wird.

      Durch die Angabe von FORMAT ist SKIP impliziert. SKIP muss nicht explizit angegeben werden.

  • MEDIADESCRIPTION = { text | **@**text_variable }
    Gibt die Freiform-Textbeschreibung des Mediensatzes an. Diese kann aus maximal 255 Zeichen bestehen.
  • MEDIANAME = { media_name | **@**media_name_variable}
    Gibt den Mediennamen für den gesamten Sicherungsmediensatz an. Der Medienname darf nicht mehr als 128 Zeichen umfassen. Wird MEDIANAME angegeben, muss dieser Name dem vorher angegebenen Mediennamen auf den Sicherungsdatenträgern entsprechen. Wird er nicht angegeben, oder ist die Option SKIP festgelegt, findet keine Prüfung des Mediennamens statt.

  • MEDIAPASSWORD = { mediapassword | **@**mediapassword_variable }
    Legt das Kennwort für den Mediensatz fest. MEDIAPASSWORD ist eine Zeichenfolge.

    Wenn für den Mediensatz ein Kennwort definiert ist, muss das Kennwort angegeben werden, um einen Sicherungssatz auf diesem Mediensatz zu erstellen. Das Kennwort muss auch angegeben werden, wenn ein Wiederherstellungsvorgang mit dem Mediensatz ausgeführt werden soll. Kennwortgeschützte Medien können nur überschrieben werden, indem sie neu formatiert werden. Weitere Informationen finden Sie unter der Option FORMAT. (Weitere Informationen zum Verwenden von Kennwörtern finden Sie weiter unten im Abschnitt "Berechtigungen".)

    ms186865.security(de-de,SQL.90).gifSicherheitshinweis:
    Dieses Kennwort bietet also nur unzureichenden Schutz. Es soll vermeiden, dass autorisierte wie nicht autorisierte Benutzer mithilfe von Tools für SQL Server 2005 fehlerhafte Wiederherstellungen ausführen. Es verhindert jedoch nicht das Lesen der Sicherungsdaten mit anderen Mitteln oder das Ersetzen des Kennwortes. 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 (Access Control List oder ACL) geschützt sind. Die ACLs sollten für den Verzeichnisstamm eingerichtet werden, unter dem die Sicherungen erstellt werden.
    ms186865.note(de-de,SQL.90).gifHinweis:
    Die Option MEDIAPASSWORD wird in einer zukünftigen Version von SQL Server entfernt.

  • BLOCKSIZE = { blocksize | **@**blocksize_variable }
    Legt die physikalische Blockgröße in Bytes fest. Die unterstützten Größen sind 512, 1024, 2048, 4096, 8192, 16.384, 32.768 und 65.536 (64 KB) Bytes. Der Standardwert ist 65.536 für Bandmedien und sonst 512. In der Regel ist diese Option nicht erforderlich, da von BACKUP automatisch eine Blockgröße ausgewählt wird, die für das Medium geeignet ist. Mit der expliziten Angabe einer Blockgröße wird die automatische Wahl der Blockgröße außer Kraft gesetzt.

    Geben Sie beim Erstellen einer Sicherung, die Sie auf eine CD-ROM kopieren und von dieser wiederherstellen möchten, BLOCKSIZE=2048 an.

    ms186865.note(de-de,SQL.90).gifHinweis:
    Diese Option hat i. d. R. nur dann Auswirkungen auf die Leistung, wenn auf Bandmedien geschrieben wird.

Datenübertragungsoptionen

  • BUFFERCOUNT = { buffercount | **@**buffercount_variable }
    Gibt die Gesamtanzahl von E/A-Puffern an, die für den Sicherungsvorgang verwendet werden sollen. Sie können eine beliebige positive ganze Zahl angeben. Eine große Pufferanzahl kann jedoch wegen eines ungeeigneten virtuellen Adressraumes im Prozess Sqlservr.exe zu Fehlern aufgrund von nicht genügend Arbeitsspeicher führen.

    Der gesamte von den Puffern belegte Speicherplatz wird durch buffercount*****maxtransfersize bestimmt.

  • MAXTRANSFERSIZE = { maxtransfersize | **@**maxtransfersize_variable }
    Gibt die größte zu verwendende Übertragungseinheit zwischen SQL Server und dem Sicherungsmedium in Bytes an. Die möglichen Werte sind Vielfache von 65.536 Bytes (64 KB) bis hin zu 4.194.304 Bytes (4 MB).

Fehlerverwaltungsoptionen

Mit diesen Optionen können Sie bestimmen, ob Sicherungsprüfsummen für den Sicherungsvorgang aktiviert werden und ob der Vorgang beim Auftreten eines Fehlers beendet wird.

  • { NO_CHECKSUM | CHECKSUM }
    Steuert, ob Sicherungsprüfsummen aktiviert sind.

    • NO_CHECKSUM
      Das Generieren von Sicherungsprüfsummen (und die Überprüfung von Seitenprüfsummen) wird explizit deaktiviert. Dies ist das Standardverhalten.

    • CHECKSUM
      Aktiviert Sicherungsprüfsummen, sodass BACKUP folgende Möglichkeiten hat:

      1. Vor dem Schreiben einer Seite auf das Sicherungsmedium werden von BACKUP die Informationen auf Seitenebene überprüft (Seitenprüfsumme oder zerrissene Seite), wenn diese Informationen auf der Seite vorhanden sind.
      2. Unabhängig davon, ob Seitenprüfsummen vorhanden sind, generiert BACKUP eine separate Sicherungsprüfsumme für den Sicherungsdatenstrom. Bei den Wiederherstellungsvorgängen kann optional die Sicherungsprüfsumme verwendet werden, um zu überprüfen, ob die Sicherung beschädigt ist. Die Sicherungsprüfsumme wird auf den Sicherungsmedien gespeichert, nicht in den Datenbankseiten. Die Sicherungsprüfsumme kann bei der Wiederherstellung optional verwendet werden.

      Die Verwendung von Sicherungsprüfsummen kann sich auf die Arbeitsauslastung und den Durchsatz bei der Sicherung auswirken.

  • { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }
    Steuert, ob ein Sicherungsvorgang beendet oder fortgesetzt wird, nachdem ein Fehler bei der Seitenprüfsumme aufgetreten ist.

    • STOP_ON_ERROR
      Von BACKUP wird ein Fehler erzeugt, wenn eine Seitenprüfsumme nicht stimmt. Dies ist das Standardverhalten.

    • CONTINUE_AFTER_ERROR
      BACKUP wird auch dann fortgesetzt, wenn Fehler auftreten, z. B. ungültige Prüfsummen oder zerrissene Seiten.

      Wenn Sie das Protokollfragment mithilfe der Option NO_TRUNCATE nicht sichern können, wenn die Datenbank beschädigt ist, können Sie versuchen, eine Sicherung des Protokollfragments auszuführen, indem Sie CONTINUE_AFTER_ERROR anstelle von NO_TRUNCATE angeben.

Kompatibilitätsoptionen

  • RESTART
    Hat keinerlei Auswirkungen. Die Option wird von der Version aus Gründen der Kompatibilität mit früheren Versionen von SQL Server angenommen.

Überwachungsoptionen

  • STATS [ = percentage ]
    Zeigt nach jedem abgeschlossenen Prozentsatz (percentage) eine Meldung an und wird zur Fortschrittsanzeige verwendet. Wird percentage nicht angegeben, zeigt SQL Server jedes Mal eine Meldung an, wenn weitere 10 Prozent des Vorgangs abgeschlossen sind.

    Mit der Option STATS wird der Prozentsatz gemeldet, der beim Erreichen des Schwellenwertes für das nächste Meldungsintervall abgeschlossen ist. Bei dem angegebenen Prozentsatz handelt es sich um einen ungefähren Wert. Wird beispielsweise STATS=10 festgelegt und sind 40 Prozent des Vorgangs abgeschlossen, dann zeigt die Option u. U. 43 Prozent an. Bei größeren Sicherungssätzen stellt dies kein Problem dar, da sich der Wert für den abgeschlossenen Prozentsatz zwischen abgeschlossenen E/A-Aufrufen nur sehr langsam verändert.

Bandoptionen

Diese Optionen werden nur für Bandmedien verwendet. Diese Optionen werden ignoriert, wenn ein anderes Medium als ein Bandmedium verwendet wird.

  • { REWIND | NOREWIND }

    • REWIND
      Gibt an, dass SQL Server das Band freigibt und zurückspult. REWIND ist die Standardeinstellung.

    • NOREWIND
      Gibt an, dass SQL Server das Band nach dem Sicherungsvorgang offen hält. Diese Option trägt zur Leistungsverbesserung bei, wenn mehrere Sicherungsvorgänge auf einem Band ausgeführt werden.

      NOREWIND impliziert NOUNLOAD, und diese Optionen sind innerhalb einer BACKUP-Anweisung inkompatibel.

      ms186865.note(de-de,SQL.90).gifHinweis:
      Wenn Sie NOREWIND verwenden, bleibt die Instanz von SQL Server Besitzer des Bandlaufwerks, bis in einer BACKUP- oder RESTORE-Anweisung, die in demselben Prozess ausgeführt wird, die Option REWIND oder UNLOAD verwendet wird oder bis die Serverinstanz heruntergefahren wird. Ein Offenhalten des Bandes verhindert, dass andere Prozesse auf das Band zugreifen können. Informationen zum Anzeigen einer Liste offener Bänder und zum Schließen eines offenen Bandes finden Sie unter Sicherungsmedien.

  • { UNLOAD | NOUNLOAD }

    ms186865.note(de-de,SQL.90).gifHinweis:
    UNLOAD/NOUNLOAD ist eine Sitzungseinstellung, die für die Dauer der Sitzung oder bis zur Angabe der alternativen Einstellung bestehen bleibt.
    • UNLOAD
      Gibt an, dass das Band automatisch zurückgespult und ausgeworfen wird, wenn die Sicherung vollständig ausgeführt ist. UNLOAD ist die Standardeinstellung beim Beginn einer Sitzung.
    • NOUNLOAD
      Gibt an, dass das Band nach dem BACKUP-Vorgang im Bandlaufwerk geladen bleibt.
ms186865.note(de-de,SQL.90).gifHinweis:
Beim Sichern auf einem Bandsicherungsmedium wirkt sich die Option BLOCKSIZE auf die Leistung des Sicherungsvorgangs aus. Diese Option hat i. d. R. nur dann Auswirkungen auf die Leistung, wenn auf Bandmedien geschrieben wird.

Protokollspezifische Optionen

Diese Optionen werden nur mit BACKUP LOG verwendet.

ms186865.note(de-de,SQL.90).gifHinweis:
Wenn Sie keine Protokollsicherungen vornehmen möchten, verwenden Sie das einfache Wiederherstellungsmodell. Weitere Informationen finden Sie unter Sicherungen mit dem einfachen Wiederherstellungsmodell.

  • { NORECOVERY | STANDBY **=**undo_file_name }

    • NORECOVERY
      Sichert das Protokollfragment und belässt die Datenbank im RESTORING-Status. NORECOVERY ist hilfreich, wenn ein Failover zu einer sekundären Datenbank erfolgt oder wenn das Protokollfragment vor einem RESTORE-Vorgang gesichert wird.

      Zum Ausführen einer Protokollsicherung, bei der die Protokollkürzung ausgelassen wird und die Datenbank automatisch den Status RESTORING erhält, verwenden Sie die Optionen NO_TRUNCATE und NORECOVERY zusammen.

    • STANDBY **=**standby_file_name
      Sichert das Protokollfragment und belässt die Datenbank im schreibgeschützten Modus und im STANDBY-Status. Die STANDBY-Klausel schreibt Standbydaten (wobei ein Rollback durchgeführt wird, aber mit der Option weiterer Wiederherstellungen). Die Verwendung der Option STANDBY ist gleichbedeutend mit BACKUP LOG WITH NORECOVERY gefolgt von RESTORE WITH STANDBY.

      Wenn der Standbymodus verwendet wird, ist eine Standbydatei erforderlich, die mit standby_file_name angegeben wird und deren Speicherort im Protokoll der Datenbank gespeichert wird. Ist die angegebene Datei bereits vorhanden, wird sie von Datenbankmodul überschrieben. Ist sie noch nicht vorhanden, wird sie von Datenbankmodul erstellt. Die Standbydatei wird Teil der Datenbank.

      Diese Datei enthält die Änderungen aus dem Rollback, die rückgängig gemacht werden müssen, wenn zu einem späteren Zeitpunkt RESTORE LOG-Vorgänge angewendet werden sollen. Es muss ausreichend Speicherplatz für die Vergrößerung der Standbydatei vorhanden sein, damit diese Datei alle Seiten aus der Datenbank enthalten kann, die durch das Rollback für die Transaktionen ohne Commit geändert wurden.

  • NO_TRUNCATE
    Gibt an, dass das Protokoll nicht abgeschnitten wird, und führt dazu, dass Datenbankmodul versucht, die Sicherung unabhängig vom Status der Datenbank durchzuführen. Daraus folgt, dass eine Sicherung, die mit NO_TRUNCATE erstellt wird, u. U. unvollständige Metadaten enthält. Diese Option ermöglicht es, das Protokoll auch dann zu sichern, wenn die Datenbank beschädigt ist.

    Die Option NO_TRUNCATE von BACKUP LOG ist gleichbedeutend mit der Angabe von COPY_ONLY und CONTINUE_AFTER_ERROR.

    Ohne die Option NO_TRUNCATE muss die Datenbank online sein.

    Ist die Datenbank im Status OFFLINE oder EMERGENCY, ist die Sicherung auch mit NO_TRUNCATE nicht zulässig.

  • [ NO_LOG | TRUNCATE_ONLY ]

    ms186865.note(de-de,SQL.90).gifHinweis:
    Diese Option wird in zukünftigen Versionen von SQL Server nicht mehr bereitgestellt. Vermeiden Sie sie deshalb bei Neuentwicklungen, und planen Sie die Änderung von Anwendungen, in denen sie derzeit verwendet wird.

    Wird nur in BACKUP LOG-Anweisungen verwendet und führt einen Prüfpunkt aus, um das Abschneiden des Transaktionsprotokolls manuell zu erzwingen. NO_LOG und TRUNCATE_ONLY sind Synonyme. Die Angabe eines Sicherungsmediums ist nicht notwendig, da das Protokoll nicht gesichert wird.

    Beim einfachen Wiederherstellungsmodell wird durch Ausführen eines Prüfpunktes der inaktive Teil des Protokolls entfernt, ohne eine Sicherungskopie zu erstellen. Dabei wird das Protokoll abgeschnitten, indem alles außer dem aktiven Protokoll verworfen wird. Durch diese Option wird Speicherplatz freigegeben, jedoch mit möglichem Datenverlust. Nachdem das Protokoll mit NO_LOG oder TRUNCATE_ONLY abgeschnitten wurde, können die im abgeschnittenen Teil des Protokolls aufgezeichneten Änderungen bis zur nächsten Datenbanksicherung nicht wiederhergestellt werden. Daher müssen Sie zu Wiederherstellungszwecken nach Verwendung einer dieser Optionen sofort BACKUP DATABASE ausführen, um eine vollständige oder differenzielle Sicherung zu erstellen.

    ms186865.Caution(de-de,SQL.90).gifVorsicht:
    Verwenden Sie NO_LOG oder TRUNCATE_ONLY niemals, um das Transaktionsprotokoll manuell abzuschneiden, weil dadurch die Protokollkette unterbrochen wird. Bis zum Erstellen der nächsten vollständigen oder differenziellen Datenbanksicherung ist die Datenbank nicht vor einem Medienausfall geschützt. Verwenden Sie die manuelle Protokollkürzung nur unter sehr speziellen Umständen, und erstellen Sie direkt danach Datensicherungen.

Hinweise

Datenbank- oder Protokollsicherungen können an das Ende jedes beliebigen Datenträgers oder Bandmediums angefügt werden. Damit ist es möglich, eine Datenbank und ihre Transaktionsprotokolle an einem einzelnen physikalischen Speicherort unterzubringen.

Die BACKUP-Anweisung ist nicht in einer expliziten oder implizierten Transaktion zulässig.

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

Informationen zur Sicherungsterminologie, zu Sicherungsmedien und zum Verwalten von Sicherungen finden Sie unter Arbeiten mit Sicherungsmedien in SQL Server.

Parallelität

SQL Server verwendet einen Onlinesicherungsprozess, um das Ausführen einer Datenbanksicherung zu ermöglichen, während die Datenbank weiterhin verwendet wird. Bei einer Sicherung sind die meisten Vorgänge möglich, so sind z. B. die Anweisungen INSERT, UPDATE oder DELETE bei einem Sicherungsvorgang zulässig.

Folgende Vorgänge können nicht ausgeführt werden, während eine Datenbank oder ein Transaktionsprotokoll gesichert wird:

  • Vorgänge, die die Dateiverwaltung betreffen, wie z. B. die ALTER DATABASE-Anweisung mit der Option ADD FILE oder REMOVE FILE.
  • Vorgänge zum Verkleinern der Datenbank oder von Dateien. Dazu gehören auch Vorgänge zum automatischen Verkleinern.

Wenn sich ein Sicherungsvorgang mit einem Dateiverwaltungs- oder Verkleinerungsvorgang überschneidet, tritt ein Konflikt auf. Unabhängig davon, welcher am Konflikt beteiligte Vorgang zuerst begonnen hat, wartet der zweite Vorgang auf das Timeout der Sperre, die vom ersten Vorgang angewendet wurde (der Timeoutzeitraum wird durch eine Timeouteinstellung für die Sitzung gesteuert). Wenn die Sperre während des Timeoutzeitraums aufgehoben wird, wird der zweite Vorgang fortgesetzt. Wenn das Timeout für die Sperre eintritt, erzeugt der zweite Vorgang einen Fehler.

Formatieren von Sicherungsmedien

Sicherungsmedien werden durch eine BACKUP-Anweisung formatiert, und zwar nur dann, wenn eine der folgenden Bedingungen zutrifft:

  • Die Option FORMAT ist angegeben.
  • Das Medium ist leer.
  • Mit dem Vorgang wird ein Anschlussband geschrieben.

Weitere Informationen finden Sie unter Erstellen eines neuen Mediensatzes.

Sicherungstypen

Die unterstützten Sicherungstypen sind vom Wiederherstellungsmodell der Datenbank abhängig, und zwar wie folgt:

  • Alle Wiederherstellungsmodelle unterstützen vollständige und differenzielle Sicherungen von Daten.

    Umfang der Sicherung Sicherungstypen

    Gesamte Datenbank

    Datenbanksicherungen umfassen die gesamte Datenbank.

    Teilweise Datenbanksicherung

    Teilsicherungen umfassen Dateigruppen mit Lese-/Schreibzugriff und möglicherweise mindestens eine schreibgeschützte Datei oder Dateigruppe.

    Datei oder Dateigruppe

    Dateisicherungen umfassen mindestens eine Datei oder Dateigruppe und sind nur für Datenbanken relevant, in denen mehrere Dateigruppen enthalten sind. Beim einfachen Wiederherstellungsmodell werden Dateisicherungen im Wesentlichen auf schreibgeschützte sekundäre Dateigruppen beschränkt.

  • Beim vollständigen oder massenprotokollierten Wiederherstellungsmodell enthalten die konventionellen Sicherungen auch Transaktionsprotokollsicherungen (oder Protokollsicherungen), die erforderlich sind. Jede Protokollsicherung umfasst den Teil des Transaktionsprotokolls, der beim Erstellen der Sicherung aktiv war, und enthält alle Protokolldatensätze, die in einer vorherigen Protokollsicherung nicht gesichert wurden.

    ms186865.note(de-de,SQL.90).gifHinweis:
    Bevor Sie die erste Protokollsicherung erstellen können, müssen Sie eine vollständige Sicherung erstellen.

    Weitere Informationen finden Sie unter Verwenden von Transaktionsprotokollsicherungen.

  • Eine Kopiesicherung ist eine besondere vollständige Sicherung oder Protokollsicherung, die von der normalen Sequenz konventioneller Sicherungen unabhängig ist. Verwenden Sie zum Erstellen einer Kopiesicherung die Option COPY_ONLY in der BACKUP-Anweisung. Weitere Informationen finden Sie unter Kopiesicherungen.

Sichern von Volltextdaten

Bei einer vollständigen Datenbanksicherung werden in SQL Server 2005 Volltextdaten zusammen mit anderen Datenbankdaten gesichert. Beim Sicherungsvorgang werden Volltextkataloge als Dateien behandelt. So können beispielsweise die Kataloge isoliert gesichert werden, indem die FILE=-Klausel zur Auswahl der Kataloge verwendet wird. (Der logische Dateiname für einen Volltextkatalog hat das Format sysft_<catalog name>.)

Bei einer Sicherung wird für den Katalog ein schreibgeschützter Modus festgelegt, sodass Crawlaktivitäten (das Anlegen und Verwalten eines Volltextindexes) bis zum Abschluss der Sicherung angehalten werden.

Interaktion von SKIP, NOSKIP, INIT und NOINIT

In dieser Tabelle werden die Interaktionen zwischen den Optionen { NOINIT | INIT } und { NOSKIP | SKIP } beschrieben.

ms186865.note(de-de,SQL.90).gifHinweis:
Wenn das Bandmedium leer oder die Datenträger-Sicherungsdatei nicht vorhanden ist, wird bei allen nachfolgend aufgeführten Interaktionen ein Medienheader geschrieben und erst danach fortgefahren. Wenn das Medium nicht leer ist und keinen gültigen Medienheader aufweist, wird von diesen Vorgängen die Rückmeldung gegeben, dass dies kein gültiges MTF-Medium ist, und der Sicherungsvorgang wird beendet.
  NOINIT INIT

NOSKIP

Überprüft, wenn der Datenträger einen gültigen Medienheader enthält, das Medienkennwort und ob der Medienname mit dem angegebenen MEDIANAME (sofern vorhanden) übereinstimmt. Wenn dies der Fall ist, wird der Sicherungssatz angefügt, wobei alle vorhandenen Sicherungssätze beibehalten werden.

Enthält der Datenträger keinen gültigen Medienheader, tritt ein Fehler auf.

Wenn der Datenträger einen gültigen Medienheader enthält, werden die folgenden Überprüfungen durchgeführt:

  • Überprüft das Medienkennwort.2
  • Wenn MEDIANAME angegeben wurde, wird überprüft, ob der angegebene Medienname mit dem Mediennamen im Medienheader übereinstimmt.
  • Stellt sicher, dass auf dem Medium keine noch nicht abgelaufenen Sicherungssätze vorhanden sind.
    Wenn solche vorhanden sind, wird die Sicherung beendet.

Wenn diese Überprüfungen erfolgreich sind, werden alle Sicherungssätze auf dem Medium überschrieben, und nur der Medienheader wird beibehalten.

Wenn der Datenträger keinen gültigen Medienheader enthält, wird dieser mithilfe der angegebenen Optionen MEDIANAME, MEDIAPASSWORD und MEDIADESCRIPTION (sofern vorhanden) generiert.

SKIP

Wenn der Datenträger einen gültigen Medienheader enthält, wird das Medienkennwort überprüft und der Sicherungssatz angefügt. Alle vorhandenen Sicherungssätze werden beibehalten.

Wenn der Datenträger einen gültigen 1-Medienheader enthält, wird das Medienkennwort überprüft, und alle Sicherungssätze auf dem Medium werden überschrieben. Nur der Medienheader wird beibehalten.

Wenn das Medium leer ist, wird ein Medienheader mithilfe der Optionen MEDIANAME, MEDIAPASSWORD und MEDIADESCRIPTION (sofern vorhanden) generiert.

1 Zur Gültigkeit gehören die MTF-Versionsnummer und andere Headerinformationen. Wenn die angegebene Version nicht unterstützt wird oder einen unerwarteten Wert hat, tritt ein Fehler auf.

2 Damit der Benutzer einen Sicherungsvorgang ausführen kann, muss er den entsprechenden festen Datenbank- oder Serverrollen angehören und das richtige Medienkennwort angeben.

Tabellen mit Sicherungsverläufen

In SQL Server sind folgende Tabellen mit Sicherungsverläufen enthalten, in denen Sicherungsaktivitäten nachverfolgt werden:

Wird eine Wiederherstellung durchgeführt, wenn der Sicherungssatz noch nicht in der msdb-Datenbank erfasst ist, dann werden möglicherweise die Tabellen mit Sicherungsverläufen verändert.

Kompatibilitätsunterstützung

ms186865.Caution(de-de,SQL.90).gifVorsicht:
Sicherungen, die mit aktuelleren Versionen von SQL Server erstellt werden, können in früheren Versionen von SQL Server nicht wiederhergestellt werden.

Zum Ermöglichen der Kompatibilität mit früheren Versionen von SQL Server unterstützt BACKUP folgende Schlüsselwörter:

  • Die Option RESTART wird für die Kompatibilität angenommen, hat jedoch in SQL Server 2005 keine Auswirkungen.
  • Zum Beibehlaten der Abwärtskompatibilität können Sie das DUMP-Schlüsselwort anstelle des BACKUP-Schlüsselwortes in der BACKUP-Anweisung verwenden. Außerdem können Sie das TRANSACTION-Schlüsselwort anstelle des LOG-Schlüsselwortes verwenden. DUMP DATABASE bzw. DUMP TRANSACTION werden von SQL Server-Datenbankmodul genauso interpretiert wie BACKUP DATABASE bzw. BACKUP LOG.
    ms186865.note(de-de,SQL.90).gifWichtig:
    Die DUMP-Anweisung wird aus Gründen der Abwärtskompatibilität bereitgestellt. Dieses Feature wird in einer zukünftigen Version von Microsoft SQL Server entfernt. Verwenden Sie dieses Feature beim Entwickeln neuer Anwendungen nicht, und planen Sie das Ändern von Anwendungen, in denen es zurzeit verwendet wird. Verwenden Sie stattdessen BACKUP.

Sicherungsmedien in Stripesetmedien

Bei einem Stripeset handelt es sich um eine Gruppe von Datenträgerdateien, für die die Daten in Blöcke aufgeteilt und in einer festen Reihenfolge verteilt werden. Die Anzahl der in einem Stripeset verwendeten Sicherungsmedien muss gleich bleiben (es sei denn, die Medien werden mit FORMAT neu initialisiert).

Im folgenden Beispiel wird eine Sicherung der AdventureWorks-Datenbank in ein neues Stripesetmedium geschrieben, für das drei Datenträgerdateien verwendet werden.

BACKUP DATABASE AdventureWorks
TO DISK='X:\SQLServerBackups\AdventureWorks1.bak', 
DISK='Y:\SQLServerBackups\AdventureWorks2.bak', 
DISK='Z:\SQLServerBackups\AdventureWorks3.bak'
WITH FORMAT,
   MEDIANAME = 'AdventureWorksStripedSet0',
   MEDIADESCRIPTION = 'Striped media set for AdventureWorks database;
GO

Nachdem ein Sicherungsmedium als Teil eines Stripesets definiert wurde, kann es nicht für eine Sicherung mit einem einzelnen Medium verwendet werden, es sei denn, FORMAT wird angegeben. Ebenso kann ein Sicherungsmedium, das Sicherungen enthält, die nicht von einem Stripeset stammen, erst dann in einem Stripeset verwendet werden, wenn FORMAT angegeben wird. Verwenden Sie FORMAT, um einen im Stripesetformat vorliegenden Sicherungssatz zu teilen.

Ist weder MEDIANAME noch MEDIADESCRIPTION angegeben, wenn ein Medienheader geschrieben wird, bleibt das entsprechende Feld im Medienheader leer.

Verwenden eines gespiegelten Mediensatzes

In der Regel sind Sicherungen ungespiegelt, und BACKUP-Sicherungen enthalten einfach eine TO-Klausel. Pro Mediensatz sind jedoch insgesamt vier Spiegel möglich. Bei einem gespiegelten Mediensatz schreibt der Sicherungsvorgang in mehrere Gruppen von Sicherungsmedien. Jede Gruppe von Sicherungsmedien umfasst einen einzelnen Spiegel im gespiegelten Mediensatz. Jede Spiegelung muss dieselbe Anzahl und denselben Typ von physikalischen Sicherungsmedien verwenden, die alle über dieselben Eigenschaften verfügen müssen.

Zum Sichern eines gespiegelten Mediensatzes müssen alle Spiegel vorhanden sein. Zum Sichern eines gespiegelten Mediensatzes geben Sie die TO-Klausel an, um den ersten Spiegel anzugeben, und geben Sie eine MIRROR TO-Klausel für jeden zusätzlichen Spiegel an.

Bei einem gespiegelten Mediensatz muss jede MIRROR TO-Klausel dieselbe Anzahl (und denselben Typ) von Medien wie die TO-Klausel aufführen. Im folgenden Beispiel wird in einen gespiegelten Mediensatz geschrieben, der zwei Spiegel enthält und drei Medien pro Spiegel verwendet:

BACKUP DATABASE AdventureWorks
TO DISK='X:\SQLServerBackups\AdventureWorks1a.bak', 
DISK='Y:\SQLServerBackups\AdventureWorks2a.bak', 
DISK='Z:\SQLServerBackups\AdventureWorks3a.bak'
MIRROR TO DISK='X:\SQLServerBackups\AdventureWorks1b.bak', 
DISK='Y:\SQLServerBackups\AdventureWorks2b.bak', 
DISK='Z:\SQLServerBackups\AdventureWorks3b.bak';
GO
ms186865.note(de-de,SQL.90).gifWichtig:
Dieses Beispiel wurde so entwickelt, dass Sie es auf Ihrem lokalen System testen können. In der Praxis würde das Sichern auf mehreren Medien desselben Laufwerks die Leistung beeinträchtigen und die Redundanz zunichte machen, für die gespiegelte Mediensätze entwickelt wurden.

Medienfamilien in gespiegelten Mediensätzen

Jedes in der TO-Klausel einer BACKUP-Sicherung angegebene Sicherungsmedium entspricht einer Medienfamilie. Werden beispielsweise in den TO-Klauseln drei Medien aufgelistet, schreibt BACKUP Daten in drei Medienfamilien. In einem gespiegelten Mediensatz muss jeder Spiegel eine Kopie jeder Medienfamilie enthalten. Aus diesem Grund muss die Anzahl der Medien in jedem Spiegel identisch sein.

Wenn für jeden Spiegel mehrere Medien aufgeführt sind, bestimmt die Reihenfolge der Medien, welche Medienfamilie in ein bestimmtes Medium geschrieben wird. In jeder Medienliste entspricht beispielsweise das zweite Medium der zweiten Medienfamilie. Für die im obigen Beispiel genannten Medien ist die Entsprechung zwischen Medien und Medienfamilien in der folgenden Tabelle dargestellt:

Spiegelung Medienfamilie 1 Medienfamilie 2 Medienfamilie 3

0

C:\AdventureWorks1a.bak

C:\AdventureWorks2a.bak

C:\AdventureWorks3a.bak

1

C:\AdventureWorks1b.bak

C:\AdventureWorks2b.bak

C:\AdventureWorks3b.bak

Eine Medienfamilie muss immer auf demselben Medium innerhalb eines bestimmten Spiegels gesichert werden. Daher müssen Sie bei Verwendung eines vorhandenen Mediensatzes jedes Mal die Medien eines Spiegels in derselben Reihenfolge wie beim Erstellen des Mediensatzes aufführen.

Weitere Informationen zu gespiegelten Mediensätzen finden Sie unter Verwenden gespiegelter Sicherungsmediensätze. Weitere Informationen zu Mediensätzen und Medienfamilien finden Sie unter Mediensätze, Medienfamilien und Sicherungssätze.

Berechtigungen

Mitglieder der festen Serverrolle sysadmin und der festen Datenbankrollen db_owner und db_backupoperator verfügen standardmäßig über BACKUP DATABASE- und BACKUP LOG-Berechtigungen.

Außerdem kann der Benutzer Kennwörter für einen Mediensatz, für einen Sicherungssatz oder für beides angeben. Wenn für einen Mediensatz ein Kennwort definiert ist, muss der Benutzer das Medienkennwort angeben, um diese Vorgänge auszuführen. Entsprechend ist ein Wiederherstellungsvorgang nur möglich, wenn im RESTORE-Befehl das richtige Medienkennwort und das richtige Sicherungssatz-Kennwort angegeben werden.

Das Definieren von Kennwörtern für Sicherungssätze und Mediensätze ist eine optionale Feature der BACKUP-Anweisung. Der von diesem Kennwort bereitgestellte Schutz ist schwach. Es soll die falsche Wiederherstellung mithilfe von SQL Server 2005-Tools durch autorisierte oder nicht autorisierte Benutzer verhindern. Es verhindert nicht das Lesen der Sicherungsdaten mithilfe anderer Mittel oder die Ersetzung des Kennwortes. Kennwörter verhindern außerdem nicht das Überschreiben von Medien mit der Option FORMAT. Es wird empfohlen, sichere Kennwörter zu verwenden. Weitere Informationen zu sicheren Kennwörtern finden Sie unter Sichere Kennwörter.

Daher können Kennwörter, obwohl ihre Verwendung die Inhalte von Medien vor nicht autorisiertem Zugriff mit SQL Server-Tools in hohem Maße schützt, diese Inhalte nicht vor dem Überschreiben schützen. Außerdem verhindern Kennwörter nicht vollständig den unbefugten Zugriff auf die Inhalte von Medien, da die Daten in den Sicherungssätzen nicht verschlüsselt sind und daher mit Programmen ausgewertet werden können, die speziell für diesen Zweck erstellt wurden. In Fällen, in denen Sicherheit höchste Bedeutung hat, sollte unbedingt verhindert werden, dass unbefugte Personen Zugriff auf die entsprechenden Medien haben.

Es führt zu einem Fehler, wenn ein Kennwort für Objekte angegeben wird, die nicht mit einem zugehörigen Kennwort erstellt wurden.

BACKUP erstellt den Sicherungssatz mit dem Sicherungssatzkennwort, das in der Option PASSWORD angegeben ist. Darüber hinaus überprüft die BACKUP-Anweisung in der Regel vor dem Schreiben auf das Medium das Medienkennwort, das in der Option MEDIAPASSWORD angegeben ist. Die BACKUP-Anweisung überprüft das Medienkennwort nur dann nicht, wenn sie das Medium formatiert, wodurch der Medienheader überschrieben wird. Wenn BACKUP den Medienheader schreibt, weist BACKUP dem Mediensatzkennwort den Wert zu, der in der Option MEDIAPASSWORD angegeben ist.

Informationen zu den Auswirkungen von Kennwörtern auf die Optionen SKIP, NOSKIP, INIT und NOINIT finden Sie im Abschnitt "Hinweise" weiter unten in diesem Thema.

Besitz- und Berechtigungsprobleme hinsichtlich der physikalischen Datei des Sicherungsmediums können einen Sicherungsvorgang beeinträchtigen. SQL Server muss in der Lage sein, Lese- und Schreibvorgänge für das Medium auszuführen. Das Konto, unter dem der SQL Server-Dienst ausgeführt wird, muss über Schreibberechtigungen verfügen. Allerdings prüft die gespeicherte Prozedur sp_addumpdevice, die den Systemtabellen einen Eintrag für ein Medium hinzufügt, nicht die Dateizugriffsberechtigungen. Solche Probleme mit der physikalischen Datei des Sicherungsmediums treten möglicherweise erst auf, wenn auf die physikalische Ressource zugegriffen wird, um einen Sicherungs- oder Wiederherstellungsvorgang auszuführen.

Beispiele

ms186865.note(de-de,SQL.90).gifHinweis:
Die AdventureWorks-Datenbank wird nur zur Veranschaulichung dargestellt. AdventureWorks ist eine der Beispieldatenbanken in SQL Server 2005. Adventure Works Cycles ist eine zum Demonstrieren von Datenbankkonzepten und -szenarien erfundene Produktionsfirma. Weitere Informationen zu dieser Datenbank finden Sie unter Beispiele und Beispieldatenbanken.

Dieser Abschnitt enthält die folgenden Beispiele:

  • A. Sichern einer vollständigen Datenbank
  • B. Sichern der Datenbank und des Protokolls
  • C. Erstellen einer vollständigen Dateisicherung der sekundären Dateigruppen
  • C. Erstellen einer differenziellen Dateisicherung der sekundären Dateigruppen
  • E. Erstellen eines gespiegelten Mediensatzes für eine Medienfamilie und Sichern auf einen gespiegelten Mediensatz für eine Medienfamilie
  • F. Erstellen eines gespiegelten Mediensatzes für mehrere Medienfamilien und Sichern auf einen gespiegelten Mediensatz für mehrere Medienfamilien
  • G. Sichern auf einen vorhandenen gespiegelten Mediensatz
ms186865.note(de-de,SQL.90).gifHinweis:
In den Themen über die Vorgehensweisen bei der Sicherung sind weitere Beispiele aufgeführt. Weitere Informationen finden Sie unter Sichern und Wiederherstellen (Transact-SQL) (Themen zur Vorgehensweise).

A. Sichern einer vollständigen Datenbank

Im folgenden Beispiel wird die AdventureWorks-Datenbank in einer Datenträgerdatei gesichert.

BACKUP DATABASE AdventureWorks 
 TO DISK = 'Z:\SQLServerBackups\AdvWorksData.bak'
   WITH FORMAT;
GO

B. Sichern der Datenbank und des Protokolls

Im folgenden Beispiel wird die AdventureWorks-Beispieldatenbank gesichert, in der standardmäßig das einfache Wiederherstellungsmodell verwendet wird. Zum Unterstützen der Protokollsicherungen wird die AdventureWorks-Datenbank für die Verwendung des vollständigen Wiederherstellungsmodells geändert.

Im Beispiel wird sp_addumpdevice verwendet, um ein logisches Sicherungsmedium zum Sichern von Daten zu erstellen, AdvWorksData, und ein anderes logisches Sicherungsmedium zum Sichern des Protokolls, AdvWorksLog, wird erstellt.

Im Beispiel wird eine vollständige Datenbanksicherung in AdvWorksData erstellt, und nach einer Aktualisierungsaktivität wird das Protokoll in AdvWorksLog gesichert.

-- To permit log backups, before the full database backup, modify the database 
-- to use the full recovery model.
USE master;
GO
ALTER DATABASE AdventureWorks
   SET RECOVERY FULL;
GO
-- Create AdvWorksData and AdvWorksLog logical backup devices. 
USE master
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksData', 
'Z:\SQLServerBackups\AdvWorksData.bak';
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksLog', 
'Z:\SQLServerBackups\AdvWorksLog.bak';
GO

-- Back up the full AdventureWorks database.
BACKUP DATABASE AdventureWorks TO AdvWorksData;
GO
-- Back up the AdventureWorks log.
BACKUP LOG AdventureWorks
   TO AdvWorksLog;
GO
ms186865.note(de-de,SQL.90).gifHinweis:
Für eine Produktionsdatenbank sollte das Protokoll regelmäßig gesichert werden. Protokollsicherungen sollten möglichst häufig ausgeführt werden, damit ein ausreichender Schutz vor Datenverlusten besteht.

C. Erstellen einer vollständigen Dateisicherung der sekundären Dateigruppen

Im folgenden Beispiel wird eine vollständige Dateisicherung von jeder Datei der beiden sekundären Dateigruppen erstellt.

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
   FILEGROUP = 'SalesGroup1',
   FILEGROUP = 'SalesGroup2'
   TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
GO

C. Erstellen einer differenziellen Dateisicherung der sekundären Dateigruppen

Im folgenden Beispiel wird eine differenzielle Dateisicherung von jeder Datei der beiden sekundären Dateigruppen erstellt.

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
   FILEGROUP = 'SalesGroup1',
   FILEGROUP = 'SalesGroup2'
   TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
   WITH 
      DIFFERENTIAL
GO

E. Erstellen eines gespiegelten Mediensatzes für eine Medienfamilie und Sichern auf einen gespiegelten Mediensatz für eine Medienfamilie

Im folgenden Beispiel wird ein gespiegelter Mediensatz erstellt, der eine einzelne Medienfamilie und vier Spiegel umfasst. Auf diese wird die AdventureWorks-Datenbank gesichert.

BACKUP DATABASE AdventureWorks
TO TAPE = '\\.\tape0'
MIRROR TO TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2'
MIRROR TO TAPE = '\\.\tape3'
WITH
   FORMAT,
   MEDIANAME = 'AdventureWorksSet0'

F. Erstellen eines gespiegelten Mediensatzes für mehrere Medienfamilien und Sichern auf einen gespiegelten Mediensatz für mehrere Medienfamilien

Im folgenden Beispiel wird ein gespiegelter Mediensatz erstellt, in dem jeder Spiegel zwei Medienfamilien enthält. Im Beispiel wird dann die AdventureWorks-Datenbank auf beide Spiegel gesichert.

BACKUP DATABASE AdventureWorks
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
   FORMAT,
   MEDIANAME = 'AdventureWorksSet1'

G. Sichern auf einen vorhandenen gespiegelten Mediensatz

Im folgenden Beispiel wird ein Sicherungssatz an den Mediensatz angefügt, der im vorherigen Beispiel erstellt wurde.

BACKUP LOG AdventureWorks
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH 
   NOINIT,
   MEDIANAME = 'AdventureWorksSet1'
ms186865.note(de-de,SQL.90).gifHinweis:
Die Standardeinstellung NOINIT wird hier zur Verdeutlichung gezeigt.

[Anfang der Beispiele]

Siehe auch

Verweis

ALTER DATABASE (Transact-SQL)
DBCC SQLPERF (Transact-SQL)
RESTORE (Transact-SQL)
RESTORE FILELISTONLY (Transact-SQL)
RESTORE HEADERONLY (Transact-SQL)
RESTORE LABELONLY (Transact-SQL)
RESTORE VERIFYONLY (Transact-SQL)
sp_addumpdevice (Transact-SQL)
sp_configure (Transact-SQL)
sp_helpfile (Transact-SQL)
sp_helpfilegroup (Transact-SQL)

Andere Ressourcen

Erstellen einer vollständigen und einer differenziellen Sicherung einer SQL Server-Datenbank
Arbeiten mit Sicherungsmedien in SQL Server
Mediensätze, Medienfamilien und Sicherungssätze
Verwenden von Transaktionsprotokollsicherungen

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf

Version Verlauf

17. Juli 2006
Geänderter Inhalt:
  • Die Abschnitte "Syntax" und "Argument" wurden neu organisiert, um verwandte Optionen zu gruppieren.
  • Die Beschreibung der Option MIRROR TO wurde erweitert.
  • Der Abschnitt "Sicherungstypen" wurde überarbeitet.
  • Der Abschnitt "Kompatibilitätsunterstützung" wurde hinzugefügt.
  • Der Abschnitt "Verwenden eines gespiegelten Mediensatzes" wurde überarbeitet.
  • Die Beispiele zu einer vollständigen Dateisicherung und einer differenziellen Dateisicherung wurden hinzugefügt.

14. April 2006
Neuer Inhalt:
  • In den Abschnitten zur Syntax und den Argumenten wurden die Optionen BUFFERCOUNT und MAXTRANSFERSIZE hinzugefügt.
Geänderter Inhalt:
  • Die unterstützten Blockgrößen wurden aufgelistet, und der Hinweis zur Leistung in der Beschreibung von BLOCKSIZE wurde aktualisiert.
  • Die Beschreibungen der Optionen {REWIND | NOREWIND} und {UNLOAD | NOUNLOAD} wurden aktualisiert.

05. Dezember 2005
Geänderter Inhalt:
  • Klarere Beschreibung der Optionen NO_LOG und TRUNCATE_ONLY.