SQL Server-Sicherung über URLs für Microsoft Azure Blob Storage
Gilt für:
SQL ServerAzure SQL Managed Instance
In diesem Artikel werden die Konzepte, Anforderungen und Komponenten vorgestellt, die Sie benötigen, wenn Sie Microsoft Azure Blob Storage als Sicherungsziel nutzen möchten. Die Sicherungs- und Wiederherstellungsfunktion sind gleich oder ähnlich wie beim Verwenden von DISK oder TAPE, mit wenigen Unterschieden. Diese Unterschiede sowie einige Codebeispiele lernen Sie in diesem Artikel kennen.
Übersicht
Es ist wichtig, die Komponenten und Interaktionen zwischen den einzelnen Komponenten zu kennen, wenn Sie Daten mit Microsoft Azure Blob Storage sichern oder wiederherstellen möchten.
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 Azure Storage-Kontonamen und den zugehörigen Zugriffsschlüsselwert für die Authentifizierung und das Schreiben und Lesen von Blobs in Microsoft Azure Blob Storage oder ein Shared Access Signature-Token verwenden, das für bestimmte Container generiert wird und Lese- und Schreibberechtigungen enthält. 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 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. Mit SQL Server 2016 (13.x) wurden Sicherungen über Dateimomentaufnahmen für Datenbankdateien in Azure sowie Sicherheit über SAS-Schlüssel (Shared Access Signature) eingeführt. Dies ist eine sichere und einfache Möglichkeit, Zertifikate bei der Azure Storage-Sicherheitsrichtlinie zu authentifizieren. 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. In SQL Server 2022 (16.x) wird die Syntax vom Typ „BACKUP/RESTORE TO/FROM URL“ durch Hinzufügen von Unterstützung für einen neuen S3-Connector mithilfe der REST-API erweitert.
Dieser Artikel enthält Informationen zur Verwendung von „Sicherung über URLs“ für Azure Blob Storage. Weitere Informationen zur Verwendung von „Sicherung über URLs“ für S3-kompatiblen Speicher finden Sie unter Sichern und Wiederherstellen in SQL Server mit S3-kompatiblem Objektspeicher.
Sichern in Azure Storage: Blockblobs im Vergleich zu Seitenblobs
Es gibt zwei Arten von Blobs, die in Microsoft 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.
- Blockblobs sind kostengünstiger als Seitenblobs.
- Kunden, die Sicherungen in Seitenblobs über einen Proxyserver durchführen, müssen
backuptourl.exeverwenden.
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
- Container
- 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.
Microsoft Azure Blob Storage
Speicherkonto: Das Speicherkonto ist der Ausgangspunkt für alle Speicherdienste. Erstellen Sie für den Zugriff auf Microsoft Azure Blob Storage zunächst ein Azure Storage-Konto. Weitere Informationen finden Sie unter Erstellen eines Speicherkontos.
Container: In einem Container können mehrere BLOBs gruppiert und eine unbegrenzte Anzahl von BLOBs gespeichert werden. 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 von beliebiger Art und 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.
Azure-Momentaufnahme: Eine Momentaufnahme eines Azure-BLOBs zu einem bestimmten Zeitpunkt. 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. Wird ein vorhandenes BLOB angegeben, erzeugt BACKUP einen Fehler, es sei denn, die WITH FORMAT-Option ist angegeben, um die vorhandene Sicherungsdatei im BLOB zu überschreiben.
Hier ist ein Beispiel-URL-Wert aufgeführt: https://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak.
Hinweis
Die Sicherung zur URL mit HTTP wird NICHT unterstützt.
Anmeldeinformationen: SQL Server-Anmeldeinformationen sind ein Objekt zum Speichern von Authentifizierungsinformationen, die für die 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. Als Anmeldeinformationen werden entweder der Name und die Zugriffsschlüsselwerte des Speicherkontos oder die Container-URL und das zugehörige Shared Access Signature-Token gespeichert. Sobald die Anmeldeinformationen erstellt wurden, bestimmt die Syntax der BACKUP/RESTORE-Anweisungen den Typ des BLOBs 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 allgemeine Informationen über Anmeldeinformationen finden Sie unter Anmeldeinformationen.
Informationen mit weiteren Beispielen zur Verwendung von Anmeldeinformationen finden Sie unter Erstellen eines Proxys für den SQL Server-Agent.
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.
Wichtig
SQL Server erfordert, dass entweder der Name und Zugriffsschlüssel zur Authentifizierung beim Azure-Konto oder eine Shared Access Signature und das 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.
Warnung
Azure Storage unterstützt das Deaktivieren der Autorisierung mit gemeinsam verwendeten Schlüsseln für ein Speicherkonto. Wenn die Autorisierung mit gemeinsam verwendeten Schlüsseln deaktiviert ist, kann die SQL Server-Sicherung über URLs nicht verwendet werden.
Das zum Ausgeben von BACKUP- oder RESTORE-Befehlen verwendete Benutzerkonto sollte Mitglied der Datenbankrolle db_backup operator sein und über Berechtigungen zum Ändern beliebiger Anmeldeinformationen verfügen.
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 maximal unterstützte Größe für Sicherungen mit Blockblobs 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 TBWichtig
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 ausgeben, indem Sie Transact-SQL, SMO, PowerShell-Cmdlets, SQL Server Management Studio Backup oder den Wiederherstellungs-Assistenten verwenden.
Die Sicherung im Azure Storage-Konto unterstützt nur die Authentifizierung mit SAS-Token (Shared Access Signature) oder Speicherkontoschlüsseln. Es werden keine anderen Authentifizierungsmethoden, darunter die Microsoft Entra-ID-Authentifizierung (ehemals Azure Active Directory), unterstützt.
Das Erstellen von Namen für logische Geräte wird nicht unterstützt. Folglich ist es nicht möglich, eine URL mithilfe von sp_dumpdevice oder über SQL Server Management Studio als Sicherungsmedium hinzuzufügen.
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. Allerdings ist das Argument WITH FORMAT bei Verwendung von Dateimomentaufnahme-Sicherungen (mit dem Argument WITH FILE_SNAPSHOT ) nicht zulässig, um zu vermeiden, dass Dateimomentaufnahmen, die mit der ursprünglichen Dateimomentaufnahme-Sicherung erstellt wurden, verwaist zurückbleiben.
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.
Das Angeben von BLOCKSIZE wird für Seiten-Blobs nicht unterstützt.
Das Angeben von MAXTRANSFERSIZE wird für Seiten-Blobs nicht unterstützt.
Die Angabe von Sicherungssatzoptionen mit RETAINDAYS und EXPIREDATE wird nicht unterstützt.
SQL Server auf 259 Zeichen begrenzt. Da BACKUP TO URL 36 Zeichen für die erforderlichen Elemente zur Angabe der URL (https://.blob.core.windows.net//.bak ) beansprucht, verbleiben insgesamt noch 223 Zeichen für Konto-, Container- und Blobnamen.
SQL Server-Versionen vor 2022 verfügen über ein Limit von 256 Zeichen für SAS-Token (Shared Access Signature), wodurch der Typ der verwendeten Token eingeschränkt wird (z. B. werden Benutzer-Delegierungsschlüsseltoken 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:
- Dem proxycfg.exe-Hilfsprogramm unter Windows XP oder Windows Server 2003 und früher.
- Dem 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 Richtlinie Unveränderlicher Speicher auf FALSE fest.
Unterstützte Argumente Anweisungen in Azure Blob Storage
Unterstützung für BACKUP-/RESTORE-Anweisungen in Azure Blob Storage
| BACKUP-/RESTORE-Anweisung | Unterstützt | Ausnahmen | Kommentare |
|---|---|---|---|
| BACKUP | J | BLOCKSIZE und MAXTRANSFERSIZE werden für Block-Blobs unterstützt. Sie werden nicht für Seiten-Blobs unterstützt. | Die Sicherung in einem Block-Blob erfordert eine SAS, die in einer SQL Server-Anmeldeinformation gespeichert ist. Die Sicherung auf einem Seiten-Blob erfordert den Speicherkontoschlüssel, der in einer SQL Server-Anmeldeinformation gespeichert ist, und erfordert das Argument WITH CREDENTIAL, um festgelegt zu werden. |
| RESTORE | J | Erfordert die Definition von SQL Server-Anmeldeinformationen sowie die Angabe des Arguments WITH CREDENTIAL, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden. | |
| RESTORE FILELISTONLY | J | Erfordert die Definition von SQL Server-Anmeldeinformationen sowie die Angabe des Arguments WITH CREDENTIAL, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden. | |
| RESTORE HEADERONLY | J | Erfordert die Definition von SQL Server-Anmeldeinformationen sowie die Angabe des Arguments WITH CREDENTIAL, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden. | |
| RESTORE LABELONLY | J | Erfordert die Definition von SQL Server-Anmeldeinformationen sowie die Angabe des Arguments WITH CREDENTIAL, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden. | |
| RESTORE VERIFYONLY | J | Erfordert die Definition von SQL Server-Anmeldeinformationen sowie die Angabe des Arguments WITH CREDENTIAL, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden. | |
| RESTORE REWINDONLY | - |
Allgemeine und Syntaxinformationen zu BACKUP-Anweisungen finden Sie unter BACKUP (Transact-SQL).
Allgemeine und Syntaxinformationen zu RESTORE-Anweisungen finden Sie unter RESTORE (Transact-SQL).
Unterstützung für BACKUP-Argumente in Azure Blob Storage
| Argument | Unterstützt | Exception | Kommentare |
|---|---|---|---|
| DATABASE | J | ||
| PROTOKOLL | J | ||
| TO (URL) | J | Bei URL wird das Angeben bzw. Erstellen eines logischen Namens im Gegensatz zu DISK und TAPE nicht unterstützt. | Dieses Argument wird verwendet, um den URL-Pfad der Sicherungsdatei anzugeben. |
| MIRROR TO | J | ||
| WITH-OPTIONEN: | |||
| CREDENTIAL | J | WITH CREDENTIAL wird nur unterstützt, wenn die Option BACKUP TO URL für die Sicherung in Azure Blob Storage verwendet wird und die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als Geheimnis definiert werden. | |
| FILE_SNAPSHOT | J | ||
| ENCRYPTION | J | Wird das Argument WITH ENCRYPTION angegeben, gewährleistet die SQL Server-Dateimomentaufnahme-Sicherung, dass die gesamte Datenbank vor dem Erstellen der Sicherung mit TDE verschlüsselt wurde, und verschlüsselt die Dateimomentaufnahme-Sicherungsdatei selbst in diesem Fall mit dem für TDE in der Datenbank angegebenen Algorithmus. Die Sicherung schlägt fehl, wenn nicht alle Daten in der gesamten Datenbank verschlüsselt sind (wenn z. B. der Verschlüsselungsvorgang noch nicht abgeschlossen ist). | |
| DIFFERENTIAL | J | ||
| COPY_ONLY | J | ||
| COMPRESSION|NO_COMPRESSION | J | Wird für Dateimomentaufnahme-Sicherungen nicht unterstützt | |
| BESCHREIBUNG | J | ||
| NAME | J | ||
| EXPIREDATE | RETAINDAYS | - | ||
| NOINIT | INIT | - | Das Anfügen an BLOBs ist nicht möglich. Verwenden Sie zum Überschreiben einer Sicherung das Argument WITH FORMAT. Allerdings ist das Argument WITH FORMAT bei Verwendung von Dateimomentaufnahme-Sicherungen (mit dem Argument WITH FILE_SNAPSHOT ) nicht zulässig, um zu vermeiden, dass Dateimomentaufnahmen, die mit der ursprünglichen Dateimomentaufnahme-Sicherung erstellt wurden, verwaist zurückbleiben. | |
| NOSKIP | SKIP | - | ||
| NOFORMAT | FORMAT | J | Eine Sicherung, die auf ein vorhandenes BLOB geschrieben wird, ist nur erfolgreich, wenn WITH FORMAT angegeben wird. Das vorhandene BLOB wird bei Angabe von WITH FORMAT überschrieben. Allerdings ist das Argument FORMAT bei Verwendung von Dateimomentaufnahme-Sicherungen (mit dem Argument WITH FILE_SNAPSHOT ) nicht zulässig, um zu vermeiden, dass Dateimomentaufnahmen, die mit der ursprünglichen Dateimomentaufnahme-Sicherung erstellt wurden, verwaist zurückbleiben. Allerdings ist das Argument WITH FORMAT bei Verwendung von Dateimomentaufnahme-Sicherungen (mit dem Argument WITH FILE_SNAPSHOT ) nicht zulässig, um zu vermeiden, dass Dateimomentaufnahmen, die mit der ursprünglichen Dateimomentaufnahme-Sicherung erstellt wurden, verwaist zurückbleiben. | |
| MEDIADESCRIPTION | J | ||
| MEDIANAME | J | ||
| BLOCKSIZE | J | Nicht für Seiten-Blob unterstützt. Unterstützt für Block-Blob. | Empfohlen BLOCKSIZE = 65536 zum Optimieren der Verwendung von 50.000 Blöcken, die in einem Block-Blob zulässig sind. |
| BUFFERCOUNT | J | ||
| MAXTRANSFERSIZE | J | Nicht für Seiten-Blob unterstützt. Unterstützt für Block-Blob. | Der Standardwert ist 1048576. Der Wert kann in einem Bereich bis zu 4 MB in Schritten von 65.536 Bytes liegen. Empfohlen MAXTRANSFERSIZE = 4194304 zum Optimieren der Verwendung von 50.000 Blöcken, die in einem Block-Blob zulässig sind. |
| NO_CHECKSUM | CHECKSUM | J | ||
| STOP_ON_ERROR | CONTINUE_AFTER_ERROR | J | ||
| STATISTIK | J | ||
| REWIND | NOREWIND | - | ||
| UNLOAD | NOUNLOAD | - | ||
| NORECOVERY | STANDBY | J | ||
| NO_TRUNCATE | J |
Weitere Informationen zu BACKUP-Argumenten finden Sie unter BACKUP (Transact-SQL).
Unterstützung für RESTORE-Argumente in Azure Blob Storage
| Argument | Unterstützt | Ausnahmen | Kommentare |
|---|---|---|---|
| DATABASE | J | ||
| PROTOKOLL | J | ||
| FROM (URL) | J | Das FROM URL-Argument wird verwendet, um den URL-Pfad der Sicherungsdatei anzugeben. | |
| WITH Options: | |||
| CREDENTIAL | J | WITH CREDENTIAL wird nur unterstützt, wenn die Option RESTORE FROM URL für die Wiederherstellung mit Azure Blob Storage verwendet wird. | |
| PARTIAL | J | ||
| RECOVERY | NORECOVERY | STANDBY | J | ||
| LOADHISTORY | J | ||
| MOVE | J | ||
| REPLACE | J | ||
| RESTART | J | ||
| RESTRICTED_USER | J | ||
| FILE | - | ||
| PASSWORD | J | ||
| MEDIANAME | J | ||
| MEDIAPASSWORD | J | ||
| BLOCKSIZE | J | ||
| BUFFERCOUNT | - | ||
| MAXTRANSFERSIZE | - | ||
| CHECKSUM | NO_CHECKSUM | J | ||
| STOP_ON_ERROR | CONTINUE_AFTER_ERROR | J | ||
| FILESTREAM | J | Wird für Momentaufnahmesicherungen nicht unterstützt | |
| STATISTIK | J | ||
| REWIND | NOREWIND | - | ||
| UNLOAD | NOUNLOAD | - | ||
| KEEP_REPLICATION | J | ||
| KEEP_CDC | J | ||
| ENABLE_BROKER | ERROR_BROKER_CONVERSATIONS | NEW_BROKER | J | ||
| STOPAT | STOPATMARK | STOPBEFOREMARK | J |
Weitere Informationen zu RESTORE-Argumenten finden Sie unter RESTORE- Argumente (Transact-SQL).
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.
Hinweis
Sie müssen allerdings Transact-SQL, Powershell oder C# anstelle des Sicherungstasks in SQL Server Management Studio verwenden, um eine SQL Server-Dateimomentaufnahme-Sicherung zu erstellen oder einen vorhandenen Mediensatz zu überschreiben.
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:
Stellen Sie im Objekt-Explorer eine Verbindung mit einer Instanz der SQL Server-Datenbank-Engine her, und erweitern Sie anschließend diese Instanz.
Erweitern Sie Datenbanken, und klicken Sie mit der rechten Maustaste auf die gewünschte Datenbank. Zeigen Sie auf Aufgaben, und klicken Sie anschließend auf Sichern....
Die Option URL ist in der Dropdownliste Back up to: (Sichern auf:) auf der Seite Allgemein im Abschnitt Ziel verfügbar. Die Option URL wird verwendet, um eine Sicherung im Windows Azure-Speicher zu erstellen. Klicken Sie auf Hinzufügen. Das Dialogfeld Sicherungsziel auswählen wird geöffnet:
Azure-Speichercontainer: Der Name des Windows Azure-Speichercontainers, um die Sicherungsdateien zu speichern. Wählen Sie einen vorhandenen Container aus der Dropdown Liste aus, oder geben Sie ihn manuell ein.
Richtlinie für den gemeinsamen Zugriff: Geben Sie die SAS (Shared Access Signature) für einen manuell eingegebenen Container an. Dieses Feld ist nicht verfügbar, wenn ein vorhandener Container ausgewählt wurde.
Sicherungsdatei: Name der Sicherungsdatei.
Neuen Container: Wird verwendet, um einen vorhandenen Container zu registrieren, für den Sie über keine SAS verfügen. Weitere Informationen finden Sie unter Herstellen einer Verbindung zu einem Microsoft Azure-Abonnement.
Hinweis
Hinzufügen unterstützt mehrere Sicherungsdateien und Speichercontainer für einen einzelnen Mediensatz.
Wenn Sie eine URL als Ziel auswählen, sind bestimmte Optionen auf der Seite Medienoptionen deaktiviert. Weitere Informationen zum Dialogfeld „Datenbank sichern“ finden Sie in den folgenden Artikeln:
Sichern mit Wartungsplan
Ähnlich dem zuvor beschriebenen Sicherungstask umfasst der Wartungsplanungs-Assistent in SQL Server Management Studio URL als eine der Zieloptionen sowie andere unterstützende Objekte, die erforderlich sind, um Daten in Azure Storage zu sichern, z. B. die SQL-Anmeldeinformationen. Weitere Informationen finden Sie unter der Definieren von Sicherungstasks im Abschnitt Using Maintenance Plan Wizard.
Hinweis
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 als Medium eine URL , von der aus wiederhergestellt wird. Führen Sie die folgenden Schritten aus, um eine Wiederherstellung mit Azure Blob Storage mithilfe der Wiederherstellungsaufgabe durchzuführen:
Klicken Sie mit der rechten Maustaste auf Datenbanken , und wählen Sie Datenbank wiederherstellenaus.
Wählen Sie auf der Seite Allgemein im Abschnitt Quelle die Option Gerät aus.
Klicken Sie auf die Schaltfläche „Durchsuchen“ (...), um das Dialogfeld Sicherungsmedien auswählen zu öffnen.
Wählen Sie eine URL aus der Dropdownliste Sicherungsmedientyp aus. Klicken Sie auf Hinzufügen, um das Dialogfeld Speicherort der Sicherungsdatei auswählen zu öffnen.
Azure-Speichercontainer: Der vollqualifizierte Name des Microsoft Azure-Speichercontainers, mit dem Sicherungsdateien gespeichert werden. Wählen Sie einen vorhandenen Container aus der Dropdownliste aus, oder geben Sie manuell einen vollqualifizierten Containernamen ein.
Shared Access Signature: Wird verwendet, um die SAS für den angegebenen Container einzugeben.
Hinzufügen: Wird verwendet, um einen vorhandenen Container zu registrieren, für den Sie über keine SAS verfügen. Weitere Informationen finden Sie unter Herstellen einer Verbindung zu einem Microsoft Azure-Abonnement.
OK: SQL Server stellt mithilfe der angegebenen SQL-Anmeldeinformationen eine Verbindung mit dem Microsoft 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 für die Wiederherstellung verwenden möchten, und klicken Sie auf OK. Dadurch werden Sie wieder zum Dialogfeld Sicherungsmedien auswählen geleitet. Wenn Sie in diesem Dialogfeld OK auswählen, wird das Hauptdialogfeld Wiederherstellen aufgerufen, in dem Sie die Wiederherstellung abschließen können.
Datenbank wiederherstellen (Seite „Allgemein“)
Codebeispiele
Dieser Abschnitt enthält die folgenden Beispiele.
Hinweis
Ein Tutorial zur Verwendung von SQL Server 2016 mit Azure Blob Storage finden Sie unter Tutorial: Verwenden von Azure Blob Storage mit SQL Server-Datenbanken.
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.
Hinweis
Dieses Beispiel erfordert Microsoft Azure PowerShell. 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.
Anmeldeinformation erstellen
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.
Verwenden von Shared Access Signature
Wenn Sie das oben genannte Skript zum Erstellen der Shared Access Signature ausgeführt haben, kopieren Sie
CREATE CREDENTIALin 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>';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 AdventureWorks2022 in Azure Blob Storage durchgeführt. Verwenden Sie eines der folgenden Beispiele:
Zur URL unter Verwendung von Shared Access Signature
BACKUP DATABASE AdventureWorks2022 TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak'; GOZur 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 AdventureWorks2022-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
Zugehöriger Inhalt
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Einreichen und Feedback anzeigen für