SQL Server Sicherung auf 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 erforderlich sind, um Azure Blob Storage als Sicherungsziel zu verwenden. 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.

Overview

SQL Server 2012 Service Pack 1 CU2 und SQL Server 2014 haben die Möglichkeit eingeführt, eine auf Azure Blob Storage verweisende URL zu sichern, wobei die vertraute T-SQL-Syntax verwendet wird, um Sicherungen sicher in Azure Speicher zu schreiben. 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 für 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.

Das Erstellen eines Azure Storage Kontos innerhalb Ihres Azure-Abonnements ist der erste Schritt in diesem Prozess. 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 dessen Zugriffsschlüsselwert verwenden, um Blobs zu authentifizieren und zu lesen und zu schreiben, oder ein Shared Access Signature-Token verwenden, das für bestimmte Container generiert wird und dem SQL Server Lese- und Schreibrechte gewährt. Weitere Informationen zu Azure-Speicherkonten finden Sie unter About Azure-Speicherkonten und weitere Informationen zu Shared Access Signatures finden Sie unter Shared Access Signatures, Part 1: Understanding the SAS Model. Die SQL Server Anmeldeinformationen speichern diese Authentifizierungsinformationen und werden während der Sicherungs- oder Wiederherstellungsvorgänge verwendet.

Azure Storage und S3-kompatibler Speicher

SQL Server 2022 (16.x) bietet die Möglichkeit, Sicherungen in S3-kompatiblen Objektspeicher zu schreiben, wobei die Sicherungs- und Wiederherstellungsfunktionalität konzeptuell mit der Verwendung von "Backup to URL" mit Azure Blob Storage als Sicherungsgerätetyp vergleichbar ist. SQL Server 2022 (16.x) erweitert die Syntax BACKUP/RESTORE TO/FROM URL durch Hinzufügen der Unterstützung für einen neuen S3-Connector mithilfe der REST-API.

Dieser Artikel enthält Informationen zur Verwendung von Backup to URL für Azure Blob Storage. Weitere Informationen zur Verwendung von Backup to URL für S3-kompatiblen Speicher finden Sie unter SQL Server Sichern der URL für den S3-kompatiblen Objektspeicher.

Sicherung auf Azure Storage Block-Blobs vs. Seiten-Blobs

Es gibt zwei Arten von Blobs, die in Azure Blob Storage gespeichert werden können: Block- und Seitenblobs. Für SQL Server 2016 und höher wird block blob bevorzugt.

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

Sicherung zum Blockieren des Blobs ist nur in SQL Server 2016 oder höherer Version für die Sicherung auf Azure Blob Storage verfügbar. Sichern, um blobs statt seitenblob zu blockieren, wenn Sie SQL Server 2016 oder höher ausführen.

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.

Das Erstellen einer Sicherung einer großen Datenbank zu Azure Blob Storage unterliegt den in Azure SQL Managed Instance 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
• Sicherungen auf mehreren Blockblobs auszuführen

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

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

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

Die einzige unterstützte Sicherung zu URL für Azure Blob Storage besteht darin, Blobs mithilfe der Signatur für den freigegebenen Zugriff zu blockieren.

Azure Blob Storage

Speicherkonto: Das Speicherkonto ist der Ausgangspunkt für alle Speicherdienste. Um auf Azure Blob Storage zuzugreifen, erstellen Sie zuerst ein Azure Speicherkonto. 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. Um eine SQL Server Sicherung in Azure Blob Storage zu schreiben, müssen Sie mindestens den Stammcontainer erstellt haben. 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: Block- und Seitenblobs. SQL Server Sicherung kann je nach verwendeter 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 Introduction to Azure Blob Storage. Weitere Informationen zu Seiten- und Block-BLOBs finden Sie unter Grundlegendes zu Block- und Seiten-BLOBs.

