Freigeben über

SQL Server-Backup über URL für Azure Blob Storage

Gilt für:SQL ServerAzure SQL Managed Instance

In diesem Artikel werden die Konzepte, Anforderungen und Komponenten vorgestellt, die für die Verwendung von Azure Blob Storage als Sicherungsziel erforderlich sind. Die Sicherungs- und Wiederherstellungsfunktionen sind bei der Verwendung von DISK oder TAPE ähnlich oder identisch, wobei es einige Unterschiede gibt. Diese Unterschiede sowie einige Codebeispiele lernen Sie in diesem Artikel kennen.

Tip

Ab SQL Server 2025 (17.x) können Sie die URL mit verwalteter Identität sichern. Überprüfen Sie „Back up to URL” mit verwalteter Identität (Vorschau) – SQL Server, aktiviert von Azure Arc.

Overview

Mit SQL Server 2012 Service Pack 1 CU2 und SQL Server 2014 wurde die Möglichkeit eingeführt, Sicherungen über eine URL zu erstellen, die auf Azure Blob Storage verweist – und dies mithilfe der vertrauten T-SQL-Syntax für Sicherungen in Azure Storage. SQL Server 2016 (13.x) hat File-Snapshot Sicherungen für Datenbankdateien in Azure und Sicherheit über SAS-Schlüssel (Shared Access Signature) eingeführt, eine sichere und einfache Möglichkeit zum Authentifizieren von Zertifikaten bei der Azure Storage-Sicherheitsrichtlinie.

Es ist wichtig, die Komponenten und die Interaktion zwischen ihnen zu verstehen, um eine Sicherung durchzuführen oder aus Azure Blob Storage wiederherzustellen.

Der erste Schritt in diesem Verfahren besteht im Erstellen eines Azure-Speicherkontos innerhalb Ihres Azure-Abonnements. Dieses Speicherkonto ist ein Administratorkonto, das über vollständige Administratorrechte für alle mit dem Speicherkonto erstellten Container und Objekte verfügt. SQL Server kann entweder den Namen des Azure-Speicherkontos und seinen Zugriffsschlüsselwert verwenden, um Blobs in Azure Blob Storage zu authentifizieren und zu schreiben und zu lesen, oder ein Token für freigegebene Zugriffssignaturen verwenden, das für bestimmte Container generiert wird, die ihm Lese- und Schreibrechte gewähren. Weitere Informationen zu Azure-Speicherkonten finden Sie unter Informationen zu Azure-Speicherkonten , und weitere Informationen zu Shared Access Signatures finden Sie unter Shared Access Signatures, Teil 1: Grundlagen zum SAS-Modell. Diese Authentifizierungsinformationen werden in den SQL Server-Anmeldeinformationen gespeichert und für Sicherungs- oder Wiederherstellungsvorgänge verwendet.

Azure Storage und S3-kompatibler Speicher

Mit SQL Server 2022 (16.x) ist es nun möglich, Sicherungen in S3-kompatiblen Objektspeicher zu schreiben. Dabei ähneln die Sicherungs- und Wiederherstellungsfunktionen grundsätzlich der Verwendung von „Sicherung über URLs“ mit Azure Blob Storage als Sicherungsmedium. SQL Server 2022 (16.x) erweitert die BACKUP/RESTORE TO/FROM URL Syntax, indem Unterstützung für einen neuen S3-Connector mithilfe der REST-API hinzugefügt wird.

Dieser Artikel enthält Informationen zur Verwendung von „Sicherung über URLs“ für Azure Blob Storage. Weitere Informationen zur Verwendung von Backup to URL für S3-kompatiblen Speicher finden Sie unter SQL Server Back up to URL for S3-kompatible Objektspeicher.

Sichern in Azure Storage: Blockblobs im Vergleich zu Seitenblobs

Es gibt zwei Arten von Blobs, die in Azure Blob Storage gespeichert werden können: Blockblobs und Seitenblobs. Bei SQL Server 2016 und höher wird das Blockblob bevorzugt.

Wenn der Speicherschlüssel in den Anmeldeinformationen verwendet wird, wird das Seitenblob verwendet. Wenn die SAS verwendet wird, wird das Blockblob verwendet.

Sicherungen in Blockblobs sind für Azure Blob Storage erst ab SQL Server 2016 verfügbar. Verwenden Sie Blockblobs statt Seitenblocks zum Sichern, wenn Sie SQL Server 2016 oder höher nutzen.

Die wichtigsten Gründe dafür sind:

  • Im Vergleich zum Speicherschlüssel ist SAS ein sicherer Weg, um Blobzugriff zu autorisieren.
  • Sie können Sicherungen in mehreren Blockblobs durchführen, um eine bessere Sicherungs- und Wiederherstellungsleistung zu erzielen und größere Datenbanksicherungen zu unterstützen.
  • Block-BLOB ist günstiger als Seiten-BLOB.
  • Kunden, die Sicherungen in Seitenblobs über einen Proxyserver durchführen, müssen backuptourl.exe verwenden.

