BACKUP (Transact-SQL)

Artikel
12/28/2023

Eine SQL-Datenbank wird gesichert.

Auswählen eines Produkts

Wählen Sie in der folgenden Zeile den Namen des Produkts aus, an dem Sie interessiert sind. Dann werden nur Informationen zu diesem Produkt angezeigt.

Weitere Informationen zu Syntaxkonventionen finden Sie unter Transact-SQL-Syntaxkonventionen.

* SQL Server *

SQL Managed Instance

Analytics Platform
System (PDW)

SQL Server

Sichert eine vollständige SQL Server-Datenbank, um eine Datenbanksicherung zu erstellen, oder eine oder mehrere Dateien oder Dateigruppen, um eine Dateisicherung (BACKUP DATABASE) zu erstellen. Sichert bei Verwendung des vollständigen oder massenprotokollierten Wiederherstellungsmodells auch das Transaktionsprotokoll der Datenbank, um eine Protokollsicherung (BACKUP LOG) zu erstellen.

Syntax

--Back 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 ] } ]
[;]

--Back 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 ] } ]
[;]

--Create 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 ] } ]
[;]

--Back 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_options> } [ ,...n ] ]
[;]

--Back up all the databases on an instance of SQL Server (a server)

ALTER SERVER CONFIGURATION
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON
[;]

BACKUP SERVER
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { METADATA_ONLY
           | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up a group of databases
ALTER DATABASE <database>
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON

ALTER DATABASE <...>
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON
...

BACKUP GROUP {<database> [,... ]}
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { METADATA_ONLY
           | <general_WITH_options> [ ,...n ] } ]
[;]

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

<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
 | [ COMPRESSION [ ALGORITHM = { MS_XPRESS | accelerator_algorithm } ] | NO_COMPRESSION ]
 | DESCRIPTION = { 'text' | @text_variable }
 | NAME = { backup_set_name | @backup_set_name_var }
 | CREDENTIAL
 | ENCRYPTION
 | FILE_SNAPSHOT
 | { EXPIREDATE = { 'date' | @date_var }
        | RETAINDAYS = { days | @days_var } }
 | { METADATA_ONLY | SNAPSHOT }

--Media Set Options
   { NOINIT | INIT }
 | { NOSKIP | SKIP }
 | { NOFORMAT | FORMAT }
 | MEDIADESCRIPTION = { 'text' | @text_variable }
 | MEDIANAME = { media_name | @media_name_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 }

--Encryption Options
 ENCRYPTION (ALGORITHM = { AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY } , encryptor_options ) <encryptor_options> ::=
   SERVER CERTIFICATE = Encryptor_Name | SERVER ASYMMETRIC KEY = Encryptor_Name

<log_specific_options> [ ,...n ]::=
--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.

Wenn Sie eine von BACKUP DATABASE (eine Datensicherung) erstellte Sicherung wiederherstellen, wird die komplette Sicherung wiederhergestellt. Nur Protokollsicherungen können bis zu einem bestimmten Zeitpunkt oder bis zu einer bestimmten Transaktion in der Sicherung wiederhergestellt werden.

Hinweis

Für die master kann nur eine vollständige Datenbanksicherung ausgeführt werden.

PROTOKOLL

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.

Eine Protokollsicherung können Sie auf eine bestimmte Zeit oder Transaktion in der Sicherung wiederherstellen, indem Sie WITH STOPAT, STOPATMARK oder STOPBEFOREMARK in Ihrer RESTORE LOG-Anweisung angeben.

Hinweis

Nach einer normalen Protokollsicherung sind einige Transaktionsprotokolldatensätze inaktiv, sofern 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 in Faktoren, die die Protokollkürzung verzögern können.

GROUP (<Datenbank>,... n)

Wurde in SQL Server 2022 (16.x) eingeführt.

Sichern Sie eine Gruppe von Datenbanken. Verwendet eine Momentaufnahmesicherung. Erfordert WITH METADATA_ONLY. Siehe Erstellen einer Transact-SQL-Momentaufnahmesicherung.

SERVER

Wurde in SQL Server 2022 (16.x) eingeführt.

Sichern Sie alle Datenbanken auf einer Instanz von SQL Server. Verwendet eine Momentaufnahmesicherung. Erfordert WITH METADATA_ONLY. Siehe Erstellen einer Transact-SQL-Momentaufnahmesicherung.

METADATA_ONLY

Wurde in SQL Server 2022 (16.x) eingeführt.

Erforderlich für eine Momentaufnahmesicherung. BACKUP SERVER oder BACKUP GROUP... Siehe Erstellen einer Transact-SQL-Momentaufnahmesicherung.

METADATA_ONLY steht für SNAPSHOT. Die VDI-(Virtual Device Interface-)Schnittstelle verwendet SNAPSHOT. Informationen zu VDI finden Sie unter Virtual Device Interface-(VDI-)Referenz.

{ database_name | @database_name_var }

Die Datenbank, für die ein Transaktionsprotokoll, eine Teildatenbank oder die vollständige Datenbank gesichert wird. Wird der Name in Form einer Variablen angegeben (@database_name_var), kann er entweder als Zeichenfolgenkonstante (@database_name_var=database name) oder als Variable eines Zeichenfolgen-Datentyps (mit Ausnahme des Datentyps ntext oder text) angegeben werden.

Hinweis

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.

Hinweis

Verwenden Sie Dateisicherungen dann, wenn eine Datenbanksicherung aufgrund der Datenbankgröße und aufgrund von Leistungsanforderungen nicht möglich ist. Das NUL-Gerät kann zum Testen der Leistung von Sicherungen verwendet werden, sollte aber nicht in Produktionsumgebungen eingesetzt werden.

n
Ein Platzhalter, der anzeigt, dass mehrere Dateien und Dateigruppen in einer durch Trennzeichen getrennten Liste angegeben werden können. Für die Anzahl gibt es keine Einschränkungen.

Weitere Informationen finden Sie unter Vollständige Dateisicherungen und Sichern von Dateien und Dateigruppen.

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.

Wichtig

Durch das explizite Auflisten der Dateigruppen 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 Artikel.

n
Ein Platzhalter, der anzeigt, dass mehrere schreibgeschützte Dateigruppen in einer durch Trennzeichen getrennten Liste angegeben werden können.

Weitere Informationen zu Sicherungen des Protokollfragments finden Sie unter Teilsicherungen.

TO <backup_device> [ ,...n ]

Gibt an, dass es sich bei den zugehörigen Sicherungsmedien entweder um einen nicht gespiegelten Mediensatz oder um den ersten Spiegel innerhalb eines gespiegelten Mediensatzes handelt (für den eine oder mehrere MIRROR TO-Klauseln deklariert sind).

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

{ logical_device_name | @logical_device_name_var }

Gilt für: SQL Server
Der logische Name des Sicherungsmediums, 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 | URL} = { 'physical_device_name' | @physical_device_name_var | 'NUL' }

Gilt für: SQL Server (URL ab SQL Server 2012 (11.x) SP1 CU2)

Gibt eine Datenträgerdatei, ein Bandmedium oder eine URL an.

Das URL-Format wird zum Erstellen von Sicherungen in Microsoft Azure Blob Storage oder einem S3-kompatiblen Objektspeicher verwendet. Weitere Informationen und Beispiele finden Sie hier:

SQL Server-Sicherung und -Wiederherstellung mit Microsoft Azure Blob Storage. Ein Tutorial finden Sie unter Tutorial: SQL Server-Sicherung und -Wiederherstellung in Microsoft Azure Blob Storage.
Die Sicherung und Wiederherstellung in S3-kompatiblem Speicher wurde in SQL Server 2022 (16.x) eingeführt. Weitere Informationen finden Sie unter SQL Server-Sicherung und -Wiederherstellung mit S3-kompatiblem Objektspeicher. Überprüfen Sie auch die Option für SQL Server-Sicherungen über eine URL für S3-kompatiblen Objektspeicher.

Hinweis

Das Datenträgermedium NUL verwirft alle Informationen, die es empfängt, und sollte nur zu Testzwecken verwendet werden. Es ist nicht zur Verwendung in der Produktion bestimmt.

Wichtig

Ab SQL Server 2012 (11.x) SP1 CU2 bis SQL Server 2014 (12.x) können Sie nur auf ein einzelnes Gerät sichern, wenn die Sicherung über URL für Azure Blob Storage erfolgt. Wenn Sie eine Sicherung auf mehreren Geräten durchführen möchten, müssen Sie SQL Server 2016 (13.x) und höher verwenden, und Sie müssen SAS-Token (Shared Access Signature) verwenden. Beispiele für die Erstellung einer Shared Access Signature finden Sie unter SQL Server-Sicherung über URLs und Simplifying creation of SQL Credentials with Shared Access Signature (SAS) tokens on Azure Storage with Powershell (Vereinfachen der Erstellung von SQL-Anmeldeinformationen mit Shared Access Signature-Token in Azure Storage mit PowerShell).