Azure Snapshot: Eine Momentaufnahme eines Azure Blobs zu einem Zeitpunkt. Weitere Informationen finden Sie unter Erstellen einer Momentaufnahme eines BLOBs. SQL Server-Sicherung unterstützt jetzt Azure Snapshot-Sicherungen von Datenbankdateien, die in Azure Blob Storage gespeichert sind. Weitere Informationen finden Sie unter File-Snapshot 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 wird verwendet, um den Speicherort und den Namen der SQL Server Sicherungsdatei anzugeben. 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.

Credential: 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. Hier verwenden SQL Server Sicherungs- und Wiederherstellungsprozesse Anmeldeinformationen, um sich für Azure Blob Storage und deren Container- und BLOB-Objekte zu authentifizieren. 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 für die Erstellung einer Freigabezugriffssignatur finden Sie unter Create a Shared Access Signature-Beispiele später in diesem Artikel. Für die Erstellung eines SQL Server-Anmeldedatensatzes siehe Create a credential-Beispiele später in diesem Artikel.

Weitere Informationen zu Anmeldeinformationen finden Sie unter Credentials (Datenbank-Engine).

Weitere Informationen zu anderen Beispielen, in denen Anmeldeinformationen verwendet werden, finden Sie unter Create a SQL Server-Agent Proxy.

Azure unveränderliche Speicherunterstützung

SQL Server 2025 (17.x) bietet Unterstützung für Azure unveränderlichen 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.

Azure Speicher bietet zwei Arten von Unveränderlichkeit, Containerebene und Versionsebene. Derzeit wird nur unveränderlicher Speicher auf Containerebene unterstützt.

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änderbarkeit für Ihren Azure-Speichercontainer.

2. Stellen Sie das BACKUP aus, um Die 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

Im Folgenden finden Sie Sicherheitsüberlegungen und Anforderungen beim Sichern oder Wiederherstellen von Azure Blob Storage.

• Beim Erstellen eines Containers für Azure Blob Storage wird empfohlen, den Zugriff auf private festzulegen. Das Festlegen des Zugriffs auf "Privat" beschränkt den Zugriff auf Benutzer oder Konten, die die erforderlichen Informationen für die Authentifizierung beim Azure Konto bereitstellen können.

  Important

  SQL Server erfordert, dass entweder ein Azure-Kontoname und die Zugriffsschlüssel-Authentifizierung oder eine Shared Access Signature und Zugriffstoken in einer SQL Server Anmeldeinformation gespeichert werden. Diese Informationen werden verwendet, um sich beim Azure Konto zu authentifizieren, wenn Sicherungs- oder Wiederherstellungsvorgänge ausgeführt werden.

  Warning

  Azure Storage unterstützt die Deaktivierung der Autorisierung durch gemeinsam genutzte Schlüssel für ein Speicherkonto. Wenn die Autorisierung für gemeinsam genutzte Schlüssel deaktiviert ist, funktioniert 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 der Sicherung/Wiederherstellung für Azure Blob Storage

• SQL Server beschränkt die maximale Sicherungsgröße, die mit einem Seitenblob auf 1 TB unterstützt wird. Die maximale Sicherungsgröße, die mit Block-Blobs unterstützt wird, ist auf ca. 195,3 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 unterstützte maximale Backup-Größe ungefähr 195,3 GB beträgt, ist es möglich, dass SQL Server in kleineren Blockgrößen schreiben kann. Dies kann dazu führen, dass SQL Server das Limit von 50.000 Blöcken erreicht, bevor das gesamte Backup ü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.

• Transaktionsprotokollsicherungen ignorieren die vom Benutzer angegebenen MAXTRANSFERSIZE, wenn sie auf mehrere Sicherungsdateien gesichert werden. Stattdessen wird 64 KB verwendet, wenn mehrere Dateien angegeben werden, unabhängig vom MAXTRANSFERSIZE Wert im Sicherungsbefehl. Daher beträgt die maximale Größe einer Transaktionsprotokollsicherung auf URL ungefähr 195,3 GB (50.000 Blöcke * 4 MB MAXTRANSFERSIZE * 1 Datei ODER 50.000 Blöcke * 64 KB * 64 Dateien). Die Komprimierung kann die Sicherung eines größeren Transaktionsprotokolls ermöglichen, die Komprimierungsverhältnisse variieren jedoch.

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