Die Sicherung einer großen Datenbank in Azure Blob Storage unterliegt den Einschränkungen, die unter Unterschiede, Einschränkungen und bekannte Probleme bei T-SQL zwischen SQL Server und Azure SQL Managed Instance aufgeführt werden.

Wenn die Datenbank zu groß ist, haben Sie die Möglichkeit:

  • Verwenden von Sicherungskomprimierung oder
  • Sicherungen auf mehreren Blockblobs auszuführen

Unterstützung für Linux, Container und SQL Managed Instance mit Azure Arc-Unterstützung

Wenn die SQL Server-Instanz unter Linux gehostet wird, einschließlich:

  • Eigenständiges Betriebssystem
  • Containers
  • Azure Arc-fähige SQL Managed Instance
  • Alle anderen Linux-basierten Umgebungen

Die einzige unterstützte Möglichkeit zur Sicherung über URLs für Azure Blob Storage besteht in einer Sicherung in Blockblobs unter Verwendung von Shared Access Signature.

Azure Blob Storage (Speicherdienst von Azure für unstrukturierte Daten)

Speicherkonto: Das Speicherkonto ist der Ausgangspunkt für alle Speicherdienste. Um auf Azure Blob Storage zuzugreifen, erstellen Sie zuerst ein Azure Storage-Konto. Weitere Informationen finden Sie unter Erstellen eines Speicherkontos.

Container: Ein Container stellt eine Gruppierung einer Gruppe von Blobs bereit und kann eine unbegrenzte Anzahl von Blobs speichern. Für eine SQL Server-Sicherung in Azure Blob Storage müssen Sie über mindestens einen Stammcontainer verfügen. Sie können ein Shared Access Signature-Token für einen Container generieren und den Zugriff nur auf Objekte in einem bestimmten Container gewähren.

Blob: Eine Datei eines beliebigen Typs und einer beliebigen Größe. Es gibt zwei Arten von Blobs, die in Azure Blob Storage gespeichert werden können: Blockblobs und Seitenblobs. Abhängig von der verwendeten Transact-SQL-Syntax können beide BLOB-Typen bei der Sicherung von SQL Server verwendet werden: Blobs sind mit dem folgenden URL-Format adressierbar: https://<storage account>.blob.core.windows.net/<container>/<blob>. Weitere Informationen zu Azure Blob Storage finden Sie unter Einführung in Azure Blob Storage. Weitere Informationen zu Seiten- und Block-BLOBs finden Sie unter Grundlegendes zu Block- und Seiten-BLOBs.

Diagramm von Azure Blob Storage-Konten, -Containern und -Blobs.

Azure-Momentaufnahme: Eine Momentaufnahme eines Azure-Blobs, die zu einem bestimmten Zeitpunkt erstellt wurde. Weitere Informationen finden Sie unter Erstellen einer Momentaufnahme eines BLOBs. Die SQL Server-Sicherung unterstützt nun Sicherungen über Momentaufnahmen für Datenbankdateien in Azure, die in Azure Blob Storage gespeichert werden. Weitere Informationen finden Sie unter Dateimomentaufnahme-Sicherungen für Datenbankdateien in Azure.

SQL Server-Komponenten

URL: Eine URL gibt einen URI (Uniform Resource Identifier) für eine eindeutige Sicherungsdatei an. Die URL dient zur Angabe des Speicherorts und Namens der SQL Server-Sicherungsdatei. Die URL muss auf ein tatsächliches BLOB, nicht nur auf einen Container verweisen. Wenn das Blob nicht vorhanden ist, wird es erstellt. Wenn ein vorhandenes Blob angegeben ist, schlägt BACKUP fehl, es sei denn, die Option WITH FORMAT wird angegeben, um die vorhandene Sicherungsdatei im Blob zu überschreiben.

Hier ist ein Beispiel-URL-Wert: https://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak.

Note

Die Sicherung zur URL mit HTTP wird nicht unterstützt.

Berechtigungsnachweis: Eine SQL Server-Anmeldeinformation ist ein Objekt, das zum Speichern von Authentifizierungsinformationen verwendet wird, die zum Herstellen einer Verbindung mit einer Ressource außerhalb von SQL Server erforderlich sind. Dabei verwenden die Sicherungs- und Wiederherstellungsprozesse von SQL Server Anmeldeinformationen für die Authentifizierung bei Azure Blob Storage und dessen Containern und Blobobjekten. Die Credentials speichern entweder den Namen des Speicherkontos und die Zugriffsschlüsselwerte des Speicherkontos oder die Container-URL und das Shared Access Signature-Token. Nachdem die Anmeldeinformationen erstellt wurden, bestimmt die Syntax der BACKUP/RESTORE Anweisungen den Blobtyp und die erforderlichen Anmeldeinformationen.