Das Datenträgermedium muss erst dann vorhanden sein, wenn es in einer BACKUP-Anweisung angegeben wird. Wenn das physische Medium vorhanden ist und die Option INIT in der BACKUP-Anweisung nicht angegeben ist, wird die Sicherung an das Medium angefügt.

Hinweis

Das NUL-Gerät verwirft alle Eingaben, die an diese Datei gesendet werden, aber die Sicherung kennzeichnet noch immer alle Seiten als gesichert.

Weitere Informationen finden Sie unter Sicherungsmedien.

Hinweis

Die Option TAPE wird in zukünftigen Versionen von SQL Server nicht mehr bereitgestellt. Nutzen Sie diese Funktionen bei Neuentwicklungen nicht mehr, und planen Sie die Änderung von Anwendungen, die diese Funktion zurzeit verwenden.

n
Ist ein Platzhalter, der angibt, dass bis zu 64 Sicherungsgeräte in einer durch Trennzeichen getrennten Liste angegeben werden können.

SPIEGELUNG AUF <backup_device> [ ,...n ]

Gibt bis zu drei sekundäre Sicherungsmedien an, die die in der TO-Klausel angegebenen Sicherungsmedien spiegeln. 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 der Enterprise Edition von SQL Server verfügbar.

Hinweis

Für MIRROR TO = DISK legt BACKUP automatisch die geeignete Blockgröße für Datenträgermedien auf Basis der Sektorgröße des Datenträgers fest. Wenn der MIRROR TO-Datenträger mit einer anderen Sektorgröße als der als primäres Sicherungsmedium angegebener Datenträger formatiert ist, schlägt der backup-Befehl fehl. Damit Sicherungen auf Geräten mit unterschiedlichen Branchengrößen gespiegelt werden können, muss der BLOCKSIZE-Parameter angegeben werden und auf die höchste Sektorgröße aller Zielgeräte festgelegt werden. Weitere Informationen zur Blockgröße finden Sie weiter unten in diesem Thema unter „BLOCKSIZE“.

<backup_device>
Informationen finden Sie unter „<backup_device>“ weiter oben in diesem Abschnitt.

n
Ist ein Platzhalter, der angibt, dass bis zu 64 Sicherungsgeräte in einer durch Trennzeichen getrennten Liste angegeben werden können. Die Anzahl von Medien in der MIRROR TO-Klausel muss der Anzahl von Medien in der TO-Klausel entsprechen.

Weitere Informationen finden Sie unter „Medienfamilien in gespiegelten Mediensätzen“ im Abschnitt Hinweise weiter unten in diesem Artikel.

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

CREDENTIAL

Gilt für: SQL Server (ab SQL Server 2012 (11.x) SP1 CU2)

Wird nur beim Erstellen einer Sicherung für Azure Blob Storage verwendet.

FILE_SNAPSHOT

Gilt für: SQL Server (ab SQL Server 2016 (13.x)).

Wird zum Erstellen einer Azure-Momentaufnahme der Datenbankdateien verwendet, wenn alle SQL Server-Datenbankdateien unter Verwendung von Azure Blob Storage gespeichert werden. Weitere Informationen finden Sie unter SQL Server-Datendateien in Microsoft Azure. SQL Server Die Momentaufnahmesicherung erstellt Azure-Momentaufnahmen der Datenbankdateien (Daten- und Protokolldateien) in einem konsistenten Zustand. Ein konsistenter Satz von Azure-Momentaufnahmen bildet zusammen eine Sicherung und wird in der Sicherungsdatei aufgezeichnet. Der einzige Unterschied zwischen BACKUP DATABASE TO URL WITH FILE_SNAPSHOT und BACKUP LOG TO URL WITH FILE_SNAPSHOT ist, dass der zweite Wert auch das Transaktionsprotokoll abschneidet, während dies beim ersten Wert nicht der Fall ist. Bei SQL Server Momentaufnahmesicherung ist nur eine Transaktionsprotokollsicherung erforderlich, um eine Datenbank auf den Zeitpunkt der Transaktionsprotokollsicherung wiederherzustellen, nachdem die erste vollständige, von SQL Server für die Einrichtung der Sicherungskette vorausgesetzte Sicherung durchgeführt wurde. Darüber hinaus sind nur zwei Sicherungen des Transaktionsprotokolls erforderlich, um eine Datenbank auf einen Zeitpunkt zwischen den beiden Transaktionsprotokollsicherungen wiederherstellen.

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.

Hinweis

Standardmäßig erstellt BACKUP DATABASE eine vollständige Sicherung.

Weitere Informationen finden Sie unter Differenzielle Sicherungen.

ENCRYPTION

Wird verwendet, um die Verschlüsselung für eine Sicherung anzugeben. Sie können einen Verschlüsselungsalgorithmus angeben, um die Sicherung zu verschlüsseln, oder NO_ENCRYPTION angeben, um die Sicherung nicht zu verschlüsseln. Die Verschlüsselung wird empfohlen, um Sicherungsdateien zu sichern. Die Liste der Algorithmen, die Sie angeben können:

AES_128
AES_192
AES_256
TRIPLE_DES_3KEY
NO_ENCRYPTION

Wenn Sie sich für die Verschlüsselung entscheiden, müssen Sie auch die Verschlüsselung mithilfe der Verschlüsselungsoptionen festlegen:

SERVER CERTIFICATE = Encryptor_Name
SERVER ASYMMETRIC KEY = Encryptor_Name

Bei SERVER CERTIFICATE und SERVER ASYMMETRIC KEY handelt es sich um ein Zertifikat und einen asymmetrischen Schlüssel, die in der master-Datenbank erstellt wurden. Weitere Informationen finden Sie unter CREATE CERTIFICATE bzw. CREATE ASYMMETRIC KEY.

Warnung

Bei Verwendung der Verschlüsselung in Verbindung mit dem FILE_SNAPSHOT-Argument wird die Metadatendatei selbst mithilfe des angegebenen Verschlüsselungsalgorithmus verschlüsselt, und das System überprüft, ob Transparent Data Encryption (TDE) für die Datenbank durchgeführt wurde. Für die Daten selbst erfolgt keine zusätzliche Verschlüsselung. Die Sicherung schlägt fehl, wenn die Datenbank nicht verschlüsselt oder die Verschlüsselung nicht abgeschlossen wurde, bevor die Backup-Anweisung ausgegeben wurde.

Sicherungssatzoptionen

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

Hinweis

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 in RESTORE-Argumente unter „Angeben eines Sicherungssatzes“.

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 sollten in Situationen verwendet werden, 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 DATABASEBACKUP 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.

Wichtig

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.

[ COMPRESSION [ ALGORITHM = ( { MS_XPRESS | accelerator_algorithm } ) ] | NO_COMPRESSION ]

Gibt an, ob für diese Sicherung eine Sicherungskomprimierung verwendet wird, wodurch die Standardeinstellung auf Serverebene überschrieben wird.

Die Sicherungskomprimierung wird bei der Installation standardmäßig deaktiviert. Diese Standardeinstellung kann jedoch durch Festlegen der Serverkonfigurationsoption backup compression default geändert werden. Informationen zum Anzeigen des aktuellen Werts dieser Option finden Sie unter Anzeigen oder Ändern von Servereigenschaften.

Informationen zur Verwendung der Sicherungskomprimierung mit Transparent Data Encryption (TDE)-fähigen Datenbanken finden Sie im Abschnitt Hinweise.

COMPRESSION
Aktiviert die Sicherungskomprimierung explizit.

NO_COMPRESSION
Deaktiviert die Sicherungskomprimierung explizit.

In SQL Server 2022 (16.x) wird ALGORITHM eingeführt, womit ein Komprimierungsalgorithmus für den Vorgang identifiziert wird. Der Standardwert ist MS_XPRESS. Wenn Sie Integrierte Beschleunigung und Abladung konfiguriert haben, können Sie einen von der Lösung bereitgestellten Beschleuniger verwenden. Wenn Sie beispielsweise Intel® QuickAssist Technology (QAT) für SQL Server konfiguriert haben, schließt das folgende Beispiel die Sicherung mit der Schnellinfolösung mit der QATzip-Bibliothek mit der Komprimierungsebene 1 abQZ_DEFLATE.

BACKUP DATABASE <database_name> TO DISK WITH COMPRESSION (ALGORITHM = QAT_DEFLATE)

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.

{ EXPIREDATE ='date' | RETAINDAYS = days }

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 media retention bestimmt. Weitere Informationen finden Sie unter Serverkonfigurationsoptionen.

Wichtig

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. Bei der Angabe als Variable (@date_var) muss das Datum dem konfigurierten Systemformat datetime entsprechen und als eines der folgenden Elemente angegeben werden:

Eine Zeichenfolgenkonstante (@date_var = Datum)
Eine Variable mit einem Zeichenfolgen-Datentyp (mit Ausnahme der Datentypen ntext oder text)
Eine smalldatetime-Variable
Eine datetime-Variable

Beispiel:

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

