Übung: Wiederherstellen bis zu einem bestimmten Zeitpunkt

10 Minuten

In dieser Übung lernen Sie, wie Sie einen häufigen Fehler mit Hilfe der Zeitpunktwiederherstellung (Point-in-Time Restore, PITR) beheben können. Dieser Prozess kann einfach über das Portal oder programmgesteuert durchgeführt werden. In dieser Übung erfahren Sie jedoch, wie Sie Ihn mithilfe der Azure CLI durchführen.

Setup: Verwenden von Skripts zum Bereitstellen der Azure SQL-Datenbank

Im Terminal auf der rechten Seite sehen Sie Azure Cloud Shell, eine Möglichkeit, mit Azure über einen Browser zu interagieren. Bevor Sie mit den Übungen beginnen, müssen Sie ein Skript ausführen, um Ihre Umgebung zu erstellen: eine Azure SQL-Datenbank, die die AdventureWorks-Datenbank enthält. Im Skript werden einige Eingabeaufforderungen für ein Kennwort und Ihre lokale IP-Adresse angezeigt.

Das Ausführen dieser Skripts sollte drei bis fünf Minuten dauern. Notieren Sie sich unbedingt Ihr Kennwort, Ihre eindeutige ID und Ihre Region, denn sie werden nicht mehr angezeigt.

Zum Abrufen der erforderlichen IP-Adresse müssen Sie sich ggf. von einem VPN-Dienst trennen und (Invoke-WebRequest -Uri "https://ipinfo.io/ip").Content in einem lokalen PowerShell-Fenster ausführen (nicht in diesem Browser). Notieren Sie sich die resultierende IP-Adresse.

Führen Sie das folgende Skript rechts auf dieser Seite in Azure Cloud Shell aus. Geben Sie ein komplexes Kennwort und die öffentliche IP-Adresse ein, wenn Sie dazu aufgefordert werden.

$adminSqlLogin = "cloudadmin"
$password = Read-Host "Your username is 'cloudadmin'. Please enter a password for your Azure SQL Database server that meets the password requirements"
# Prompt for local IP address
$ipAddress = Read-Host "Disconnect your VPN, open PowerShell on your machine and run '(Invoke-WebRequest -Uri "https://ipinfo.io/ip").Content'. Please enter the value (include periods) next to 'Address': "
# Get resource group and location and random string
$resourceGroup = Get-AzResourceGroup | Where ResourceGroupName -like "<rgn>[sandbox resource group name]</rgn>"
$resourceGroupName = "<rgn>[sandbox resource group name]</rgn>"
$uniqueID = Get-Random -Minimum 100000 -Maximum 1000000
$storageAccountName = "mslearnsa"+$uniqueID
$location = $resourceGroup.Location
# The logical server name has to be unique in the system
$serverName = "aw-server$($uniqueID)"

Speichern Sie die Informationen, die Sie im gesamten Modul immer wieder benötigen, in einer Textdatei oder einem vergleichbaren Speicherort, und geben Sie sie aus, indem Sie das folgende Skript in Azure Cloud Shell ausführen. Wahrscheinlich müssen Sie die EINGABETASTE drücken, nachdem Sie den Code eingefügt haben, da die letzte Zeile nicht standardmäßig ausgeführt wird.
```
Write-Host "Please note your unique ID for future exercises in this module:"  
Write-Host $uniqueID
Write-Host "Your resource group name is:"
Write-Host $resourceGroupName
Write-Host "Your resources were deployed in the following region:"
Write-Host $location
Write-Host "Your server name is:"
Write-Host $serverName
```
Wichtig

Vergessen Sie nicht, Ihr Kennwort, die eindeutige ID und die Region zu notieren. Diese Informationen benötigen Sie im Verlauf des gesamten Moduls.

Führen Sie das folgende Skript aus, um eine Azure SQL-Datenbank und einen logischen Server mit dem AdventureWorks-Beispiel bereitzustellen. Dieses Skript fügt außerdem Ihre IP-Adresse als Firewall-Regel hinzu, aktiviert Microsoft Defender for Cloud und erstellt ein Speicherkonto für die Verwendung in zukünftigen Lerneinheiten.

