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.
Überblick
Es ist wichtig, die Komponenten und die Interaktion zwischen ihnen zu verstehen, um eine Sicherung durchzuführen oder aus Microsoft 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 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
SQL Server 2012 Service Pack 1 CU2 und SQL Server 2014 haben die Möglichkeit eingeführt, eine AUF Azure Blob Storage verweisende URL mit vertrauter T-SQL-Syntax zu sichern, um Sicherungen sicher in Azure Storage zu schreiben. 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. SQL Server 2022 (16.x) bietet die Möglichkeit, Sicherungen in S3-kompatiblen Objektspeicher zu schreiben, wobei die Sicherungs- und Wiederherstellungsfunktionalität konzeptuell dem Arbeiten mit Backup to URL unter Verwendung von Azure Blob Storage als Sicherungsgerätetyp ähnelt. SQL Server 2022 (16.x) erweitert die SYNTAX BACKUP/RESTORE TO/FROM URL durch Hinzufügen von Unterstützung für einen neuen S3-Connector mithilfe der REST-API.
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 bis zu mehreren Block-Blobs sichern, um eine bessere Sicherung und Wiederherstellung der Leistung zu erzielen und eine größere Datenbanksicherung zu unterstützen.
- Blockblobs sind kostengünstiger als Seitenblobs.
- Kunden, die über einen Proxyserver auf Seitenblobs sichern müssen, müssen verwendet
backuptourl.exewerden.
Das Erstellen einer Sicherung einer großen Datenbank zu Azure Blob Storage unterliegt den in Azure SQL verwaltete Instanz T-SQL-Unterschieden, Einschränkungen und bekannten Problemen aufgeführten Einschränkungen.
Wenn die Datenbank zu groß ist, haben Sie die Möglichkeit:
- Verwenden von Sicherungskomprimierung oder
- Sichern in mehreren Block-Blobs
Unterstützung für Linux, Container und SQL-verwaltete Instanz von Azure Arc aktiviert
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. Die SQL Server-Sicherung kann abhängig von der verwendeten Transact-SQL-Syntax einen blob-Typ verwenden. 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: http[s]://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak. HTTPS ist zwar nicht erforderlich, aber empfehlenswert.
Anmeldeinformationen: 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. 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 ein Azure-Kontoname und eine Zugriffsschlüsselauthentifizierung oder ein Signatur- und Zugriffstoken für freigegebenen Zugriff 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. Block-Blobs 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 maximale Sicherungsgröße, die von einem einzelnen Block-BLOB unterstützt wird, 200 GB beträgt, ist es möglich, dass SQL Server in kleinere Blockgrößen schreiben kann, was DAZU führen kann, dass SQL Server das 50.000-Blocklimit erreicht, bevor die gesamte Sicherung übertragen wird. 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, SQL Server Management Studio-Sicherungs- oder Wiederherstellungs-Assistenten ausstellen.
Die Sicherung im Azure Storage-Konto unterstützt 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 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 Benutzerdelegierungsschlü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 und 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. BACKUP-zu-Seiten-BLOB erfordert, dass der Speicherkontoschlüssel in einer SQL Server-Anmeldeinformation gespeichert ist und das WITH CREDENTIAL-Argument angegeben werden muss. |
| RESTORE | J | Erfordert, dass eine SQL Server-Anmeldeinformation definiert wird, und das ARGUMENT WITH CREDENTIAL muss angegeben werden, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden. | |
| RESTORE FILELISTONLY | J | Erfordert, dass eine SQL Server-Anmeldeinformation definiert wird, und das ARGUMENT WITH CREDENTIAL muss angegeben werden, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden. | |
| RESTORE HEADERONLY | J | Erfordert, dass eine SQL Server-Anmeldeinformation definiert wird, und das ARGUMENT WITH CREDENTIAL muss angegeben werden, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden. | |
| RESTORE LABELONLY | J | Erfordert, dass eine SQL Server-Anmeldeinformation definiert wird, und das ARGUMENT WITH CREDENTIAL muss angegeben werden, wenn die SQL Server-Anmeldeinformationen mithilfe des Speicherkontoschlüssels als geheimer Schlüssel definiert werden. | |
| RESTORE VERIFYONLY | J | Erfordert, dass eine SQL Server-Anmeldeinformation definiert wird, und das ARGUMENT WITH CREDENTIAL muss angegeben werden, 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 | Wenn das ARGUMENT WITH ENCRYPTION angegeben wird, stellt sql Server File-Snapshot Backup sicher, dass die gesamte Datenbank vor dem Erstellen der Sicherung TDE verschlüsselt wurde und, falls ja, die Datei-Momentaufnahme Sicherungsdatei selbst mit dem algorithmus verschlüsselt, der für TDE in der Datenbank angegeben ist. 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 | ||
| KOMPRIMIERUNG|NO_COMPRESSION | J | Wird für Dateimomentaufnahme-Sicherungen nicht unterstützt | |
| BESCHREIBUNG | J | ||
| NAME | J | ||
| ABGELAUFEN | 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 | ÜBERSPRINGEN | - | ||
| 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 | PRÜFSUMME | J | ||
| STOP_ON_ERROR | CONTINUE_AFTER_ERROR | J | ||
| STATISTIK | J | ||
| RÜCKSPULEn | NOREWIND | - | ||
| ENTLADEN | 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 | ||
| WIEDERHERSTELLUNG | 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 | - | ||
| PRÜFSUMME | NO_CHECKSUM | J | ||
| STOP_ON_ERROR | CONTINUE_AFTER_ERROR | J | ||
| FILESTREAM | J | Wird für Momentaufnahmesicherungen nicht unterstützt | |
| STATISTIK | J | ||
| RÜCKSPULEn | NOREWIND | - | ||
| ENTLADEN | 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
Um eine SQL Server-Datei-Momentaufnahme Sicherung 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:
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 Standard Tenance-Plan
Ä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.
Hinweis
Zum Erstellen eines gestreiften Sicherungssatzes, einer SQL Server-Datei-Momentaufnahme Sicherung oder einer SQL-Anmeldeinformation mit freigegebenem Zugriffstoken müssen Sie Transact-SQL, Powershell oder C# anstelle der Sicherungsaufgabe im Wartungsplan-Assistenten verwenden.
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, der die Sicherungsdateien enthält. 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 gelangen Sie zurück zum Dialogfeld "Sicherungsgeräte auswählen", und wenn Sie in diesem Dialogfeld "OK" auswählen, gelangen Sie zurück zum Dialogfeld "Standard Wiederherstellen", in dem Sie die Wiederherstellung abschließen können.
Datenbank wiederherstellen (Seite „Allgemein“)
Codebeispiele
Dieser Abschnitt enthält die folgenden Beispiele.
Hinweis
Ein Lernprogramm zur Verwendung von SQL Server 2016 mit Azure Blob Storage finden Sie im Lernprogramm: Verwenden von Azure Blob Storage mit SQL Server-Datenbanken
Erstellen einer SAS (Shared Access Signature)
Im folgenden Beispiel werden Freigegebene Zugriffssignaturen erstellt, die zum Erstellen einer SQL Server-Anmeldeinformation in einem 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
Kopieren Sie nach dem erfolgreichen Ausführen des Skripts den CREATE CREDENTIAL Befehl in ein Abfragetool, stellen Sie eine Verbindung mit einer Instanz von SQL Server her, und führen Sie den Befehl aus, um die Anmeldeinformationen mit der Freigegebenen Zugriffssignatur zu erstellen.
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 vorherige Skript zum Erstellen der Signatur für den freigegebenen Zugriff ausgeführt haben, kopieren Sie den
CREATE CREDENTIALAbfrage-Editor, der mit Ihrer Instanz von SQL Server verbunden ist, 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 AdventureWorks2022 Datenbank in Azure Blob Storage ausgefü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 die AdventureWorks2022 Beispieldatenbank zu einem zeitpunkt in seinem Zustand wiederhergestellt, und es wird ein Wiederherstellungsvorgang angezeigt.
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-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für