Informationen zum Angeben der datetime-Werte finden Sie unter Datums- und Uhrzeittypen.

Hinweis

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.

{ METADATA_ONLY | SNAPSHOT }

Gilt für: SQL Server 2022 (16.x)

METADATA_ONLY und SNAPSHOT sind Synonyme.

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äßig an den neuesten Sicherungssatz auf dem Medium (NOINIT) angefügt.

Hinweis

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 weiter unten in diesem Thema unter Mediensätze, Medienfamilien und 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 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 zu überschreiben.

Weitere Informationen finden Sie weiter unten in diesem Thema unter Mediensätze, Medienfamilien und Sicherungssätze.

{ NOSKIP | SKIP }

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

Hinweis

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 Artikel. 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 Volumes 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 Medienvolumes 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 Medienvolumes geschrieben wird, die für den Sicherungsvorgang verwendet werden. Der vorhandene Inhalt des Volumes wird ungültig, da alle vorhandenen Medienheader und Sicherungssätze überschrieben werden.

Wichtig

Verwenden Sie FORMAT mit Bedacht. Die Formatierung von Volumes 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 länger als 128 Zeichen sein. Wird MEDIANAME angegeben, muss dieser Name dem vorher angegebenen Mediennamen auf den Sicherungsvolumes entsprechen. Wird er nicht angegeben, oder ist die Option SKIP festgelegt, findet keine Prüfung des Mediennamens statt.

BLOCKSIZE = { blocksize | @blocksize_variable }

Legt die physische 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 andernfalls 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 überschrieben.

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

Hinweis

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.

Hinweis

Wichtige Informationen zur Verwendung der BUFFERCOUNT-Option finden Sie im Blogeintrag Falsche BufferCount-Datenübertragungsoption kann OOM-Bedingung auslösen.

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

Wenn beim Erstellen von Sicherungen mithilfe des SQL Writer-Diensts für die Datenbank FILESTREAM konfiguriert ist oder speicheroptimierte Dateigruppen enthält, dann sollte MAXTRANSFERSIZE zum Zeitpunkt der Wiederherstellung größer als oder gleich der MAXTRANSFERSIZE sein, die beim Erstellen der Sicherung verwendet wurde.

Für Transparente Datenverschlüsselung (TDE)-fähige Datenbanken mit einer einzelnen Datendatei ist der standardmäßige MAXTRANSFERSIZE-Wert 65536 (64 KB). Für nicht mit TDE verschlüsselte Datenbanken ist der Standardwert von MAXTRANSFERSIZE 1.048.576 (1 MB) bei einer Sicherung auf DISK und 65.536 (64 KB) bei Verwendung von VDI oder TAPE. Weitere Informationen zur Verwendung der Sicherungskomprimierung mit TDE-verschlüsselten Datenbanken finden Sie im Abschnitt Hinweise.

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
Gibt an, dass der Sicherungsvorgang jede Seite auf Prüfsumme und zerrissene Seiten überprüft (wenn aktiviert und verfügbar) und eine Prüfsumme für die gesamte Sicherung generiert.

Die Verwendung von Sicherungsprüfsummen wirkt sich möglicherweise auf Workload und Sicherungsdurchsatz aus.

Weitere Informationen finden Sie unter Mögliche Medienfehler während der Sicherung und Wiederherstellung.

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

Weitere Informationen finden Sie unter Mögliche Medienfehler während der Sicherung und Wiederherstellung.

Kompatibilitätsoptionen

RESTART

Keine Auswirkungen ab SQL Server 2008 (10.0.x). Die Option wird von der Version aus Gründen der Kompatibilität mit früheren Versionen von SQL Server angenommen.

Überwachungsoptionen

STATS [ = Prozentsatz ]

Zeigt nach jedem abgeschlossenen Prozentsatz eine Meldung an und wird als Statusanzeige verwendet. Wird Prozentsatz 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 freigeben und zurückspulen soll. 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.

Hinweis

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 Bands finden Sie unter Sicherungsmedien.

{ UNLOAD | NOUNLOAD }

Hinweis

UNLOAD und NOUNLOAD sind Sitzungseinstellungen, die für die Dauer der Sitzung oder bis zur Angabe der alternativen Einstellung persistent gespeichert wird.

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.

Hinweis

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.

Hinweis

Wenn Sie keine Protokollsicherungen vornehmen möchten, verwenden Sie das einfache Wiederherstellungsmodell. Weitere Informationen finden Sie unter Wiederherstellungsmodelle.

{ 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 Datenbank-Engine überschrieben. Ist sie noch nicht vorhanden, wird sie von Datenbank-Engine 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

Legt fest, dass das Transaktionsprotokoll nicht abgeschnitten werden soll, und veranlasst die Datenbank-Engine, unabhängig vom Zustand der Datenbank eine Sicherung 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 Transaktionsprotokoll auch dann zu sichern, wenn die Datenbank beschädigt ist.

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

Ohne die Option NO_TRUNCATE muss sich die Datenbank im ONLINE-Status befinden. Wenn die Datenbank im SUSPENDED-Status ist, können Sie möglicherweise durch die Angabe von NO_TRUNCATE eine Sicherung erstellen. Wenn sich die Datenbank jedoch im Status OFFLINE oder EMERGENCY befindet, ist die Sicherung auch mit NO_TRUNCATE nicht zulässig. Weitere Informationen zu Datenbankstatus finden Sie unter Datenbankstatus.

Informationen zum Arbeiten mit SQL Server-Sicherungen

In diesem Abschnitt werden die folgenden grundlegenden Sicherungskonzepte erläutert:

Sicherungstypen Kürzung des Transaktionsprotokolls Formatieren von Sicherungsmedien Arbeiten mit Sicherungsmedien und Mediensätzen Wiederherstellen von SQL Server-Sicherungen

Hinweis

Eine Einführung in die Sicherung in SQL Server finden Sie unter Übersicht über Sicherungen.

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. Optional kann jede Datenbanksicherung als Basis einer Serie von einer oder mehreren differenziellen Datenbanksicherungen dienen.
Teilweise Datenbanksicherung	Teilsicherungen umfassen Dateigruppen mit Lese-/Schreibzugriff und möglicherweise mindestens eine schreibgeschützte Datei oder Dateigruppe. Optional kann jede Teilsicherung als Basis einer Serie von einer oder mehreren differenziellen Teilsicherungen dienen.
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. Optional kann jede Dateisicherung als Basis einer Serie von einer oder mehreren differenziellen Dateisicherungen dienen.

Beim vollständigen oder massenprotokollierten Wiederherstellungsmodell enthalten die herkömmlichen Sicherungen auch sequentielle 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.

Wenn Sie die Gefahr eines Datenverlusts minimieren und den damit verbundenen höheren Verwaltungsaufwand in Kauf nehmen möchten, sollten Sie häufige Protokollsicherungen planen. Wenn Sie zwischen vollständigen Sicherungen differenzielle Sicherungen planen, kann dies die Wiederherstellungszeit verkürzen, da Sie nach dem Wiederherstellen der Daten nur eine geringe Anzahl von Protokollsicherungen wiederherstellen müssen.

Es empfiehlt sich, Protokollsicherungen auf einem anderen Volume als die Datenbanksicherungen zu speichern.

Hinweis

Bevor Sie die erste Protokollsicherung erstellen können, müssen Sie eine vollständige Sicherung erstellen.
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.

Kürzung des Transaktionsprotokolls

Um das schnelle Auffüllen des Transaktionsprotokolls einer Datenbank zu vermeiden, sind routinemäßige Sicherungen von entscheidender Bedeutung. Die Protokollkürzung erfolgt beim einfachen Wiederherstellungsmodell automatisch, wenn die Datenbank gesichert wurde, und beim vollständigen Wiederherstellungsmodell, wenn das Transaktionsprotokoll gesichert wurde. Manchmal kann der Kürzungsprozess jedoch verzögert werden. Informationen zu Faktoren, die eine Protokollkürzung verzögern können, finden Sie unter Das Transaktionsprotokoll.

Hinweis

Die Optionen BACKUP LOG WITH NO_LOG und WITH TRUNCATE_ONLY werden nicht mehr unterstützt. Wechseln Sie zum einfachen Wiederherstellungsmodell, wenn Sie zur Wiederherstellung das vollständige oder das massenprotokollierte Wiederherstellungsmodell verwenden und die Protokollsicherungskette aus einer Datenbank entfernen müssen. Weitere Informationen finden Sie unter Anzeigen oder Ändern des Wiederherstellungsmodells einer Datenbank.

Formatieren von Sicherungsmedien

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

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

Arbeiten mit Sicherungsgeräten und Mediensätzen

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 AdventureWorks2022-Datenbank in ein neues Stripesetmedium geschrieben, für das drei Datenträgerdateien verwendet werden.

BACKUP DATABASE AdventureWorks2022
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 AdventureWorks2022 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.

Arbeiten mit einem gespiegelten Mediensatz

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 physischen 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 AdventureWorks2022
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

Wichtig

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. Wenn beispielsweise in den TO-Klauseln drei Medien aufgelistet werden, 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:

Spiegel	Medienfamilie 1	Medienfamilie 2	Medienfamilie 3
0	`Z:\AdventureWorks1a.bak`	`Z:\AdventureWorks2a.bak`	`Z:\AdventureWorks3a.bak`
1	`Z:\AdventureWorks1b.bak`	`Z:\AdventureWorks2b.bak`	`Z:\AdventureWorks3b.bak`

Eine Medienfamilie muss immer auf dem gleichen Gerät 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 Gespiegelte Sicherungsmediensätze. Weitere Informationen zu Mediensätzen und Medienfamilien im Allgemeinen finden Sie unter "Mediensätze", "Medienfamilien" und "Sicherungssätze".

Wiederherstellen von SQL Server-Sicherungen

Sie können die RESTORE-Anweisung von Transact-SQL oder die Restore-Tasks von SQL Server Management Studio verwenden, um eine Datenbank wiederherzustellen und optional wieder online zu schalten, oder um eine Datei oder Dateigruppe wiederherzustellen. Weitere Informationen finden Sie unter Übersicht über Wiederherstellungsvorgänge.

Weitere Überlegungen zu BACKUP-Optionen

Interaktion von SKIP, NOSKIP, INIT und NOINIT

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

Hinweis

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.

Skip-Option	NOINIT	INIT
NOSKIP	Überprüft, wenn das Volume einen gültigen Medienheader enthält, 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 das Volume keinen gültigen Medienheader, tritt ein Fehler auf.	Wenn das Volume einen gültigen Medienheader enthält, werden die folgenden Überprüfungen durchgeführt: 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 das Volume keinen gültigen Medienheader enthält, wird dieser mithilfe der angegebenen Optionen `MEDIANAME` und `MEDIADESCRIPTION` (sofern vorhanden) generiert.
SKIP	Wenn das Volume einen gültigen Medienheader enthält, wird der Sicherungssatz angefügt. Alle vorhandenen Sicherungssätze werden beibehalten.	Wenn das Volume einen gültigen² Medienheader enthält, werden alle Sicherungssätze auf dem Medium überschrieben. Nur der Medienheader wird beibehalten. Wenn das Medium leer ist, wird ein Medienheader mithilfe der Optionen `MEDIANAME` und `MEDIADESCRIPTION` (sofern vorhanden) generiert.

¹ Damit der Benutzer einen Sicherungsvorgang ausführen kann, muss er den entsprechenden festen Datenbank- oder Serverrollen angehören.

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

Kompatibilität

Achtung

Sicherungen, die mit aktuelleren Versionen von SQL Server erstellt werden, können in früheren Versionen von SQL Servernicht wiederhergestellt werden.

BACKUP unterstützt die RESTART Option zur Abwärtskompatibilität mit früheren Versionen von SQL Server. RESTART hat jedoch keine Auswirkungen.

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 physischen Speicherort unterzubringen.

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

Sie können eine Datenbank nicht in den folgenden Zuständen sichern:

Wiederherstellen
Standby
Schreibgeschützt

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

Ab SQL Server 2016 (13.x) ermöglicht die Einstellung MAXTRANSFERSIZE größer als 65.536 (64 KB) einen optimierten Komprimierungsalgorithmus für mittels Transparent Data Encryption TDE) verschlüsselte Datenbanken, der eine Seite entschlüsselt, komprimiert und dann wieder verschlüsselt. Wenn MAXTRANSFERSIZE nicht angegeben ist, oder wenn MAXTRANSFERSIZE = 65536 (64 KB) verwendet wird, komprimiert die Sicherungskomprimierung mit TDE-verschlüsselten Datenbanken die verschlüsselten Seiten direkt und gibt möglicherweise keine guten Komprimierungsraten aus. Weitere Informationen finden Sie unter Backup Compression for TDE-enabled Databases (Sicherungskomprimierung für TDE-fähige Datenbanken).