Ein Beispiel zum Erstellen einer Shared Access Signature finden Sie in den Beispielen unter Erstellen einer Shared Access Signature weiter unten in diesem Artikel. Informationen zum Erstellen von SQL Server-Anmeldeinformationen finden Sie in den Beispielen unter Erstellen von Anmeldeinformationen weiter unten in diesem Artikel.

Weitere Informationen über Anmeldenamen finden Sie unter Anmeldeinformationen (Datenbank-Engine).

Informationen mit weiteren Beispielen zur Verwendung von Anmeldeinformationen finden Sie unter Erstellen eines Proxys für den SQL Server-Agent.

Unterstützung für unveränderliche Azure-Speicher

SQL Server 2025 (17.x) bietet Unterstützung für unveränderlichen Azure-Speicher, der vor Ransomware-Angriffen schützt. Dateien, die in unveränderlichen Speicher geschrieben wurden, können nicht geändert oder gelöscht werden, wie durch Unveränderlichkeit definiert.

In der Regel werden SQL Server-Sicherungen in zwei Schritten erstellt. Zunächst wird die .bak Sicherungsdatei mit Nullen erstellt, und dann wird die Datei mit Daten aktualisiert. Da die Dateiänderung beim unveränderlichen Speicher nicht zulässig ist, nachdem die Datei geschrieben und zugesichert wurde, überspringt der Sicherungsvorgang jetzt den ersten Schritt, um die Sicherungsdatei mit Nullen zu erstellen. Stattdessen wird die gesamte Sicherung in einem Schritt erstellt, wenn sie zum Blockieren von Blobs geschrieben wurde.

Führen Sie die folgenden Schritte aus, um unveränderlichen Speicher mit SQL Server 2025 (17.x)-Sicherung zu URL zu verwenden:

  1. Konfigurieren Sie unveränderlichkeit für Ihren Azure-Speichercontainer.

  2. Stellen Sie die SICHERUNG aus, um Ihre Datenbank im Azure-Speichercontainer zu sichern. Wenn Sie die WITH FORMAT Option für unveränderlichen Speicher verwenden und eine Sicherung bereits mit demselben Namen vorhanden ist, wird ein Fehler angezeigt, und die Sicherung schlägt fehl.

    BACKUP DATABASE [<Database>] TO URL = '<url>';

Sicherheit für Azure Blob Storage

Die folgenden Sicherheitsüberlegungen und -anforderungen beziehen sich auf die Sicherung oder Wiederherstellung mit Azure Blob Storage.

  • Beim Erstellen eines Containers für Azure Blob Storage wird empfohlen, den Zugriff auf "Privat" festzulegen. Dadurch wird der Zugriff auf Benutzer oder Konten beschränkt, die über die erforderlichen Anmeldeinformationen zur Authentifizierung beim Azure-Konto verfügen.

    Important

    SQL Server erfordert, dass entweder ein Azure-Kontoname und ein Zugriffsschlüssel mit Authentifizierung oder eine freigegebene Zugriffs-Signatur und ein Zugriffstoken in SQL Server-Anmeldeinformationen gespeichert werden. Mithilfe dieser Informationen wird im Fall von Sicherungs- und Wiederherstellungsvorgängen die Authentifizierung beim Azure-Konto ausgeführt.

    Warning

    Azure Storage unterstützt das Deaktivieren der Shared Key-Autorisierung für ein Speicherkonto. Wenn die Autorisierung für gemeinsam genutzte Schlüssel deaktiviert ist, funktioniert die SQL Server-Sicherung auf URL nicht.

  • Das Benutzerkonto, das zum Ausgeben von BACKUP- oder RESTORE-Befehlen verwendet wird, sollte sich in der db_backup Operator-Datenbankrolle mit den Berechtigungen zum Ändern jeder Anmeldeinformation befinden.