• Bei der Sicherung 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 ( früher 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 mit 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 hat eine maximale Grenze von 259 Zeichen für den Namen eines Sicherungsgeräts. 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üheren Versionen haben einen Grenzwert von 256 Zeichen für SAS-Token (Shared Access Signature), wodurch der Typ der verwendeten Token eingeschränkt wird (z. B. werden Token für benutzerdelegierungsschlüssel nicht unterstützt).

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

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

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

• Unterstützung in SQL Server 2025 und höheren Versionen finden Sie unter Azure unveränderliche Speicherunterstützung.

  • Azure Speicher bietet zwei Arten von Unveränderlichkeit, Containerebene und Versionsebene. Derzeit wird nur unveränderlicher Speicher auf Containerebene unterstützt.

• 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 Sicherungs-/Wiederherstellungsanweisungen in Azure Blob Storage

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 Sicherungsargumente in Azure Blob Storage

Weitere Informationen zu Sicherungsargumenten finden Sie unter BACKUP.

Unterstützung für Wiederherstellungsargumente in Azure Blob Storage

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

Sichern mit SSMS

Sie können eine Datenbank mithilfe einer SQL Server-Anmeldeinformation über die Back Up-Aufgabe in dem SQL Server Management Studio sichern.

In den folgenden Schritten werden die Änderungen beschrieben, die an der Aufgabe "Datenbank sichern" in SQL Server Management Studio vorgenommen wurden, um die Sicherung auf Azure Speicher zu ermöglichen:

1. Stellen Sie in Objekt-Explorer eine Verbindung mit einer Instanz des SQL Server-Datenbank-Engine her, und erweitern Sie 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 Option URL wird verwendet, um eine Sicherung zum Azure Speicher 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. Siehe Connect to a Microsoft Azure Subscription (Backup TO URL).

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:

• Datenbank sichern (Seite „Allgemein“)
• Datenbank sichern (Seite "Medienoptionen")
• Datenbank sichern (Seite „Sicherungsoptionen“)
• Anmeldeinformationen erstellen – Authentifizieren bei Azure Storage

Sichern mit Wartungsplan

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

Wiederherstellen mit SSMS

Die Aufgabe "Datenbank wiederherstellen" enthält die URL als Quelle zum Wiederherstellen. Die folgenden Schritte beschreiben die Verwendung der Wiederherstellungsaufgabe zum Wiederherstellen von Azure Blob Storage:

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. Siehe Connect to a Microsoft Azure Subscription (Backup TO URL).

   4. OK: SQL Server stellt eine Verbindung mit dem Azure-Speicher mithilfe der bereitgestellten SQL-Anmeldeinformationen 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.

      • Datenbank wiederherstellen (Allgemeine Seite)
      • Datenbank wiederherstellen (Seite Dateien)
      • Datenbank wiederherstellen (Seite Optionen)

Code-Beispiele

Dieser Abschnitt enthält die folgenden Beispiele.

• Erstellen einer Shared Access Signature
• Erstellen von Anmeldeinformationen
• Ausführen einer vollständigen Datenbanksicherung
• Wiederherstellen zu einem bestimmten Zeitpunkt mithilfe von STOPAT

Erstellen einer SAS (Shared Access Signature)

Im folgenden Beispiel werden Shared Access Signaturen erstellt, die verwendet werden können, um ein SQL Server-Credential in einem neu erstellten Container zu erstellen. 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 für SQL Server erforderlich ist.

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 Befehl CREATE CREDENTIAL 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 Signatur für den freigegebenen Zugriff zu erstellen.

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 vorherige Skript zum Erstellen der Signatur für den freigegebenen Zugriff ausgeführt haben, kopieren Sie die CREATE CREDENTIAL in einen Abfrage-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>';
   

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

• SQL Server-Backup auf URL für Microsoft Azure Blob Storage: Best Practices und Problembehandlung
• Backup und Wiederherstellung: Systemdatenbanken (SQL Server)
• Tutorial: Azure Blob Storage mit SQL Server