Ab SQL Server 2019 (15.x) CU5 muss MAXTRANSFERSIZE nicht mehr festgelegt werden, um diesen optimierten Komprimierungsalgorithmus mit TDE zu aktivieren. Wenn der Sicherungsbefehl WITH COMPRESSION angegeben wurde oder die Serverkonfigurationseinstellung backup compression default auf 1 festgelegt ist, wird MAXTRANSFERSIZE automatisch auf 128.000 erhöht, um den optimierten Algorithmus zu aktivieren. Wenn MAXTRANSFERSIZE für den Sicherungsbefehl mit dem Wert > 64 K angegeben wird, wird der angegebene Wert berücksichtigt. Mit anderen Worten, SQL Server nimmt den Wert nie automatisch ab, erhöht ihn nur. Wenn Sie eine TDE-verschlüsselte Datenbank mit MAXTRANSFERSIZE = 65536 sichern müssen, müssen Sie WITH NO_COMPRESSION angeben oder sicherstellen, dass die Serverkonfiguration backup compression default auf 0 festgelegt ist.

Hinweis

In einigen Fällen ist die Standardeinstellung von MAXTRANSFERSIZE größer als 64 KB:

Wenn die Datenbank mehrere Datendateien erstellt hat, wird MAXTRANSFERSIZE> 64.000 verwendet.
Wenn die Sicherung über eine URL in Azure Blob Storage erfolgt, lautet die Standardeinstellung MAXTRANSFERSIZE = 1048576 (1 MB).
Beim Ausführen der Sicherung zu EINER URL zum S3-kompatiblen Objektspeicher wird der Standardwert (10 MB) verwendet MAXTRANSFERSIZE = 10485760 .

Selbst wenn eine der folgenden Bedingungen gilt, müssen Sie explizit festlegen, dass MAXTRANSFERSIZE im Sicherungsbefehl größer als 64 KB ist, damit der optimierte Algorithmus für die Sicherungskomprimierung zurückgegeben wird, wenn Sie nicht SQL Server 2019 (15.x) CU5 oder höher verwenden.

Standardmäßig wird bei jedem erfolgreichen Sicherungsvorgang dem SQL Server -Fehlerprotokoll und dem Systemereignisprotokoll ein Eintrag hinzugefügt. Wenn Sie das Protokoll regelmäßig sichern, kann die Anzahl dieser Erfolgsmeldungen schnell ansteigen, sodass sehr große Fehlerprotokolle entstehen, die das Suchen nach anderen Meldungen erschweren können. In solchen Fällen können Sie diese Protokolleinträge mit dem Ablaufverfolgungsflag 3226 unterdrücken, wenn keine Ihrer Automatisierungen oder Überwachungen von diesen Einträgen abhängen. Weitere Informationen finden Sie unter Ablaufverfolgungsflags.

Interoperabilitä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 werden:

Dateiverwaltungsvorgänge, 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 einer Dateiverwaltung oder DBCC SHRINK einem Vorgang überlappt, 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.

Metadaten

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, werden möglicherweise die Tabellen mit Sicherungsverläufen verändert.

Sicherheit

Ab SQL Server 2012 (11.x) werden die Optionen PASSWORD und MEDIAPASSWORD nicht mehr für die Erstellung von Sicherungen verwendet. Es ist weiterhin möglich, mit Kennwörtern erstellte Sicherungen wiederherzustellen.

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.

Besitz- und Berechtigungsprobleme im Zusammenhang mit der physischen Datei des Sicherungsmediums können den Sicherungsvorgang beeinträchtigen. Stellen Sie sicher, dass das SQL Server-Startkonto über Lese- und Schreibberechtigungen für das Sicherungsmedium und den Ordner verfügt, in den die Sicherungsdateien geschrieben werden. Allerdings prüft die gespeicherte Prozedur sp_addumpdevice, die den Systemtabellen einen Eintrag für ein Sicherungsmedium hinzufügt, nicht die Dateizugriffsberechtigungen. Solche Probleme mit der physischen Datei des Sicherungsmediums treten möglicherweise erst auf, wenn auf die physische Ressource zugegriffen wird, um einen Sicherungs- oder Wiederherstellungsvorgang auszuführen.

Beispiele

Dieser Abschnitt enthält folgende Beispiele:

A. Sichern einer vollständigen Datenbank
B. Sichern der Datenbank und des Protokolls
C. Erstellen einer vollständigen Dateisicherung der sekundären Dateigruppen
D: Erstellen einer differenziellen Dateisicherung der sekundären Dateigruppen
E. Erstellen und Sichern eines gespiegelten Mediensatzes mit einer Familie
F. Erstellen und Sichern einer multiamily gespiegelten Mediengruppe
G. Sichern eines vorhandenen gespiegelten Mediensatzes
H. Erstellen einer komprimierten Sicherung in einem neuen Mediensatz
I. Sichern von Azure Blob Storage
J. [Sichern bis zum S3-kompatiblen Objektspeicher] ((#j-backing-up-to-s3-compatible-object-storage)
K. Überwachen des Fortschritts einer BACKUP-Anweisung

Hinweis

In den Themen über die Vorgehensweisen bei der Sicherung sind weitere Beispiele aufgeführt. Weitere Informationen finden Sie unter Übersicht über Sicherungen.

A. Sichern einer vollständigen Datenbank

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

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

B. Sichern der Datenbank und des Protokolls

Im folgenden Beispiel wird die AdventureWorks2022-Beispieldatenbank gesichert, in der standardmäßig das einfache Wiederherstellungsmodell verwendet wird. Zum Unterstützen der Protokollsicherungen wird die AdventureWorks2022-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 Updateaktivitä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 AdventureWorks2022
    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',
'X:\SQLServerBackups\AdvWorksLog.bak';
GO

-- Back up the full AdventureWorks2022 database.
BACKUP DATABASE AdventureWorks2022 TO AdvWorksData;
GO
-- Back up the AdventureWorks2022 log.
BACKUP LOG AdventureWorks2022
    TO AdvWorksLog;
GO

Hinweis

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

D: 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 und Sichern eines gespiegelten Mediensatzes mit einer Familie

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

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

F. Erstellen und Sichern einer multiamily gespiegelten Mediengruppe

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

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

G. Sichern eines vorhandenen gespiegelten Mediensatzes

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

BACKUP LOG AdventureWorks2022
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
    NOINIT,
    MEDIANAME = 'AdventureWorksSet1';

Hinweis

Die Standardeinstellung NOINIT wird hier zur Verdeutlichung gezeigt.

H. Erstellen einer komprimierten Sicherung in einem neuen Mediensatz

Im folgenden Beispiel wird das Medium formatiert, wobei ein neuer Mediensatz angelegt wird, und eine vollständige, komprimierte Sicherung der AdventureWorks2022-Datenbank wird erstellt.

BACKUP DATABASE AdventureWorks2022 TO DISK='Z:\SQLServerBackups\AdvWorksData.bak'
WITH
    FORMAT,
    COMPRESSION;

I. Sichern von Microsoft Azure Blob Storage

In diesem Beispiel wird eine vollständige Datenbanksicherung von Sales Azure Blob Storage ausgeführt. Der Speicherkontoname lautet mystorageaccount. Der Container heißt myfirstcontainer. Eine gespeicherte Zugriffsrichtlinie wurde bereits mit Lese-, Schreib-, Lösch- und Listenrechten erstellt. Die Anmeldeinformation SQL Serverhttps://mystorageaccount.blob.core.windows.net/myfirstcontainer wurde mit einer Shared Access Signature (SAS) erstellt, die der gespeicherten Zugriffsrichtlinie zugeordnet ist. Informationen zur SQL Server-Sicherung in Azure Blob Storage finden Sie unter SQL Server-Sicherung und -Wiederherstellung mit Azure Blob Storage und SQL Server Backup zu URL.

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales.bak'
WITH STATS = 5;

Sie können Ihre Datenbank auch in mehreren Streifen sichern und wie folgt aussehen:

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-01.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-02.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-03.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-04.bak'
WITH COPY_ONLY;

J. Sichern des S3-kompatiblen Objektspeichers

Gilt für: SQL Server 2022 (16.x)

In diesem Beispiel wird eine vollständige Sicherung der Sales-Datenbank auf einer S3-kompatiblen Objektspeicherplattform durchgeführt. Der Name der Anmeldeinformationen ist in der Anweisung nicht erforderlich und muss auch nicht mit dem exakten URL-Pfad übereinstimmen. Es wird jedoch eine Suche nach den richtigen Anmeldeinformationen unter der angegebenen URL durchgeführt. Weitere Informationen finden Sie unter SQL Server-Sicherungs- und -Wiederherstellungsvorgänge für S3-kompatiblen Objektspeicher.

BACKUP DATABASE Sales
TO      URL = 's3://10.10.10.10:8787/sqls3backups/sales_01.bak'
,       URL = 's3://10.10.10.10:8787/sqls3backups/sales_02.bak'
,       URL = 's3://10.10.10.10:8787/sqls3backups/sales_03.bak'
WITH    FORMAT
,       STATS               = 10
,       COMPRESSION;

K. Überwachen des Fortschritts von BACKUP-Anweisungen

Die folgende Abfrage gibt Informationen zu den aktuell ausgeführten BACKUP-Anweisungen zurück:

SELECT query = a.text, start_time, percent_complete,
    eta = dateadd(second,estimated_completion_time/1000, getdate())
FROM sys.dm_exec_requests r
    CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command LIKE 'BACKUP%';

SQL Server

* SQL Managed Instance *

Analytics Platform
System (PDW)

Verwaltete Azure SQL-Instanz

Diese sichert eine SQL-Datenbank-Instanz in Azure SQL Managed Instance. Azure SQL Managed Instance umfasst automatische Sicherungen. Sie können vollständige COPY_ONLY-Datenbanksicherungen erstellen. Differenzielle Sicherungen, Protokollsicherungen und Dateimomentaufnahmesicherungen werden nicht unterstützt.

Gilt auch für SQL-verwaltete Instanz, die von Azure Arc aktiviert sind.

Syntax

BACKUP DATABASE { database_name | @database_name_var }
  TO URL = { 'physical_device_name' | @physical_device_name_var }[ ,...n ]
  WITH COPY_ONLY [, { <general_WITH_options> } ]
[;]

<general_WITH_options> [ ,...n ]::=

--Media Set Options
   MEDIADESCRIPTION = { 'text' | @text_variable }
 | MEDIANAME = { media_name | @media_name_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 ]

--Encryption Options
 ENCRYPTION (ALGORITHM = { AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY } , encryptor_options ) <encryptor_options> ::=
   SERVER CERTIFICATE = Encryptor_Name | SERVER ASYMMETRIC KEY = Encryptor_Name

Argumente

DATABASE

Gibt eine vollständige Datenbanksicherung an. Während einer Datenbanksicherung sichert Azure SQL Managed Instance einen ausreichenden Anteil des Transaktionsprotokolls, um eine konsistente Datenbank zu erstellen, wenn die Sicherung wiederhergestellt wird.

Wichtig

Eine Datenbanksicherung, die auf einer verwalteten Instanz erstellt wurde, kann nur auf einer anderen Instanz von Azure SQL Managed Instance oder auf einer SQL Server 2022-Instanz wiederhergestellt werden. Dies liegt daran, dass SQL Managed Instance im Vergleich zu anderen SQL Server-Versionen eine höhere interne Datenbankversion verwendet. Weitere Informationen finden Sie unter Wiederherstellen einer SQL Managed Instance-Datenbanksicherung auf SQL Server 2022.

Wenn Sie eine von BACKUP DATABASE (eine Datensicherung) erstellte Sicherung wiederherstellen, wird die komplette Sicherung wiederhergestellt. Informationen zur Wiederherstellung aus automatischen Sicherungen von SQL Managed Instance finden Sie unter Wiederherstellen einer Datenbank in Azure SQL Managed Instance.

{ database_name | @database_name_var }

Dies ist die Datenbank, aus der die vollständige Datenbank gesichert wird. Wird der Name in Form einer Variablen angegeben (@database_name_var), kann er entweder als Zeichenfolgenkonstante (@database_name_var=database name) oder als Variable eines Zeichenfolgen-Datentyps (mit Ausnahme des Datentyps ntext oder text) angegeben werden.

Weitere Informationen finden Sie unter Vollständige Dateisicherungen und Sichern von Dateien und Dateigruppen.

TO URL

Gibt die URL an, die für den Sicherungsvorgang verwendet werden soll. Das URL-Format wird zum Erstellen von Sicherungen in Microsoft Azure Storage verwendet.

Wichtig

Um auf mehreren Geräten eine Sicherung durchzuführen, wenn Sie über die URL sichern, müssen Sie Shared Access Signature-Token (SAS) verwenden. Beispiele für die Erstellung einer Shared Access Signature finden Sie unter SQL Server-Sicherung über URLs und Simplifying creation of SQL Credentials with Shared Access Signature (SAS) tokens on Azure Storage with Powershell (Vereinfachen der Erstellung von SQL-Anmeldeinformationen mit Shared Access Signature-Token in Azure Storage mit PowerShell).

n
Ist ein Platzhalter, der angibt, dass bis zu 64 Sicherungsgeräte in einer durch Trennzeichen getrennten Liste angegeben werden können.

WITH-Optionen

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

ENCRYPTION

AES_128
AES_192
AES_256
TRIPLE_DES_3KEY
NO_ENCRYPTION

Wenn Sie sich für die Verschlüsselung entscheiden, müssen Sie auch die Verschlüsselung mithilfe der Verschlüsselungsoptionen angeben:

SERVER CERTIFICATE = <Encryptor_Name>
SERVER ASYMMETRIC KEY = <Encryptor_Name>

Sicherungssatzoptionen

COPY_ONLY

Gibt an, dass die Sicherung eine Kopiesicherung ist, die keine Auswirkungen auf die normale Sicherungssequenz hat. Eine Kopiesicherung wird unabhängig von automatischen Azure SQL-Datenbank-Sicherungen erstellt. Weitere Informationen finden Sie unter Kopiesicherungen.

{ KOMPRIMIERUNG | NO_COMPRESSION }

Gibt an, ob für diese Sicherung eine Sicherungskomprimierung verwendet wird, wodurch die Standardeinstellung auf Serverebene überschrieben wird.

Die Sicherungskomprimierung wird standardmäßig deaktiviert. Diese Standardeinstellung kann jedoch durch Festlegen der Serverkonfigurationsoption backup compression default geändert werden. Informationen zum Anzeigen des aktuellen Werts dieser Option finden Sie unter Anzeigen oder Ändern von Servereigenschaften.

COMPRESSION
Aktiviert die Sicherungskomprimierung explizit.

NO_COMPRESSION
Deaktiviert die Sicherungskomprimierung explizit.

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.

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 Sicherungsvolumes entsprechen. Wird er nicht angegeben, oder ist die Option SKIP festgelegt, findet keine Prüfung des Mediennamens statt.

BLOCKSIZE = { blocksize | @blocksize_variable }

Datenübertragungsoptionen

BUFFERCOUNT = { buffercount | @buffercount_variable }

Der gesamte von den Puffern belegte Speicherplatz wird durch BUFFERCOUNT * MAXTRANSFERSIZE bestimmt.

Hinweis

Wichtige Informationen zur Verwendung der BUFFERCOUNT Option finden Sie im Blogbeitrag Falsche BufferCount-Datenübertragungsoption, die zu einer OOM-Bedingung führen kann.

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

Für Transparente Datenverschlüsselung (TDE)-fähige Datenbanken mit einer einzelnen Datendatei ist der standardmäßige MAXTRANSFERSIZE-Wert 65536 (64 KB). Für nicht mit TDE verschlüsselte Datenbanken ist der MAXTRANSFERSIZE-Standardwert 1048576 (1 MB) bei Verwendung der Sicherung auf DISK und 65536 (64 KB) bei Verwendung von VDI oder TAPE.

Hinweis

MAXTRANSFERSIZE gibt die größte Übertragungseinheit an, garantiert jedoch nicht, dass die angegebene maximale Größe von jedem Schreibvorgang übertragen wird. Die MAXTRANSFERSIZE ist für Schreibvorgänge von Stripeset-Transaktionsprotokollsicherungen auf 64 KB festgelegt.

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
Gibt an, dass der Sicherungsvorgang jede Seite auf Prüfsumme und zerrissene Seiten überprüft (wenn aktiviert und verfügbar) und eine Prüfsumme für die gesamte Sicherung generiert.

Die Verwendung von Sicherungsprüfsummen wirkt sich möglicherweise auf Workload und Sicherungsdurchsatz aus.

Weitere Informationen finden Sie unter Mögliche Medienfehler während der Sicherung und Wiederherstellung.

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

Weitere Informationen finden Sie unter Mögliche Medienfehler während der Sicherung und Wiederherstellung.

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 [ = Prozentsatz ]

Einschränkungen von SQL Managed Instance

Die max. Streifengröße bei der Speicherung beträgt 195 GB (maximale Blob-Größe). Erhöhen Sie die Streifenanzahl im Backup-Befehl, um die einzelne Streifengröße zu reduzieren und innerhalb dieser Einschränkungen zu bleiben.

Sicherheit

Berechtigungen

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

Besitz- und Berechtigungsprobleme im Zusammenhang mit der URL können den Sicherungsvorgang beeinträchtigen. SQL Server muss über Lese- und Schreibberechtigungen für das Medium verfügen. Das Konto, unter dem der SQL Server -Dienst ausgeführt wird, muss Schreibberechtigungen haben.

Beispiele

Im Beispiel wird eine COPY_ONLY Sicherung von Sales Microsoft Azure Blob Storage ausgeführt. Der Speicherkontoname lautet mystorageaccount. Der Container heißt myfirstcontainer. Eine gespeicherte Zugriffsrichtlinie wurde mit Lese-, Schreib-, Lösch- und Auflistungsrechten erstellt. Die Anmeldeinformation SQL Serverhttps://mystorageaccount.blob.core.windows.net/myfirstcontainer wurde mit einer Shared Access Signature (SAS) erstellt, die der gespeicherten Zugriffsrichtlinie zugeordnet ist. Informationen zur SQL Server-Sicherung in Azure Blob Storage finden Sie unter SQL Server Backup and Restore with Microsoft Azure Blob Storage und SQL Server Backup to URL.

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_20160726.bak'
WITH STATS = 5, COPY_ONLY;

Sie können Ihre Datenbank auch in mehreren Streifen sichern und wie folgt aussehen:

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-01.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-02.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-03.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-04.bak'
WITH COPY_ONLY;

Datenbank wiederherstellen

SQL Server

SQL Managed Instance

* Analytics
Platform System (PDW) *

Analyseplattformsystem

Erstellt eine Sicherungskopie einer Analytics-Plattformsystem (PDW)-Datenbank und speichert die Sicherung nicht auf der Appliance, sondern in einem benutzerdefinierten Netzwerkpfad. Verwenden Sie diese Anweisung mit RESTORE DATABASE - Analytics Platform System zur Notfallwiederherstellung oder zum Kopieren einer Datenbank von einer Appliance auf eine andere.

Lesen Sie als Vorbereitung den Artikel „Erwerben und Konfigurieren eines Sicherungsservers“ in der Produktdokumentation zu Analytics Platform System (PDW).

Es gibt zwei Arten von Sicherungen in Analytics-Plattformsystem (PDW). Eine vollständige Datenbanksicherung ist eine Sicherung einer kompletten Analytics-Plattformsystem (PDW)-Datenbank. Bei einer differenziellen Datenbanksicherung werden nur die Änderungen seit der letzten vollständigen Datenbanksicherung erfasst. Die Sicherung einer Benutzerdatenbank schließt Datenbankbenutzer und Datenbankrollen ein. Eine Sicherung der master-Datenbank schließt Anmeldungen ein.

Weitere Informationen zu Analytics Platform System-Datenbanksicherungen (PDW) finden Sie unter „Sichern und Wiederherstellen“ in der Produktinformation zu Analytics Platform System (PDW).

Syntax

--Create a full backup of a user database or the master database.
BACKUP DATABASE database_name
    TO DISK = '\\UNC_path\backup_directory'
    [ WITH [ ( ]<with_options> [ ,...n ][ ) ] ]
[;]

--Create a differential backup of a user database.
BACKUP DATABASE database_name
    TO DISK = '\\UNC_path\backup_directory'
    WITH [ ( ] DIFFERENTIAL
    [ , <with_options> [ ,...n ] [ ) ]
[;]

<with_options> ::=
    DESCRIPTION = 'text'
    | NAME = 'backup_name'

Argumente

database_name

Der Name der Datenbank, auf der eine Sicherung erstellt werden soll. Bei der Datenbank kann es sich um die master-Datenbank oder eine Benutzerdatenbank handeln.

TO DISK = '\\UNC_path\backup_directory'

Netzwerkpfad und Verzeichnis, in die Analytics-Plattformsystem (PDW) die Sicherungsdateien schreibt. Beispiel: \\\xxx.xxx.xxx.xxx\backups\2012\Monthly\08.2012.Mybackup.

Der Pfad zum Sicherungsverzeichnisnamen muss bereits vorhanden sein und als vollqualifizierter UNC-Pfad (Universal Naming Convention) angegeben werden.
Das Sicherungsverzeichnis backup_directory darf nicht vor dem Ausführen des Sicherungsbefehls vorhanden sein. Analytics-Plattformsystem (PDW) erstellt das Sicherungsverzeichnis.
Beim Pfad zum Sicherungsverzeichnis darf es sich nicht um einen lokalen Pfad handeln, und der Speicherort darf sich nicht auf einem Analytics-Plattformsystem (PDW)-Applianceknoten befinden.
Die maximale Länge des UNC-Pfads und des Sicherungsverzeichnisnamens beträgt 200 Zeichen.
Der Server oder Host muss als IP-Adresse angegeben werden. Sie können ihn nicht als Host- oder Servernamen angeben.

DESCRIPTION = 'text'

Gibt eine Textbeschreibung der Datensicherung an. Die maximale Länge des Texts beträgt 255 Zeichen.

Die Beschreibung wird in den Metadaten gespeichert und angezeigt, wenn der Sicherungsheader mit RESTORE HEADERONLY wiederhergestellt wird.

NAME = 'Backup _name'

Gibt den Namen der Sicherung an. Der Sicherungsname kann vom Datenbanknamen abweichen.

Namen können maximal 128 Zeichen haben.
Sie können keinen Pfad einschließen.
An der ersten Stelle muss ein Buchstabe, eine Ziffer oder ein Unterstrich (_) stehen. Zulässige Sonderzeichen sind Unterstrich (_), Bindestrich (-) oder Leerzeichen ( ). Sicherungsnamen dürfen nicht mit einem Leerzeichen enden.
Die Anweisung schlägt fehl, wenn backup_name am angegebenen Speicherort bereits vorhanden ist.

Der Name wird in den Metadaten gespeichert und angezeigt, wenn der Sicherungsheader mit RESTORE HEADERONLY wiederhergestellt wird.

DIFFERENTIAL

Gibt an, dass eine differenzielle Sicherung einer Benutzerdatenbank durchgeführt werden soll. Wenn nicht angegeben, ist die Standardeinstellung eine vollständige Sicherung. Der Name der differenziellen Sicherung muss nicht mit dem Namen der vollständigen Sicherung übereinstimmen. Zum Nachverfolgen der differenziellen Sicherung und der zugehörigen vollständigen Sicherung sollten Sie den gleichen Namen verwenden und "full" oder "diff" anfügen.

Beispiel:

BACKUP DATABASE Customer TO DISK = '\\xxx.xxx.xxx.xxx\backups\CustomerFull';

BACKUP DATABASE Customer TO DISK = '\\xxx.xxx.xxx.xxx\backups\CustomerDiff' WITH DIFFERENTIAL;

Berechtigungen

Erfordert die BACKUP DATABASE-Berechtigung oder die Mitgliedschaft in der festen Datenbankrolle db_backupoperator. Die master-Datenbank kann nur von einem normalen Benutzer gesichert werden, der der festen Datenbankrolle Db_backupoperator hinzugefügt wurde. Die master-Datenbank kann nur von sa, dem Fabricadministrator, oder Mitgliedern der festen Serverrolle Sysadmin gesichert werden.

Erfordert ein Windows-Konto mit der Berechtigung, auf das Sicherungsverzeichnis zuzugreifen, es zu erstellen und auf es zu schreiben. Sie müssen außerdem den Windows-Kontonamen und das Kennwort in Analytics-Plattformsystem (PDW) speichern. Verwenden Sie die gespeicherte Prozedur sp_pdw_add_network_credentials – Azure Synapse Analytics, um diese Netzwerkanmeldeinformationen zu Analytics-Plattformsystem (PDW) hinzuzufügen.

Weitere Informationen zum Verwalten von Anmeldeinformationen in Analytics-Plattformsystem (PDW) finden Sie im Abschnitt Sicherheit.

Fehlerbehandlung

BACKUP DATABASE-Fehler unter den folgenden Bedingungen:

Benutzerberechtigungen sind nicht ausreichend, um eine Sicherung auszuführen.
Analytics-Plattformsystem (PDW) verfügt nicht über die erforderlichen Berechtigungen für den Netzwerkspeicherort, an dem die Sicherungsdateien gespeichert werden.
Die Datenbank ist nicht vorhanden.
Das Zielverzeichnis ist bereits auf der Netzwerkfreigabe vorhanden.
Die Zielnetzwerkfreigabe ist nicht verfügbar.
Der Speicherplatz auf der Ziel-Netzwerkfreigabe ist nicht ausreichend für die Sicherung. Der BACKUP DATABASE-Befehl bestätigt nicht, dass genügend freier Speicherplatz vorhanden ist, bevor die Sicherung initiiert wird, wodurch bei Ausführen von BACKUP DATABASE ein Fehler wegen unzureichendem Speicherplatz generiert werden kann. Wenn nicht genügend Speicherplatz vorhanden ist, führt Analytics-Plattformsystem (PDW) ein Rollback für den Befehl BACKUP DATABASE aus. Um die Größe Ihrer Datenbank zu verringern, führen Sie DBCC SHRINKLOG (Analytics Platform System (PDW)) aus.
Versuchen Sie, eine Sicherung innerhalb einer Transaktion zu starten.

Hinweise

Bevor Sie eine Datenbanksicherung durchführen, verwenden Sie DBCC SHRINKLOG (Analytics Platform System (PDW)), um die Größe Ihrer Datenbank zu verringern.

Eine Analytics-Plattformsystem (PDW)-Sicherung wird als Satz von mehreren Dateien im gleichen Verzeichnis gespeichert.

Eine differenzielle Sicherung nimmt normalerweise weniger Zeit in Anspruch als eine vollständige Sicherung und kann häufiger ausgeführt werden. Wenn mehrere differenzielle Sicherungen auf der gleichen vollständigen Sicherung basieren, enthält jede differenzielle Sicherung alle Änderungen aus der vorherigen differenziellen Sicherung.

Wenn Sie einen BACKUP-Befehl abbrechen, entfernt Analytics-Plattformsystem (PDW) das Zielverzeichnis und alle Dateien, die für die Sicherung erstellt wurden. Wenn Analytics-Plattformsystem (PDW) die Netzwerkkonnektivität mit der Freigabe verliert, kann das Rollback nicht abgeschlossen werden.

Vollständige und differenzielle Sicherungen werden in separaten Verzeichnissen gespeichert. Benennungskonventionen werden nicht erzwungen, um anzugeben, dass eine vollständige Sicherung und eine differenzielle Sicherung zusammengehören. Sie können dies über Ihre eigenen Benennungskonventionen nachverfolgen. Alternativ können Sie dies nachverfolgen, indem Sie mithilfe der WITH DESCRIPTION-Option eine Beschreibung hinzufügen und diese dann mithilfe der RESTORE HEADERONLY-Anweisung abrufen.

Begrenzungen

Sie können keine differenzielle Sicherung der master-Datenbank erstellen. Nur vollständige Sicherungen der master-Datenbank werden unterstützt.

Transaktionsprotokollsicherungen der master-Systemdatenbank werden nicht unterstützt.

Die Sicherungsdateien werden in einem Format gespeichert, das nur geeignet ist, um die Sicherung auf einer Analytics-Plattformsystem (PDW)-Appliance unter Verwendung der RESTORE DATABASE - Analytics Platform System-Anweisung wiederherzustellen.

Die Sicherung mit der BACKUP DATABASE-Anweisung kann nicht verwendet werden, um Daten oder Benutzerinformationen an SMP-SQL Server-Datenbanken zu übertragen. Hierfür können Sie die Remotetabellenkopie-Features verwenden. Weitere Informationen finden Sie unter „Remotetabellenkopie“ in der Produktdokumentation zu Analytics Platform System (PDW).

Analytics Platform System (PDW) verwendet SQL Server-Sicherungstechnologie zum Sichern und Wiederherstellen von Datenbanken. SQL Server-Sicherungsoptionen sind vorkonfiguriert, um die Komprimierung von Sicherungen zu verwenden. Sie können keine Sicherungsoptionen wie Komprimierung, Prüfsumme, Blockgröße und Pufferanzahl festlegen.

Nur eine Datenbanksicherung oder -wiederherstellung kann zu einem beliebigen Zeitpunkt auf der Appliance ausgeführt werden. Analytics-Plattformsystem (PDW) stellt Sicherungs- oder Wiederherstellungsbefehle in die Warteschlange, bis der aktuelle Sicherungs-oder Wiederherstellungsbefehl abgeschlossen ist.

Die Zielappliance für die Wiederherstellung der Sicherung muss mindestens so viele Computeknoten besitzen wie die Quellappliance. Die Zielappliance kann über mehr Computeknoten verfügen als die Quellappliance, darf aber nicht weniger Computeknoten besitzen.

Analytics-Plattformsystem (PDW) verfolgt Speicherort und Namen von Sicherungen nicht, da die Sicherungen nicht auf der Appliance gespeichert werden.

Analytics-Plattformsystem (PDW) verfolgt den Erfolg oder Misserfolg von Datenbanksicherungen nicht.

Eine differenzielle Sicherung ist nur zulässig, wenn die letzte vollständige Sicherung erfolgreich abgeschlossen wurde. Angenommen, Sie erstellen am Montag eine vollständige Sicherung der Sales Datenbank und die Sicherung wurde erfolgreich abgeschlossen. Anschließend erstellen Sie am Dienstag eine vollständige Sicherung der Sales Datenbank und schlägt fehl. Nach diesem Fehler können Sie dann keine auf der vollständigen Sicherung vom Montag basierende differenzielle Sicherung erstellen. Sie müssen eine vollständige Sicherung erstellen, bevor Sie eine differenzielle Sicherung erstellen.

Metadaten

Diese dynamischen Verwaltungssichten enthalten Informationen über alle Sicherungs-, Wiederherstellungs- und Ladevorgänge. Die Informationen persistieren über Systemneustarts.

Leistung

Analytics-Plattformsystem (PDW) führt eine Sicherung aus, indem zuerst die Metadaten gesichert werden und dann eine parallele Sicherung der auf den Computeknoten gespeicherten Datenbankdaten ausgeführt wird. Daten werden direkt aus jedem Computeknoten in das Sicherungsverzeichnis kopiert. Um die bestmögliche Leistung für das Verschieben von Daten von den Computeknoten in das Sicherungsverzeichnis zu erzielen, steuert Analytics-Plattformsystem (PDW) die Anzahl von Computeknoten, die gleichzeitig Daten kopieren.

Sperren

Das DATABASE-Objekt wird mit einer ExclusiveUpdate-Sperre gesperrt.

Sicherheit

Analytics-Plattformsystem (PDW)-Sicherungen werden nicht auf dem Gerät gespeichert. Daher ist Ihr IT-Team zuständig für das Verwalten aller Aspekte der Sicherheit von Sicherungen. Dazu gehört beispielsweise die Verwaltung der Sicherheit der Sicherungsdaten, der Sicherheit der Server, auf denen Sicherungen gespeichert werden, und der Sicherheit der Netzwerkinfrastruktur, die die Sicherungsserver mit der Analytics-Plattformsystem (PDW)-Appliance verbinden.

Verwalten von Anmeldeinformationen für das Netzwerk

Der Netzwerkzugriff auf das Sicherungsverzeichnis basiert auf der Datei für die Standardfreigabesicherheit des Betriebssystems. Vor dem Ausführen einer Sicherung müssen Sie ein Windows-Konto erstellen oder reservieren, das für die Authentifizierung von Analytics-Plattformsystem (PDW) beim Sicherungsverzeichnis verwendet wird. Dieses Windows-Konto benötigt die Berechtigung, auf das Sicherungsverzeichnis zuzugreifen, es zu erstellen und darin zu schreiben.

Wichtig

Um Sicherheitsrisiken in Verbindung mit Ihren Daten zu reduzieren, empfehlen wir, dass Sie ein Windows-Konto ausschließlich zum Ausführen der Sicherungs- und Wiederherstellungsvorgänge festlegen. Definieren Sie das Konto so, dass es nur Berechtigungen für den Sicherungsspeicherort besitzt.

Sie müssen den Benutzernamen und das Kennwort in Analytics-Plattformsystem (PDW) speichern, indem Sie die gespeicherte Prozedur sp_pdw_add_network_credentials – Azure Synapse Analytics ausführen. Analytics-Plattformsystem (PDW) verwendet die Windows-Anmeldeinformationsverwaltung zum Speichern und Verschlüsseln von Benutzernamen und Kennwörtern auf dem Steuerknoten und den Computeknoten. Die Anmeldeinformationen werden nicht mit dem Befehl BACKUP DATABASE gesichert.

Mit sp_pdw_remove_network_credentials – Azure Synapse Analytics können Sie Netzwerkanmeldeinformationen aus Analytics-Plattformsystem (PDW) entfernen.

Um alle in Analytics-Plattformsystem (PDW) gespeicherten Netzwerkanmeldeinformationen aufzulisten, verwenden Sie die dynamische Verwaltungssicht sys.dm_pdw_network_credentials.

Beispiele

A. Fügen Sie der Netzwerkanmeldeinformationen für den Sicherungsspeicherort hinzu

Zum Erstellen einer Sicherung Analytics-Plattformsystem (PDW) benötigen Sie die Lese-/Schreibberechtigung für das Sicherungsverzeichnis. Im folgenden Beispiel wird gezeigt, wie die Anmeldeinformationen für einen Benutzer hinzugefügt werden. Analytics-Plattformsystem (PDW) speichert die Anmeldeinformationen und verwendet sie für Sicherungs- und Wiederherstellungsvorgänge.

Wichtig

Aus Sicherheitsgründen wird empfohlen, mindestens ein Domänenkonto ausschließlich zum Zweck der Durchführung von Sicherungen zu erstellen.

EXEC sp_pdw_add_network_credentials 'xxx.xxx.xxx.xxx', 'domain1\backupuser', '*****';

B. Entfernen Sie Netzwerkanmeldeinformationen für den Sicherungsspeicherort

Im folgenden Beispiel wird gezeigt, wie die Anmeldeinformationen für ein Domänenbenutzerkonto aus Analytics-Plattformsystem (PDW) entfernt werden.

EXEC sp_pdw_remove_network_credentials 'xxx.xxx.xxx.xxx';

C. Erstellen Sie eine vollständige Sicherung jeder Benutzerdatenbank

Im folgenden Beispiel wird eine vollständige Sicherung der Invoices-Benutzerdatenbank erstellt. Analytics Platform System (PDW) erstellt das Verzeichnis Invoices2013 und speichert die Sicherungsdateien im Verzeichnis \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full.

BACKUP DATABASE Invoices TO DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full';

D: Erstellen Sie eine differenzielle Sicherung einer Benutzerdatenbank

Das folgende Beispiel erstellt eine differenzielle Sicherung, die alle Änderungen seit der letzten vollständigen Sicherung der Invoices-Datenbank enthält. Das Analytics Platform System (PDW) erstellt das \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff Verzeichnis zum Speichern der Dateien. Die Beschreibung "Invoices 2013 differential backup" wird mit den Headerinformationen für die Sicherung gespeichert.

Die differenzielle Sicherung wird nur dann erfolgreich ausgeführt, wenn die letzte vollständige Sicherung von Rechnungen erfolgreich abgeschlossen wurde.

BACKUP DATABASE Invoices TO DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff'
    WITH DIFFERENTIAL,
    DESCRIPTION = 'Invoices 2013 differential backup';

E. Erstellen Sie eine vollständige Sicherung der Masterdatenbank

Im folgenden Beispiel wird eine vollständige Sicherung der master-Datenbank erstellt und im Verzeichnis „\\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master“ gespeichert, wobei IP für eine Netzwerk-IP-Adresse steht.

BACKUP DATABASE master TO DISK = '\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master';

Die master-Datenbank speichert die Anmeldeinformationen für die Appliance. Um die Anmeldeinformationen der Appliance zu sichern, müssen Sie die master Datenbank sichern.

Im folgenden Beispiel wird eine vollständige Sicherung der master-Datenbank erstellt.

BACKUP DATABASE master TO DISK = '\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master'
WITH (
    DESCRIPTION = 'Master Backup 20130722',
    NAME = 'login-backup'
)
;

RESTORE DATABASE (Parallel Data Warehouse)

Freigeben über

BACKUP (Transact-SQL)

Auswählen eines Produkts

SQL Server

Syntax

Argumente

DATABASE

PROTOKOLL

GROUP (<Datenbank>,... n)

SERVER

METADATA_ONLY

{ database_name | @database_name_var }

<> file_or_filegroup [ ,...n ]

FILE = { logical_file_name | @logical_file_name_var }

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } [ ,...n ] ]

READ_WRITE_FILEGROUPS

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

TO <backup_device> [ ,...n ]

{ logical_device_name | @logical_device_name_var }

{ DISK | TAPE | URL} = { 'physical_device_name' | @physical_device_name_var | 'NUL' }

SPIEGELUNG AUF <backup_device> [ ,...n ]

WITH-Optionen

CREDENTIAL

FILE_SNAPSHOT

DIFFERENTIAL

ENCRYPTION

Sicherungssatzoptionen

COPY_ONLY

[ COMPRESSION [ ALGORITHM = ( { MS_XPRESS | accelerator_algorithm } ) ] | NO_COMPRESSION ]

DESCRIPTION = { 'text' | @text_variable }

NAME = { backup_set_name | @backup_set_var }

{ EXPIREDATE ='date' | RETAINDAYS = days }

{ METADATA_ONLY | SNAPSHOT }

Mediensatzoptionen

{ NOINIT | INIT }

{ NOSKIP | SKIP }

{ NOFORMAT | FORMAT }

MEDIADESCRIPTION = { text | @text_variable }

MEDIANAME = { media_name | @media_name_variable }

BLOCKSIZE = { blocksize | @blocksize_variable }

Datenübertragungsoptionen

BUFFERCOUNT = { buffercount | @buffercount_variable }

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

Fehlerverwaltungsoptionen

{ NO_CHECKSUM | CHECKSUM }

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

Kompatibilitätsoptionen

RESTART

Überwachungsoptionen

STATS [ = Prozentsatz ]

Bandoptionen

{ REWIND | NOREWIND }

{ UNLOAD | NOUNLOAD }

Protokollspezifische Optionen

{ NORECOVERY | STANDBY = undo_file_name }

NO_TRUNCATE

Informationen zum Arbeiten mit SQL Server-Sicherungen

Sicherungstypen

Kürzung des Transaktionsprotokolls

Formatieren von Sicherungsmedien

Arbeiten mit Sicherungsgeräten und Mediensätzen

Sicherungsmedien in Stripesetmedien

Arbeiten mit einem gespiegelten Mediensatz

Medienfamilien in gespiegelten Mediensätzen

Wiederherstellen von SQL Server-Sicherungen

Weitere Überlegungen zu BACKUP-Optionen

Interaktion von SKIP, NOSKIP, INIT und NOINIT

Kompatibilität

Hinweise

Interoperabilität

Metadaten

Sicherheit

Berechtigungen

Beispiele

A. Sichern einer vollständigen Datenbank

B. Sichern der Datenbank und des Protokolls

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

D: Erstellen einer differenziellen Dateisicherung der sekundären Dateigruppen

E. Erstellen und Sichern eines gespiegelten Mediensatzes mit einer Familie