# The logical server name has to be unique in the system
$serverName = "aw-server$($uniqueID)"
# The sample database name
$databaseName = "AdventureWorks"
# The storage account name has to be unique in the system
$storageAccountName = $("sql$($uniqueID)")
# Create a new server with a system-wide unique server name
$server = New-AzSqlServer -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -Location $location `
    -SqlAdministratorCredentials $(New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $adminSqlLogin, $(ConvertTo-SecureString -String $password -AsPlainText -Force))
# Create a server firewall rule that allows access from the specified IP range and all Azure services
$serverFirewallRule = New-AzSqlServerFirewallRule `
    -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -FirewallRuleName "AllowedIPs" `
    -StartIpAddress $ipAddress -EndIpAddress $ipAddress
$allowAzureIpsRule = New-AzSqlServerFirewallRule `
    -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -AllowAllAzureIPs
# Create a database
$database = New-AzSqlDatabase  -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -DatabaseName $databaseName `
    -SampleName "AdventureWorksLT" `
    -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5"
# Enable Azure Defender
$azureDefender = Enable-AzSqlServerAdvancedDataSecurity `
    -ResourceGroupName $resourceGroupName `
    -ServerName $serverName
# Create a storage account
$storageAccount = New-AzStorageAccount -ResourceGroupName $resourceGroupName `
    -AccountName $storageAccountName `
    -Location $location `
    -Type "Standard_LRS"

Öffnen Sie SSMS auf Ihrem lokalen Computer, und stellen Sie eine neue Verbindung mit Ihrem logischen Server her. Geben Sie für den Servernamen den Namen Ihres logischen Azure SQL-Datenbank-Servers ein. Wenn Sie den Namen zuvor nicht gespeichert haben, müssen Sie diesen möglicherweise im Azure-Portal suchen. Beispiel: aw-server\<unique ID>.database.windows.net

Azure portal
1. Im Suchfeld des Azure-Portals können Sie AdventureWorks eingeben, um Ihre Datenbank und den zugehörigen logischen Server zu suchen.
2. Wählen Sie im Feld Authentifizierung die Option SQL Server-Authentifizierung aus. Geben Sie den entsprechenden Anmeldenamen und das Kennwort für das Serveradministratorkonto ein (diese haben Sie während der Bereitstellung in der vorherigen Übung angegeben).
3. Aktivieren Sie das Kontrollkästchen Kennwort speichern, und klicken Sie auf Verbinden.
Hinweis

Je nach lokaler Konfiguration (z. B. VPN) unterscheidet sich Ihre Client-IP-Adresse möglicherweise von der IP-Adresse, die im Azure-Portal bei der Bereitstellung verwendet wurde. In diesem Fall wird eine Meldung angezeigt: „Ihre Client-IP-Adresse hat keinen Zugriff auf den Server. Melden Sie sich bei einem Azure-Konto an, und erstellen Sie eine neue Firewallregel, um den Zugriff zu ermöglichen.“ Wenn diese Meldung angezeigt wird, melden Sie sich mit dem Konto an, das Sie für die Sandbox verwenden, und fügen Sie eine Firewallregel für Ihre Client-IP-Adresse hinzu. All diese Schritte können Sie mit dem Popupassistenten in SSMS durchführen.

Vollständige Zeitpunktwiederherstellung

Zunächst einmal müssen Sie den empfohlenen Prozess für die Durchführung einer Zeitpunktwiederherstellung kennen, bevor Sie fortfahren:

Angenommen, eine Tabelle oder Datenbank wird versehentlich gelöscht.
Bestimmen Sie den Zeitpunkt, zu dem Sie zurückgehen müssen; er sollte vor dem Auftreten des Fehlers liegen.
Führen Sie eine vollständige Zeitpunktwiederherstellung über PowerShell oder das Azure-Portal durch, um bis zu diesem Zeitpunkt zurückzukehren. Durch diesen Prozess wird eine neue Datenbank bereitgestellt, und eine Kopie Ihrer Datenbank wird wiederhergestellt. Beispiele: AdventureWorks-copy.
Vergewissern Sie sich, dass sich die neue Datenbank (z. B. AdventureWorks-copy) im richtigen Zustand befindet (wie vor dem Vorfall).
Benennen Sie die ursprüngliche Datenbank um. Geben Sie der Datenbank AdventureWorks beispielsweise den Namen AdventureWorks-old.
Geben Sie der neuen Datenbank den Namen der ursprünglichen Datenbank. Geben Sie der Datenbank AdventureWorks-copy beispielsweise den Namen AdventureWorks.
Löschen Sie die ursprüngliche Datenbank. Beispiele: AdventureWorks-old.

Diese Schritte führen Sie in dieser Übung aus.

Simulieren der Löschung von Daten

Stellen Sie zunächst sicher, dass die Tabelle, die Sie versehentlich löschen werden, vorhanden ist und Daten enthält. Als Nächstes sehen Sie sich einige der Werte in SalesLT.OrderDetail an.

Rufen Sie SSMS auf, und überprüfen/aktualisieren Sie Ihre Verbindung. Wählen Sie Datei>Objekt-Explorer verbinden und dann die Schaltfläche Optionen aus.
Stellen Sie sicher, dass Ihre Verbindung mit dem logischen Server hergestellt wird, aber nicht mit einer spezifischen Datenbank. (Verwenden Sie beispielsweise wie im folgenden Screenshot gezeigt <default> [Standard]). Stellen Sie außerdem sicher, dass die Registerkarte Zusätzliche Verbindungsparameter keinen Text enthält.
Erweitern Sie den Ordner Datenbanken, klicken Sie dann mit der rechten Maustaste auf Ihre AdventureWorks-Datenbank und wählen Sie Neue Abfrage. Geben Sie die folgende Abfrage ein und führen Sie sie aus, indem Sie Ausführen wählen und prüfen Sie dann die Ergebnisse:
```
SELECT TOP 10 * from SalesLT.SalesOrderDetail
```
Simulieren Sie den Datenverlust, indem Sie die Tabelle in der Datenbank löschen.

Führen Sie diese Abfrage im gleichen Abfragefenster aus, wählen Sie dann die Registerkarte Meldungen im Ergebnisfenster und notieren Sie die Bearbeitungszeit:
```
DROP TABLE SalesLT.SalesOrderDetail
```
Wichtig

Speichern Sie die Abschlusszeit. Sie benötigen die Information später. Hier ist ein Beispiel: Completion time: 2020-06-22T09:20:27.1859237-07:00.

Bevor Sie mit den Schritten zur Wiederherstellung der Datenbank beginnen, führen Sie abschließend den folgenden Code in Azure Cloud Shell rechts auf dieser Seite aus, um Ihre Umgebung zu konfigurieren:

$resourceGroup = Get-AzResourceGroup | Where ResourceGroupName -like <rgn>[sandbox resource group name]</rgn>
$server = Get-AzureRmSqlServer -ResourceGroupName $resourceGroup.ResourceGroupName
$logical_server = $server.ServerName
$resource_group = $resourceGroup.ResourceGroupName

# Specify your default resource group and Azure SQL Database logical server
az configure --defaults group=$resource_group sql-server=$logical_server

# Confirm the defaults are set
az configure --list-defaults

Die zurückgegebenen Parameter group und sql-server sollten dem Namen Ihrer Microsoft Learn-Ressourcengruppe und dem Ihres logischen Azure SQL-Datenbank-Servers entsprechen.

Bestimmen des Zeitpunkts, zu dem die Datenbank wiederhergestellt werden soll

Der erste Schritt besteht darin, den Zeitpunkt für die Wiederherstellung der Datenbank zu bestimmen. Sie müssen in Erfahrung bringen, wann die letzte „gute“ Transaktion vor der „schlechten“ aufgetreten ist. Sie stellen den Zeitpunkt vor der schlechten Transaktion, aber nach der letzten guten Transaktion her.

Eine Möglichkeit zum Bestimmen des Löschzeitpunkts besteht darin, die Abschlusszeit der DROP-Anweisung zu untersuchen, die Sie sich im vorherigen Schritt notiert haben.

Eine alternative Möglichkeit besteht in der Verwendung der Überwachungsprotokolle im Azure-Portal. In dieser Übung haben Sie die Überwachung für Log Analytics nicht konfiguriert, aber sehen wir uns an, was Sie tun könnten, wenn Sie dies getan hätten. Sie könnten Ihre Azure SQL-Datenbank im Azure-Portal aufrufen. Wählen Sie im linken Bereich unter Sicherheit die Option Überwachung und dann die Option Überwachungsprotokolle anzeigen aus. Wenn Sie anschließend Log Analytics auswählen, gelangen Sie zu einem Abfrage-Editor, mit dem Sie Protokolle mit der Kusto Query Language (KQL) abfragen können. SQL-Experten können diese Abfragesprache verwenden, um Protokolle problemlos abzufragen.

Sie könnten dann die folgende KQL-Abfrage ausführen:
```
search database_name_s == "AdventureWorks"
| where Category == 'SQLSecurityAuditEvents' and statement_s like 'DROP'
| project format_datetime(event_time_t, 'yyyy-MM-dd hh:mm:ss.fff'), ResourceGroup, server_instance_name_s, database_name_s,  statement_s, succeeded_s,client_ip_s, server_principal_name_s, application_name_s
| sort by event_time_t desc
```
Die Ergebnisse sollten den folgenden Ergebnissen ähneln, allerdings sollten sie ein anderes Datum und eine andere Uhrzeit aufweisen.

Hinweis

Es kann 5 bis 10 Minuten dauern, bis die Protokolle hier erscheinen. Für die Zwecke dieser Übung haben wir sie daher weggelassen. Sie verwenden stattdessen die Bearbeitungszeit, die Sie im vorherigen Schritt notiert haben. (Sie müssen sie in das GMT-Format umwandeln.) In einer realen Situation ist es unwahrscheinlich, dass Sie zum Fenster mit der Abschlusszeit gelangen, sodass die Überwachung eine großartige Hilfe sein kann.
In diesem Beispiel stammen Datum/Uhrzeit 2020-07-24 08:06:24.386 aus Log Analytics und 2020-07-24T13:06:24.386-07:00 aus SSMS. Dabei unterscheidet sich erforderliche Format geringfügig. Verwenden Sie das folgende Beispiel, um das richtige Format festzulegen. Sie sollten auch 0,001 Sekunden subtrahieren, um sicherzustellen, dass Sie einen Zustand zum Zeitpunkt vor dem Auftreten des Fehlers wiederherstellen:
- Log Analytics-Format: 2020-07-24 08:06:24.386
- SSMS-Format: 2020-07-24T13:06:24.386-07:00
- Das erforderliche Format: 2020-07-24T20:06:24.385
Legen Sie $before_error_time auf den sich ergebenden Wert fest und ersetzen Sie die Zeit in diesem Beispiel durch Ihre Zeit:
```
$before_error_time ="2020-07-24T20:06:24.385"
```

Wiederherstellen der Datenbank und Bestätigen, dass Daten fehlen

In diesem Abschnitt verwenden Sie az cli db restore, um den Zustand der Datenbank vor dem Löschen der Tabelle wiederherzustellen.

Führen Sie im Terminal auf der rechten Seite dieses Fensters das folgende Skript aus:
```
# Restore the database to a time before the database was deleted
az sql db restore --dest-name "AdventureWorks-copy" --name "AdventureWorks" --time $before_error_time --verbose
```
Die Wiederherstellung wird etwa 5 bis 10 Minuten dauern. Beim Ausführen einer Wiederherstellung stellt Azure auf Ihrem logischen Azure SQL-Datenbankserver eine neue Azure SQL-Datenbank bereit. Die neue Datenbank verfügt über die gleichen Konfigurationsoptionen wie die ursprüngliche Datenbank. Nachdem die Azure SQL-Datenbank bereitgestellt wurde, stellt Azure die Datenbank in der neuen Azure SQL-Datenbank wieder her.
Sie können den Status überprüfen, indem Sie die Ansicht der Datenbanken in SSMS aktualisieren. Klicken Sie mit der rechten Maustaste auf den Ordner Datenbanken und wählen Sie Aktualisieren aus. Nachdem die Datenbank bereitgestellt wurde, werden Sie feststellen, dass die Wiederherstellung ausgeführt wird:

Nachdem Sie festgestellt haben, dass die Wiederherstellung im Gange ist, sollte diese noch zwei bis drei Minuten dauern. Dass der Vorgang beendet ist, erkennen Sie daran, dass der Befehl abgeschlossen ist. Außerdem wird beim Starten einer Aktualisierung neben der kopierten Datenbank nicht mehr „(Wird wiederhergestellt...)“ angezeigt.

Wenn Sie bemerken, dass die Wiederherstellung länger dauert als die zuvor angegebene Zeit, könnte dies auf Ihre Microsoft Learn-Umgebung zurückzuführen sein. Für die Anzahl der Wiederherstellungsanforderungen, die für ein Abonnement auf einmal verarbeitet bzw. übermittelt werden können, gilt eine Begrenzung. Wenn Sie in der Zwischenzeit mehr über die Grenzen und damit verbundene Details über die Zeitpunktwiederherstellung (PITR) erfahren möchten, lesen Sie Wiederherstellen einer Datenbank aus einer Sicherung in Azure SQL-Datenbank.
Nun stellen Sie sicher, dass die neue Datenbank den richtigen Status (wie vor Auftreten des Fehlers) aufweist. Klicken Sie mit der rechten Maustaste auf den logischen Server in SSMS und dann auf Aktualisieren, um die Verbindung mit dem logischen Azure SQL-Datenbank-Server zu aktualisieren.
Klicken Sie mit der rechten Maustaste auf die neue Datenbank (z. B. AdventureWorks-copy) und dann auf Neue Abfrage.
Verwenden Sie diese Abfrage, um zu bestätigen, dass die Tabelle vorhanden ist:
```
SELECT TOP 10 * from SalesLT.SalesOrderDetail
```
Sie sollten Ergebnisse erhalten, die denen auf dem folgenden Screenshot ähneln. Dadurch wird bestätigt, dass die Datenbank an der gewünschten Stelle wiederhergestellt wird.

Austauschen der Datenbanken und Bereinigen

Als nächstes benennen Sie die ursprüngliche Datenbank in AdventureWorks-old um, damit Sie später die neue Datenbank so umbenennen können, dass sie den ursprünglichen Datenbanknamen verwendet. Wenn Ihre Anwendungen eine Wiederholungslogik verwenden, wird dies nach der Änderung automatisch gemacht, sodass Sie keine Verbindungszeichenfolgen verändern müssen.

Wenn die Datenbank zu einem bestimmten Zeitpunkt als nicht verfügbar angezeigt wird (z. B. können Sie keine Verbindung mit den Datenbanken in SSMS herstellen, wenn Sie die Verbindung aktualisieren), kann das daran liegen, dass die DNS-Tabelle aktualisiert wird. Obwohl die Datenbank also physisch verfügbar ist, ist eine Auflösung nicht möglich. Wenn Sie eine Minute warten, sollten Sie die normalen Aktivitäten fortsetzen können.

Verwenden Sie diesen Befehl, um den Datenbanknamen zu ändern:

az sql db rename --name "AdventureWorks" --new-name "AdventureWorks-old"

Nachdem der Name der ursprünglichen Datenbank nun nicht mehr verwendet wird, können Sie der kopierten Datenbank den Namen der ursprünglichen Datenbank geben. Verwenden Sie hierzu wieder Azure Cloud Shell:
```
az sql db rename --name "AdventureWorks-copy" --new-name "AdventureWorks"
```
Sie benötigen die alte Datenbank nicht, sodass Sie sie mit az sql db delete löschen können:
```
az sql db delete --name "AdventureWorks-old" --yes
Write-Host "Database deleted"
```
Mithilfe des folgenden Befehls können Sie überprüfen, ob die alte Datenbank nicht mehr vorhanden ist:
```
az sql db list -o table
```

Nun wissen Sie, wie Sie die Zeitpunktwiederherstellung in Azure SQL-Datenbank nutzen. Die Zeitpunktwiederherstellung ist auch in Azure SQL Managed Instance für Datenbanken, nicht aber für eine ganze Instanz verfügbar. Sie können fast dieselben Befehle verwenden, mit dem Unterschied, dass Sie az sql midb anstelle von az sql db verwenden müssen.