Einschränkungen bei der Sicherung/Wiederherstellung mit Azure Blob Storage

  • SQL Server schränkt die maximale Sicherungsgröße, die mit einem Seitenblob unterstützt wird, auf 1 TB ein. Die maximale Sicherungsgröße, die mithilfe von Block-BLOBs unterstützt wird, ist auf ca. 200 GB (50.000 Blöcke * 4 MB MAXTRANSFERSIZE) beschränkt. Blockblobs unterstützen das Striping, um wesentlich größere Sicherungsgrößen zu unterstützen – der Grenzwert beträgt maximal 64 URLs, was zu der folgenden Formel führt: 64 stripes * 50,000 blocks * 4MB maxtransfersize = 12.8 TB

    Important

    Obwohl die von einem einzelnen Blockblob maximal unterstützte Sicherungsgröße bei 200 GB liegt, kann SQL Server in kleinere Blocks schreiben. Dadurch kann SQL Server das Limit von 50.000 Blocks erreichen, bevor die Sicherung vollständig übertragen wurde. Teilen Sie Sicherungen auf, auch wenn diese kleiner als 200 GB sind, um zu vermeiden, dass das Blocklimit erreicht wird. Das gilt insbesondere dann, wenn Sie differenzielle oder nicht komprimierte Sicherungen verwenden.

  • Sie können Sicherungs- oder Wiederherstellungsanweisungen mithilfe von Transact-SQL, SMO, PowerShell-Cmdlets oder dem SQL Server Management Studio-Sicherungs- oder Wiederherstellungs-Assistenten ausstellen.

  • Beim Sichern eines Azure Storage-Kontos unterstützt SQL Server nur die Authentifizierung mit SAS-Token (Shared Access Signature) oder Speicherkontoschlüsseln. Alle anderen Authentifizierungsmethoden, einschließlich der Authentifizierung mit Microsoft Entra ID (vormals Azure Active Directory), werden nicht unterstützt.

  • Das Erstellen eines logischen Gerätenamens wird nicht unterstützt. Das Hinzufügen von URL als Sicherungsgerät mithilfe sp_dumpdevice oder über SQL Server Management Studio wird daher nicht unterstützt.

  • Das Anfügen an vorhandene Sicherungs-Blobs wird nicht unterstützt. Sicherungen auf einem vorhandenen BLOB können nur unter Verwendung der Option WITH FORMAT überschrieben werden. Bei der Verwendung von Dateisnapshot-Sicherungen (mit dem Argument WITH FILE_SNAPSHOT) ist das Argument WITH FORMAT jedoch nicht zulässig, um zu vermeiden, dass verwaiste Dateisnapshots zurückbleiben, die mit der ursprünglichen Dateisnapshot-Sicherung erstellt wurden.

  • Um Daten in einem einzigen Sicherungsvorgang in mehrere BLOBs zu sichern, müssen Sie Block-BLOBs und ein SAS-Token anstelle der Speicherkontoschlüssel für die SQL-Anmeldeinformationen verwenden.

  • Die Angabe BLOCKSIZE wird für Seitenblobs nicht unterstützt.

  • Die Angabe von MAXTRANSFERSIZE wird bei Seitenblobs nicht unterstützt.

  • Angeben von Backupset-Optionen – RETAINDAYS und EXPIREDATE werden nicht unterstützt.

  • SQL Server auf 259 Zeichen begrenzt. Die BACKUP TO URL verbraucht 36 Zeichen für die erforderlichen Elemente zur Angabe der URL https://.blob.core.windows.net//.bak, sodass 223 Zeichen für die Konto-, Container- und Blobnamen übrig bleiben.

  • SQL Server 2019 (15.x) und frühere Versionen verfügen über ein Limit von 256 Zeichen für SAS-Token (Shared Access Signature), wodurch der Typ der verwendeten Token begrenzt wird (z. B. Benutzerdelegierungsschlüsseltoken werden nicht unterstützt).

  • Wenn Ihr Server über einen Proxyserver auf Azure zugreift, müssen Sie das Ablaufverfolgungsflag 1819 verwenden und dann die WinHTTP-Proxykonfiguration mit einer der folgenden Methoden festlegen:

    • Das proxycfg.exe Hilfsprogramm unter Windows XP oder Windows Server 2003 und früher.
    • Das netsh.exe Hilfsprogramm unter Windows Vista und Windows Server 2008 oder höher.

  • Unveränderlicher Speicher für Azure Blob Storage wird nicht unterstützt. Legen Sie die Unveränderliche Speicherrichtlinie auf "false" fest.

  • Die Sicherung auf URL wird für Premiumspeicher nicht unterstützt.

Unterstützte Argumente und Ausdrücke in Azure Blob Storage

Unterstützung für BACKUP-/RESTORE-Anweisungen in Azure Blob Storage

Backup/Restore-Anweisung Supported Exceptions Comments
BACKUP Yes BLOCKSIZE und MAXTRANSFERSIZE werden für Block-Blobs unterstützt. Sie werden nicht für Seiten-Blobs unterstützt. BACKUP für einen Block-BLOB ist eine freigegebene Zugriffssignatur erforderlich, die in einer SQL Server-Anmeldeinformation gespeichert ist. BACKUP erfordert den Speicherkontoschlüssel, der in SQL Server-Anmeldeinformationen gespeichert ist, und das WITH CREDENTIAL-Argument muss angegeben werden, um einen Seitenblob zu erstellen.
RESTORE Yes Erfordert, dass eine SQL Server-Anmeldeinformation definiert wird, und das WITH CREDENTIAL Argument muss angegeben werden, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden.
RESTORE FILELISTONLY Yes Erfordert, dass eine SQL Server-Anmeldeinformation definiert wird, und das WITH CREDENTIAL Argument muss angegeben werden, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden.
RESTORE HEADERONLY Yes Erfordert, dass eine SQL Server-Anmeldeinformation definiert wird, und das WITH CREDENTIAL Argument muss angegeben werden, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden.
RESTORE LABELONLY Yes Erfordert, dass eine SQL Server-Anmeldeinformation definiert wird, und das WITH CREDENTIAL Argument muss angegeben werden, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden.
RESTORE VERIFYONLY Yes Erfordert, dass eine SQL Server-Anmeldeinformation definiert wird, und das WITH CREDENTIAL Argument muss angegeben werden, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden.
RESTORE REWINDONLY No

Syntax und allgemeine Informationen zu Sicherungsanweisungen finden Sie unter BACKUP.

Syntax und allgemeine Informationen zu Wiederherstellungsanweisungen finden Sie unter RESTORE-Anweisungen.

Unterstützung für BACKUP-Argumente in Azure Blob Storage

Argument Supported Exception Comments
DATABASE Yes
LOG Yes
TO (URL) Yes Im Gegensatz zu DISK und TAPE, URL unterstützt nicht das Angeben oder Erstellen eines logischen Namens. Dieses Argument wird verwendet, um den URL-Pfad der Sicherungsdatei anzugeben.
MIRROR TO Yes
WITH Optionen:
CREDENTIAL Yes WITH CREDENTIAL wird nur unterstützt, wenn die Option BACKUP TO URL zum Sichern in Azure Blob Storage verwendet wird, und nur, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheim definiert sind.
FILE_SNAPSHOT Yes
ENCRYPTION Yes Wenn das WITH ENCRYPTION Argument angegeben wird, stellt SQL Server File-Snapshot Backup sicher, dass die gesamte Datenbank TDE-verschlüsselt wurde, bevor sie die Sicherung übernimmt, und verschlüsselt in diesem Fällen die Datei-Snapshot-Sicherungsdatei selbst mithilfe des algorithmus, der für TDE in der Datenbank angegeben ist. Wenn alle Daten in der Datenbank in der gesamten Datenbank nicht verschlüsselt sind, schlägt die Sicherung fehl (z. B. ist der Verschlüsselungsprozess noch nicht abgeschlossen).
DIFFERENTIAL Yes
COPY_ONLY Yes
COMPRESSION|NO_COMPRESSION Yes Wird für Dateimomentaufnahme-Sicherungen nicht unterstützt
DESCRIPTION Yes
NAME Yes
EXPIREDATE | RETAINDAYS No
NOINIT | INIT No Das Anfügen an BLOBs ist nicht möglich. Verwenden Sie das WITH FORMAT Argument, um eine Sicherung zu überschreiben. Bei der Verwendung von Dateimomentaufnahme-Sicherungen (mit dem WITH FILE_SNAPSHOT-Argument) ist das WITH FORMAT-Argument jedoch nicht erlaubt, um zu vermeiden, dass Dateimomentaufnahmen verwaist zurückbleiben, die mit der ursprünglichen Sicherung erstellt worden sind.
NOSKIP | SKIP No
NOFORMAT | FORMAT Yes Ein Backup, das bei einem vorhandenen Blob gemacht wird, schlägt fehl, es sei denn, WITH FORMAT wird angegeben. Das vorhandene Blob wird überschrieben, wenn WITH FORMAT angegeben wird. Bei der Verwendung von Dateisnapshot-Sicherungen (mit dem Argument WITH FILE_SNAPSHOT) ist das Argument FORMAT jedoch nicht zulässig, um zu vermeiden, dass verwaiste Dateisnapshots zurückbleiben, die mit der ursprünglichen Dateisnapshot-Sicherung erstellt wurden. Bei der Verwendung von Dateimomentaufnahme-Sicherungen (mit dem WITH FILE_SNAPSHOT-Argument) ist das WITH FORMAT-Argument jedoch nicht erlaubt, um zu vermeiden, dass Dateimomentaufnahmen verwaist zurückbleiben, die mit der ursprünglichen Sicherung erstellt worden sind.
MEDIADESCRIPTION Yes
MEDIANAME Yes
BLOCKSIZE Yes Nicht für Seiten-Blob unterstützt. Unterstützt für Block-Blob. Es wird empfohlen, BLOCKSIZE=65536 zu verwenden, um die in einem Block-BLOB zulässigen 50.000 Blöcke zu optimieren.
BUFFERCOUNT Yes
MAXTRANSFERSIZE Yes Nicht für Seiten-Blob unterstützt. Unterstützt für Block-Blob. Der Standardwert ist 1048576. Der Wert kann bis zu 4 MB in Schritten von 65.536 Byte reichen.

Es wird empfohlen, MAXTRANSFERSIZE=4194304 zu verwenden, um die in einem Block-BLOB zulässigen 50.000 Blöcke zu optimieren.
NO_CHECKSUM | CHECKSUM Yes
STOP_ON_ERROR | CONTINUE_AFTER_ERROR Yes
STATS Yes
REWIND | NOREWIND No
UNLOAD | NOUNLOAD No
NORECOVERY | STANDBY Yes
NO_TRUNCATE Yes

Weitere Informationen zu Sicherungsargumenten finden Sie unter BACKUP.

Unterstützung für RESTORE-Argumente in Azure Blob Storage

Argument Supported Exceptions Comments
DATABASE Yes
LOG Yes
FROM (URL) Yes Das FROM URL Argument wird verwendet, um den URL-Pfad für die Sicherungsdatei anzugeben.
WITH Optionen:
CREDENTIAL Yes WITH CREDENTIAL wird nur unterstützt, wenn die Option RESTORE FROM URL zum Wiederherstellen aus Azure Blob Storage verwendet wird.
PARTIAL Yes
RECOVERY | NORECOVERY | STANDBY Yes
LOADHISTORY Yes
MOVE Yes
REPLACE Yes
RESTART Yes
RESTRICTED_USER Yes
FILE No
PASSWORD Yes
MEDIANAME Yes
MEDIAPASSWORD Yes
BLOCKSIZE Yes
BUFFERCOUNT No
MAXTRANSFERSIZE No
CHECKSUM | NO_CHECKSUM Yes
STOP_ON_ERROR | CONTINUE_AFTER_ERROR Yes
FILESTREAM Yes Wird für Momentaufnahmesicherungen nicht unterstützt
STATS Yes
REWIND | NOREWIND No
UNLOAD | NOUNLOAD No
KEEP_REPLICATION Yes
KEEP_CDC Yes
ENABLE_BROKER | ERROR_BROKER_CONVERSATIONS | NEW_BROKER Yes
STOPAT | STOPATMARK | STOPBEFOREMARK Yes

Weitere Informationen zu RESTORE-Argumenten finden Sie unter RESTORE Statements - Argumente.

Sichern mit SSMS

Sie können eine Datenbank über URL mit dem Sicherungstask in SQL Server Management Studio mithilfe einer SQL-Server-Anmeldeinformation schützen.

Note

Um eine SQL Server-Dateimomentaufnahmesicherung zu erstellen oder einen vorhandenen Mediensatz zu überschreiben, müssen Sie Transact-SQL, PowerShell oder C# anstelle der Back Up-Aufgabe in SQL Server Management Studio verwenden.

Die folgenden Schritte beschreiben die Änderungen, die am Task „Datenbank sichern“ in SQL Server Management Studio vorgenommen wurde, um das Sichern in Azure Storage zu ermöglichen:

  1. Stellen Sie im Objekt-Explorer eine Verbindung mit einer Instanz der SQL Server-Datenbank-Engine her, und erweitern Sie anschließend diese Instanz.

  2. Erweitern Sie Datenbanken, klicken Sie mit der rechten Maustaste auf die gewünschte Datenbank, zeigen Sie auf Aufgaben, und wählen Sie dann Sichern... aus.

  3. Auf der Seite "Allgemein" im Abschnitt "Ziel " ist die URL-Option in der Dropdownliste " Back up to:" verfügbar. Die URL-Option wird verwendet, um eine Sicherung für Azure Storage zu erstellen. Wählen Sie "Hinzufügen" aus, und das Dialogfeld " Sicherungsziel auswählen " wird geöffnet:

    1. Azure-Speichercontainer: Der Name des Azure-Speichercontainers zum Speichern der Sicherungsdateien. Wählen Sie einen vorhandenen Container aus der Dropdownliste aus, oder geben Sie den Container manuell ein.

    2. Richtlinie für den freigegebenen Zugriff: Geben Sie die Signatur für den freigegebenen Zugriff für einen manuell eingegebenen Container ein. Dieses Feld ist nicht verfügbar, wenn ein vorhandener Container ausgewählt wurde.

    3. Sicherungsdatei: Name der Sicherungsdatei.

    4. Neuer Container: Wird verwendet, um einen vorhandenen Container zu registrieren, für den Sie keine Signatur für freigegebenen Zugriff haben. Weitere Informationen finden Sie unter Herstellen einer Verbindung zu einem Microsoft Azure-Abonnement (Erstellen von Sicherungen über URLs).

Note

Add unterstützt mehrere Sicherungsdateien und Speichercontainer für einen einzelnen Mediensatz.

Wenn Sie die URL als Ziel auswählen, werden bestimmte Optionen auf der Seite "Medienoptionen " deaktiviert. Weitere Informationen zum Dialogfeld „Datenbank sichern“ finden Sie in den folgenden Artikeln:

Sichern mit Wartungsplan

Ähnlich wie bei der zuvor beschriebenen Sicherungsaufgabe enthält der Wartungsplan-Assistent in SQL Server Management Studio die URL als eine der Zieloptionen und andere unterstützende Objekte, die zum Sichern von Azure-Speicher wie sql-Anmeldeinformationen erforderlich sind. Weitere Informationen finden Sie unter der Definieren von Sicherungstasks im Abschnitt Using Maintenance Plan Wizard.

Note

Sie müssen Transact-SQL, PowerShell oder C# anstelle des Sicherungstasks im Wartungsplanungsassistenten verwenden, um einen Sicherungssatz im Stripesetformat, eine SQL Server-Dateimomentaufnahmesicherung oder SQL-Anmeldeinformationen unter Verwendung eines Shared Access-Tokens zu erstellen.

Wiederherstellen mit SSMS

Die Aufgabe "Datenbank wiederherstellen" enthält die URL als Quelle zum Wiederherstellen. Führen Sie die folgenden Schritten aus, um eine Wiederherstellung mit Azure Blob Storage mithilfe der Wiederherstellungsaufgabe durchzuführen:

  1. Klicken Sie mit der rechten Maustaste auf Datenbanken , und wählen Sie " Datenbank wiederherstellen..." aus.

  2. Wählen Sie auf der Seite "Allgemein" unter dem Abschnitt "Quelle" die Option "Gerät" aus.

  3. Klicken Sie auf die Schaltfläche „Durchsuchen“ (...), um das Dialogfeld Sicherungsmedien auswählen zu öffnen.

  4. Wählen Sie die URL aus der Sicherungsmedientyp: Dropdown-Liste aus. Wählen Sie "Hinzufügen" aus, um das Dialogfeld " Speicherort der Sicherungsdatei auswählen " zu öffnen.

    1. Azure-Speichercontainer: Der vollqualifizierte Name des Azure-Speichercontainers, der die Sicherungsdateien enthält. Wählen Sie einen vorhandenen Container aus der Dropdownliste aus, oder geben Sie den vollqualifizierten Containernamen manuell ein.

    2. Signatur des freigegebenen Zugriffs: Wird verwendet, um die Signatur für den freigegebenen Zugriff für den angegebenen Container einzugeben.

    3. Hinzufügen: Wird verwendet, um einen vorhandenen Container zu registrieren, für den Sie keine Signatur für freigegebenen Zugriff haben. Weitere Informationen finden Sie unter Herstellen einer Verbindung zu einem Microsoft Azure-Abonnement (Erstellen von Sicherungen über URLs).

    4. OK: SQL Server stellt mithilfe der von Ihnen bereitgestellten SQL-Anmeldeinformationen eine Verbindung zum Azure-Speicher her und öffnet das Dialogfeld Sicherungsdatei in Microsoft Azure suchen. Die Sicherungsdateien, die sich im Speichercontainer befinden, werden auf dieser Seite angezeigt. Wählen Sie die Datei aus, die Sie zum Wiederherstellen verwenden möchten, und wählen Sie "OK" aus. Dadurch gelangen Sie zurück zum Dialogfeld " Sicherungsgeräte auswählen ", und wenn Sie in diesem Dialogfeld "OK " auswählen, gelangen Sie zurück zum Hauptdialogfeld " Wiederherstellen ", in dem Sie die Wiederherstellung abschließen können.

Code-Beispiele

Dieser Abschnitt enthält die folgenden Beispiele.

Note

Ein Lernprogramm zur Verwendung von SQL Server 2016 mit Azure Blob Storage finden Sie im Lernprogramm: Verwenden von Azure Blob Storage mit SQL Server

Erstellen einer SAS (Shared Access Signature)

In dem folgenden Beispiel werden Shared Access Signatures erstellt, die zum Erstellen von SQL Server-Anmeldeinformationen für einen neu erstellten Container verwendet werden können. Das Skript erstellt eine Shared Access Signature, die einer gespeicherten Zugriffsrichtlinie zugeordnet ist. Weitere Informationen finden Sie unter Shared Access Signatures, Teil 1: Grundlagen zum SAS-Modell. Das Skript schreibt auch den T-SQL-Befehl, der zum Erstellen der Anmeldeinformationen unter SQL Server erforderlich ist.

Note

Für das Beispiel ist Azure PowerShell erforderlich. Informationen zum Installieren und Verwenden von Azure PowerShell finden Sie unter Installieren und Konfigurieren von Azure PowerShell. Diese Skripts wurden mit Azure PowerShell 5.1.15063 überprüft.

Shared Access Signature, die einer gespeicherten Zugriffsrichtlinie zugeordnet ist

# Define global variables for the script
$prefixName = '<a prefix name>'  # used as the prefix for the name for various objects
$subscriptionName = '<your subscription name>'   # the name of subscription name you will use
$locationName = '<a data center location>'  # the data center region you will use
$storageAccountName = $prefixName + 'storage' # the storage account name you will create or use
$containerName = $prefixName + 'container'  # the storage container name to which you will attach the SAS policy with its SAS token
$policyName = $prefixName + 'policy' # the name of the SAS policy

# Set a variable for the name of the resource group you will create or use
$resourceGroupName = $prefixName + 'rg'

# adds an authenticated Azure account for use in the session
Connect-AzAccount

# set the tenant, subscription and environment for use in the rest of
Set-AzContext -SubscriptionName $subscriptionName

# create a new resource group - comment out this line to use an existing resource group
New-AzResourceGroup -Name $resourceGroupName -Location $locationName

# Create a new ARM storage account - comment out this line to use an existing ARM storage account
New-AzStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -Type Standard_RAGRS -Location $locationName

# Get the access keys for the ARM storage account
$accountKeys = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName

# Create a new storage account context using an ARM storage account
$storageContext = New-AzStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $accountKeys[0].value

# Creates a new container in Azure Blob Storage
$container = New-AzStorageContainer -Context $storageContext -Name $containerName
$cbc = $container.CloudBlobContainer

# Sets up a Stored Access Policy and a Shared Access Signature for the new container
$policy = New-AzStorageContainerStoredAccessPolicy -Container $containerName -Policy $policyName -Context $storageContext -ExpiryTime $(Get-Date).ToUniversalTime().AddYears(10) -Permission "rwld"
$sas = New-AzStorageContainerSASToken -Policy $policyName -Context $storageContext -Container $containerName
Write-Host 'Shared Access Signature= '$($sas.TrimStart('?'))''

# Outputs the Transact SQL to the clipboard and to the screen to create the credential using the Shared Access Signature
Write-Host 'Credential T-SQL'
$tSql = "CREATE CREDENTIAL [{0}] WITH IDENTITY='Shared Access Signature', SECRET='{1}'" -f $cbc.Uri, $sas.TrimStart('?')
$tSql | clip
Write-Host $tSql

Nachdem Sie das Skript erfolgreich ausgeführt haben, kopieren Sie den Befehl CREATE CREDENTIAL in ein Abfragetool, stellen eine Verbindung mit einer SQL Server-Instanz her und führen den Befehl zum Erstellen der Anmeldeinformationen mit der Shared Access Signature aus.

Erstellen von Anmeldeinformationen

In den folgenden Beispielen werden SQL Server-Anmeldeinformationen für die Authentifizierung bei Azure Blob Storage erstellt. Führen Sie einen der folgenden Schritte aus.

  1. Verwenden von Shared Access Signature

    Wenn Sie das oben genannte Skript zum Erstellen der Shared Access Signature ausgeführt haben, kopieren Sie CREATE CREDENTIAL in einen mit Ihrer SQL Server-Instanz verbundenen Abfrage-Editor, und führen Sie den Befehl aus.

    Der folgende T-SQL-Befehl ist ein Beispiel, das die Anmeldeinformationen für die Verwendung einer Shared Access Signature erstellt.

    IF NOT EXISTS (SELECT *
               FROM sys.credentials
               WHERE name = 'https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>')
    CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>]
        WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = '<SAS_TOKEN>';

  2. Verwenden der Identität und des Zugriffsschlüssels eines Speicherkontos

    IF NOT EXISTS (SELECT *
               FROM sys.credentials
               WHERE name = '<mycredentialname>')
    CREATE CREDENTIAL [<mycredentialname>]
        WITH IDENTITY = '<mystorageaccountname>', SECRET = '<mystorageaccountaccesskey>';

Ausführen einer vollständigen Datenbanksicherung

In den folgenden Beispielen wird eine vollständige Datenbanksicherung der Datenbank AdventureWorks2025 in Azure Blob Storage durchgeführt. Verwenden Sie eines der folgenden Beispiele:

  1. Zur URL unter Verwendung von Shared Access Signature

    BACKUP DATABASE AdventureWorks2022
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak';
GO

  2. Zur URL unter Verwendung der Identität und des Zugriffsschlüssels des Speicherkontos

    BACKUP DATABASE AdventureWorks2022
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak'
WITH CREDENTIAL = '<mycredentialname>',
COMPRESSION, STATS = 5;
GO

Wiederherstellen eines bestimmten Zeitpunkts mithilfe von STOPAT

Im folgenden Beispiel wird der Zustand der AdventureWorks2025-Beispieldatenbank zu einem bestimmten Zeitpunkt wiederhergestellt und ein Wiederherstellungsvorgang veranschaulicht.

Von URL unter Verwendung von Shared Access Signature

RESTORE DATABASE AdventureWorks2022
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022_2015_05_18_16_00_00.bak'
    WITH MOVE 'AdventureWorks2022_data' TO 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2022.mdf',
    MOVE 'AdventureWorks2022_log' TO 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2022.ldf',
    NORECOVERY, REPLACE, STATS = 5;
GO

RESTORE LOG AdventureWorks2022
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022_2015_05_18_18_00_00.trn'
    WITH RECOVERY, STOPAT = 'May 18, 2015 5:35 PM';
GO

Verwandte Inhalte

  • Last updated on