Sichern und Wiederherstellen von SQL-Datenbanken auf virtuellen Azure-Computern mit PowerShell
In diesem Artikel wird beschrieben, wie Sie mit Azure PowerShell eine SQL-Datenbank auf einem virtuellen Azure-Computer mithilfe des Azure Backup Recovery Services-Tresors sichern und wiederherstellen.
In diesem Artikel wird Folgendes erläutert:
- Einrichten von PowerShell und Registrieren des Azure Recovery Services-Anbieters
- Erstellen Sie einen Recovery Services-Tresor.
- Konfigurieren der Sicherung für eine SQL-Datenbank auf einem virtuellen Azure-Computer
- Ausführen eines Sicherungsauftrags
- Wiederherstellen einer gesicherten SQL-Datenbank
- Überwachen von Sicherungs- und Wiederherstellungsaufträgen
Vorbereitung
- Lesen Sie weitere Informationen zu Recovery Services-Tresoren.
- Erfahren Sie mehr über die Funktionen zum Sichern von SQL-Datenbanken auf virtuellen Azure-Computern.
- Sehen Sie sich die PowerShell-Objekthierarchie für Recovery Services an.
Recovery Services-Objekthierarchie
Die Objekthierarchie ist im folgenden Diagramm zusammengefasst.
Sehen Sie sich die Cmdlet-Referenz zu Az.RecoveryServices in der Azure-Bibliothek an.
Einrichten und Installieren
Richten Sie PowerShell wie folgt ein:
Laden Sie die neueste Version von Azure PowerShell herunter. Version 1.5.0 ist die erforderliche Mindestversion.
Ermitteln Sie die PowerShell-Cmdlets für Azure Backup mit dem folgenden Befehl:
Get-Command *azrecoveryservices*Sehen Sie sich die Aliase und Cmdlets für Azure Backup und den Recovery Services-Tresor an. Unten sehen Sie eine Beispielanzeige. Dies ist keine vollständige Liste der Cmdlets.
Melden Sie sich mit Connect-AzAccount bei Ihrem Azure-Konto an.
Auf der daraufhin angezeigten Webseite werden Sie aufgefordert, Ihre Kontoanmeldeinformationen einzugeben.
- Alternativ können Sie Ihre Kontoanmeldeinformationen als Parameter im Cmdlet Connect-AzAccount mit -Credential angeben.
- Wenn Sie als CSP-Partner für einen Mandanten tätig sind, geben Sie den Kunden mit dessen Mandanten-ID oder primärem Mandantendomänennamen als Mandanten an. Beispiel: Connect-AzAccount -Tenant fabrikam.com.
Da ein Konto mehrere Abonnements enthalten kann, müssen Sie das Abonnement, das Sie verwenden möchten, dem Konto zuordnen.
Select-AzSubscription -SubscriptionName $SubscriptionNameFalls Sie Azure Backup zum ersten Mal verwenden, registrieren Sie den Azure Recovery Services-Anbieter für Ihr Abonnement mithilfe des Cmdlets Register-AzResourceProvider.
Register-AzResourceProvider -ProviderNamespace "Microsoft.RecoveryServices"Überprüfen Sie, ob die Anbieter erfolgreich registriert wurden:
Get-AzResourceProvider -ProviderNamespace "Microsoft.RecoveryServices"Vergewissern Sie sich in der Befehlsausgabe, dass sich der Wert für RegistrationState in Registered ändert. Ist dies nicht der Fall, führen Sie das Cmdlet Register-AzResourceProvider erneut aus.
Erstellen eines Recovery Services-Tresors
Führen Sie die nachstehenden Schritte aus, um einen Recovery Services-Tresors zu erstellen.
Der Recovery Services-Tresor ist eine Resource Manager-Ressource. Deshalb müssen Sie ihn in eine Ressourcengruppe einfügen. Sie können eine vorhandene Ressourcengruppe verwenden oder eine Ressourcengruppe mit dem Cmdlet New-AzResourceGroup erstellen. Wenn Sie eine Ressourcengruppe erstellen, geben Sie den Namen und den Speicherort dafür an.
Ein Tresor wird in einer Ressourcengruppe platziert. Erstellen Sie mit New-AzResourceGroup eine neue Ressourcengruppe, wenn noch keine vorhanden ist. In diesem Beispiel wird eine neue Ressourcengruppe in der Region „USA, Westen“ erstellt.
New-AzResourceGroup -Name "test-rg" -Location "West US"Verwenden Sie das Cmdlet New-AzRecoveryServicesVault zum Erstellen des Tresors. Geben Sie denselben Speicherort für den Tresor an, der für die Ressourcengruppe verwendet wurde.
New-AzRecoveryServicesVault -Name "testvault" -ResourceGroupName "test-rg" -Location "West US"Geben Sie den für den Tresorspeicher zu verwendenden Redundanztyp an.
- Sie können lokal redundanten Speicher, georedundanten Speicher oder zonenredundanten Speicher verwenden.
- Im folgenden Beispiel wird die Option
-BackupStorageRedundancyfür die Set-AzRecoveryServicesBackupProperty-cmd fürtestvaultaufGeoRedundantfestgelegt.
$vault1 = Get-AzRecoveryServicesVault -Name "testvault" Set-AzRecoveryServicesBackupProperties -Vault $vault1 -BackupStorageRedundancy GeoRedundant
Anzeigen von Tresoren in einem Abonnement
Wenn Sie alle Tresore des Abonnements anzeigen möchten, verwenden Sie Get-AzRecoveryServicesVault.
Get-AzRecoveryServicesVault
Die Ausgabe sieht in etwa wie folgt aus: Die zugeordnete Ressourcengruppe und der Speicherort werden angegeben.
Name : Contoso-vault
ID : /subscriptions/1234
Type : Microsoft.RecoveryServices/vaults
Location : WestUS
ResourceGroupName : Contoso-docs-rg
SubscriptionId : 1234-567f-8910-abc
Properties : Microsoft.Azure.Commands.RecoveryServices.ARSVaultProperties
Festlegen des Tresorkontexts
Speichern Sie das Tresorobjekt in einer Variablen, und legen Sie den Tresorkontext fest.
- Viele Azure Backup-Cmdlets erfordern das Recovery Services-Tresorobjekt als Eingabe. Daher ist es sinnvoll, das Tresorobjekt in einer Variablen zu speichern.
- Der Tresorkontext ist der Datentyp, der im Tresor geschützt wird. Legen Sie ihn mit Set-AzRecoveryServicesVaultContext fest. Der festgelegte Kontext gilt für alle nachfolgenden Cmdlets.
Im folgenden Beispiel wird der Tresorkontext für testvault festgelegt
Get-AzRecoveryServicesVault -Name "testvault" | Set-AzRecoveryServicesVaultContext
Abrufen der Tresor-ID
Es ist geplant, die Tresorkontexteinstellung gemäß den Azure PowerShell-Richtlinien als veraltet zu kennzeichnen. Stattdessen können Sie die Tresor-ID speichern oder abrufen und wie folgt an relevante Befehle übergeben:
$testVault = Get-AzRecoveryServicesVault -ResourceGroupName "Contoso-docs-rg" -Name "testvault"
$testVault.ID
Konfigurieren einer Sicherungsrichtlinie
Eine Sicherungsrichtlinie gibt den Zeitplan für Sicherungen an und legt fest, wie lange Wiederherstellungspunkte der Sicherung beibehalten werden sollen:
- Eine Sicherungsrichtlinie ist mindestens einer Aufbewahrungsrichtlinie zugeordnet. Eine Aufbewahrungsrichtlinie definiert, wie lange ein Wiederherstellungspunkt gespeichert werden soll, bevor er gelöscht wird.
- Zeigen Sie den Aufbewahrungszeitraum der Standardsicherungsrichtlinie mit Get-AzRecoveryServicesBackupRetentionPolicyObject an.
- Zeigen Sie den Zeitplan der Standardsicherungsrichtlinie mit Get-AzRecoveryServicesBackupSchedulePolicyObject an.
- Mit dem Cmdlet New-AzRecoveryServicesBackupProtectionPolicy erstellen Sie eine neue Sicherungsrichtlinie. Dazu geben Sie die Zeitplan- und Aufbewahrungsrichtlinienobjekte ein.
Eine Startzeit wird standardmäßig im Schedule Policy Object (Zeitplanrichtlinienobjekt) definiert. Verwenden Sie das folgende Beispiel, um die Startzeit in die gewünschte Startzeit zu ändern. Die gewünschte Startzeit sollte ebenfalls in UTC angegeben werden. Beim folgenden Beispiel wird vorausgesetzt, dass die gewünschte Startzeit für tägliche Sicherungen 01:00 Uhr UTC ist.
$schPol = Get-AzRecoveryServicesBackupSchedulePolicyObject -WorkloadType "MSSQL"
$UtcTime = (Get-Date -Date "2019-03-20 01:30:00Z").ToUniversalTime()
$schPol.FullBackupSchedulePolicy.ScheduleRunTimes[0] = $UtcTime
Wichtig
Sie können die Startzeit nur in 30-Minuten-Einheiten angeben. Im obigen Beispiel kann sie nur „01:00:00“ oder „02:30:00“ lauten. 01:15:00 kann nicht als Startzeit angegeben werden.
Im folgenden Beispiel werden die Zeitplanrichtlinie und die Aufbewahrungsrichtlinie in Variablen gespeichert. Anschließend werden diese Variablen als Parameter für eine neue Richtlinie (NewSQLPolicy) verwendet. Mit NewSQLPolicy wird täglich eine „vollständige“ Sicherung ausgeführt, diese 180 Tage lang aufbewahrt und alle 2 Stunden eine Protokollsicherung durchgeführt.
$schPol = Get-AzRecoveryServicesBackupSchedulePolicyObject -WorkloadType "MSSQL"
$retPol = Get-AzRecoveryServicesBackupRetentionPolicyObject -WorkloadType "MSSQL"
$NewSQLPolicy = New-AzRecoveryServicesBackupProtectionPolicy -Name "NewSQLPolicy" -WorkloadType "MSSQL" -RetentionPolicy $retPol -SchedulePolicy $schPol
Die Ausgabe sieht in etwa wie folgt aus:
Name WorkloadType BackupManagementType BackupTime Frequency IsDifferentialBackup IsLogBackupEnabled
Enabled
---- ------------ -------------------- ---------- --------- -------------------- ------------------
NewSQLPolicy MSSQL AzureWorkload 3/15/2019 01:30:00 AM Daily False True
Aktivieren der Sicherung
Registrieren des virtuellen SQL-Computers
Im Falle von Sicherungen virtueller Azure-Computer und Azure-Dateifreigaben kann der Backup-Dienst eine Verbindung mit diesen Azure Resource Manager-Ressourcen herstellen und die relevanten Details abrufen. Da es sich bei SQL um eine Anwendung auf einem virtuellen Azure-Computer handelt, muss der Backup-Dienst über die Berechtigung für den Zugriff auf die Anwendung und das Abrufen der erforderlichen Informationen verfügen. Dazu müssen Sie den virtuellen Azure-Computer, der die SQL-Anwendung enthält, bei einem Recovery Services-Tresor „registrieren“ . Nachdem Sie einen virtuellen SQL-Computer bei einem Tresor registriert haben, können Sie die SQL-Datenbanken nur in diesem Tresor schützen. Verwenden Sie zum Registrieren des virtuellen Computers das PowerShell-Cmdlet Register-AzRecoveryServicesBackupContainer.
$myVM = Get-AzVM -ResourceGroupName <VMRG Name> -Name <VMName>
Register-AzRecoveryServicesBackupContainer -ResourceId $myVM.ID -BackupManagementType AzureWorkload -WorkloadType MSSQL -VaultId $testVault.ID -Force
Der Befehl gibt einen „Sicherungscontainer“ dieser Ressource zurück, und der Status lautet „registriert“.
Hinweis
Wenn der Parameter „Force“ nicht angegeben wird, werden Sie mit einem Text vom Typ „Möchten Sie den Schutz für diesen Container deaktivieren?“ zur Bestätigung aufgefordert. Ignorieren Sie diesen Text, und bestätigen Sie mit „Ja“. Dies ist ein bekanntes Problem, und wir arbeiten gerade daran, den Text und die Anforderung für den Parameter „Force“ zu entfernen.
Abrufen von SQL-Datenbanken
Nach der Registrierung kann der Backup-Dienst alle verfügbaren SQL-Komponenten auf dem virtuellen Computer auflisten. Verwenden Sie zum Anzeigen aller SQL-Komponenten, die in diesem Tresor noch zu sichern sind, das PowerShell-Cmdlet Get-AzRecoveryServicesBackupProtectableItem.
Get-AzRecoveryServicesBackupProtectableItem -WorkloadType MSSQL -VaultId $testVault.ID
Die Ausgabe zeigt alle nicht geschützten SQL-Komponenten auf allen virtuellen SQL-Computern, die bei diesem Tresor registriert sind, mit dem Elementtyp und dem Servernamen an. Sie können weiter nach einem bestimmten virtuellen SQL-Computer filtern, indem Sie den Parameter „-Container“ übergeben oder die Kombination aus „Name“ und „ServerName“ zusammen mit dem Flag „ItemType“ verwenden, um zu einem eindeutigen SQL-Element zu gelangen.
$SQLDB = Get-AzRecoveryServicesBackupProtectableItem -workloadType MSSQL -ItemType SQLDataBase -VaultId $testVault.ID -Name "<Item Name>" -ServerName "<Server Name>"
Konfigurieren der Sicherung
Da nun die erforderliche SQL-Datenbank und die benötigte Richtlinie für deren Sicherung vorhanden sind, kann mit dem Cmdlet Enable-AzRecoveryServicesBackupProtection die Sicherung für diese SQL-Datenbank konfiguriert werden.
Enable-AzRecoveryServicesBackupProtection -ProtectableItem $SQLDB -Policy $NewSQLPolicy
Der Befehl wartet, bis die Sicherungskonfiguration abgeschlossen ist, und gibt die folgende Ausgabe zurück.
WorkloadName Operation Status StartTime EndTime JobID
------------ --------- ------ --------- ------- -----
master ConfigureBackup Completed 3/18/2019 6:00:21 PM 3/18/2019 6:01:35 PM 654e8aa2-4096-402b-b5a9-e5e71a496c4e
Abrufen neuer SQL-Datenbanken
Sobald der Computer registriert ist, ruft der Backup-Dienst die Details der dann verfügbaren Datenbanken ab. Wenn SQL-Datenbanken oder SQL-Instanzen dem registrierten Computer später hinzugefügt werden, müssen Sie den Sicherungsdienst manuell auslösen, damit eine neue „Abfrage“ zum erneuten Abrufen aller nicht geschützten Datenbanken (einschließlich der neu hinzugefügten) ausgeführt wird. Verwenden Sie zum Ausführen einer neuen Abfrage das PowerShell-Cmdlet Initialize-AzRecoveryServicesBackupItem auf dem virtuellen SQL-Computer. Der Befehl wartet, bis der Vorgang abgeschlossen ist. Verwenden Sie später das PowerShell-Cmdlet Get-AzRecoveryServicesBackupProtectableItem, um die Liste der neuesten nicht geschützten SQL-Komponenten abzurufen.
$SQLContainer = Get-AzRecoveryServicesBackupContainer -ContainerType AzureVMAppContainer -FriendlyName <VM name> -VaultId $testVault.ID
Initialize-AzRecoveryServicesBackupProtectableItem -Container $SQLContainer -WorkloadType MSSQL -VaultId $testVault.ID
Get-AzRecoveryServicesBackupProtectableItem -workloadType MSSQL -ItemType SQLDataBase -VaultId $testVault.ID
Nachdem die entsprechenden schützbaren Elemente abgerufen wurden, aktivieren Sie die Sicherungen wie im Abschnitt oben angegeben. Wenn neue Datenbanken nicht manuell erkannt werden sollen, können Sie sich auch für automatischen Schutz entscheiden, wie er weiter unten erläutert ist.
Aktivieren des automatischen Schutzes
Sie können die Sicherung so konfigurieren, dass alle zukünftig hinzugefügten Datenbanken mit einer bestimmten Richtlinie automatisch geschützt werden. Verwenden Sie zum Aktivieren des automatischen Schutzes das PowerShell-Cmdlet Enable-AzRecoveryServicesBackupAutoProtection.
Da die Anweisung das Sichern aller zukünftigen Datenbanken vorsieht, erfolgt der Vorgang auf der Ebene einer SQL-Instanz.
$SQLInstance = Get-AzRecoveryServicesBackupProtectableItem -workloadType MSSQL -ItemType SQLInstance -VaultId $testVault.ID -Name "<Protectable Item name>" -ServerName "<Server Name>"
Enable-AzRecoveryServicesBackupAutoProtection -InputItem $SQLInstance -BackupManagementType AzureWorkload -WorkloadType MSSQL -Policy $NewSQLPolicy -VaultId $testVault.ID
Sobald der beabsichtigte automatische Schutz festgelegt ist, wird die Anfrage an den Computer zum Abrufen neu hinzugefügter Datenbanken alle acht Stunden als geplante Hintergrundaufgabe ausgeführt.
Wiederherstellen von SQL-Datenbanken
Azure Backup kann auf virtuellen Azure-Computern ausgeführte SQL Server-Datenbanken wie folgt wiederherstellen:
- Wiederherstellung eines bestimmten Datums oder einer bestimmten Uhrzeit (sekundengenau) mithilfe von Transaktionsprotokollsicherungen. Azure Backup ermittelt automatisch die geeignete vollständige differenzielle Sicherung und die Kette von Protokollsicherungen, die für die Wiederherstellung Ihrer Daten basierend auf dem ausgewählten Zeitpunkt benötigt werden.
- Wiederherstellung einer bestimmten vollständigen oder differenziellen Sicherung, um die Daten eines bestimmten Wiederherstellungspunkts wiederherzustellen.
Überprüfen Sie vor dem Wiederherstellen von SQL-Datenbanken die hier genannten Voraussetzungen.
Warnung
Aufgrund eines Sicherheitsproblems im Zusammenhang mit RBAC musste ein Breaking Change in den Wiederherstellungsbefehlen für SQL DB über PowerShell eingeführt werden. Führen Sie ein Upgrade auf Az 6.0.0 oder höher durch, damit die richtigen Wiederherstellungsbefehle über PowerShell übermittelt werden. Die neuesten PS-Befehle werden unten bereitgestellt.
Rufen Sie zunächst die jeweilige gesicherte SQL-Datenbank mit dem PowerShell-Cmdlet Get-AzRecoveryServicesBackupItem ab.
$bkpItem = Get-AzRecoveryServicesBackupItem -BackupManagementType AzureWorkload -WorkloadType MSSQL -Name "<backup item name>" -VaultId $testVault.ID
Abrufen der relevanten Wiederherstellungszeit
Wie oben beschrieben, können Sie die gesicherte SQL-Datenbank auf eine vollständige/differenzielle Kopie ODER auf einen Protokollzeitpunkt wiederherstellen.
Abrufen eindeutiger Wiederherstellungspunkte
Mit Get-AzRecoveryServicesBackupRecoveryPoint können Sie eindeutige (vollständige/differenzielle) Wiederherstellungspunkte für eine gesicherte SQL-Datenbank abrufen.
$startDate = (Get-Date).AddDays(-7).ToUniversalTime()
$endDate = (Get-Date).ToUniversalTime()
Get-AzRecoveryServicesBackupRecoveryPoint -Item $bkpItem -VaultId $testVault.ID -StartDate $startdate -EndDate $endDate
Die Ausgabe sieht in etwa wie das folgende Beispiel aus:
RecoveryPointId RecoveryPointType RecoveryPointTime ItemName BackupManagemen
tType
--------------- ----------------- ----------------- -------- ---------------
6660368097802 Full 3/18/2019 8:09:35 PM MSSQLSERVER;model AzureWorkload
Verwenden Sie zum Abrufen des relevanten Wiederherstellungspunkts den Filter „RecoveryPointId“ oder einen Arrayfilter.
$FullRP = Get-AzRecoveryServicesBackupRecoveryPoint -Item $bkpItem -VaultId $testVault.ID -RecoveryPointId "6660368097802"
Abrufen eines Zeitpunkts als Wiederherstellungspunkt
Wenn Sie die Datenbank auf einen bestimmten Zeitpunkt wiederherstellen möchten, verwenden Sie dazu das PowerShell-Cmdlet Get-AzRecoveryServicesBackupRecoveryLogChain. Das Cmdlet gibt eine Liste mit Datumsangaben zurück, die Start- und Endzeiten einer ununterbrochenen, kontinuierlichen Protokollkette für das jeweilige SQL-Sicherungselement darstellen. Der gewünschte Zeitpunkt sollte innerhalb dieses Bereichs liegen.
Get-AzRecoveryServicesBackupRecoveryLogChain -Item $bkpItem -VaultId $testVault.ID
Die Ausgabe entspricht etwa folgendem Beispiel:
ItemName StartTime EndTime
-------- --------- -------
SQLDataBase;MSSQLSERVER;azu... 3/18/2019 8:09:35 PM 3/19/2019 12:08:32 PM
Die vorstehende Ausgabe bedeutet, dass Sie auf jeden beliebigen Zeitpunkt zwischen der angezeigten Start- und Endzeit wiederherstellen können. Die Zeitangaben sind in UTC. Erstellen Sie in PowerShell einen beliebigen Zeitpunkt innerhalb des oben gezeigten Bereichs.
Hinweis
Wenn ein Protokollzeitpunkt für die Wiederherstellung ausgewählt wird, müssen Sie keinen Startzeitpunkt angeben, d. h., die Datenbank wird aus der vollständigen Sicherung wiederhergestellt. Der Azure Backup-Dienst übernimmt die gesamte Wiederherstellungsplanung, d. h., welche vollständige Sicherung auszuwählen ist, welche Protokollsicherungen anzuwenden sind usw.
Bestimmen der Wiederherstellungskonfiguration
Bei der Wiederherstellung einer SQL-Datenbank werden die folgenden Wiederherstellungsszenarien unterstützt.
- Überschreiben der gesicherten SQL-Datenbank mit Daten von einem anderen Wiederherstellungspunkt – OriginalWorkloadRestore
- Wiederherstellen der SQL-Datenbank als eine neue Datenbank in derselben SQL-Instanz – AlternateWorkloadRestore
- Wiederherstellen der SQL-Datenbank als eine neue Datenbank in einer anderen SQL-Instanz auf einem anderen virtuellen SQL-Computer – AlternateWorkloadRestore
- Wiederherstellen der SQL-Datenbank als BAK-Dateien -RestoreAsFiles
Nach dem Abrufen des relevanten Wiederherstellungspunkts (eindeutig oder Protokollzeitpunkt) rufen Sie das Wiederherstellungskonfigurationsobjekt mit dem PowerShell-Cmdlet Get-AzRecoveryServicesBackupWorkloadRecoveryConfig entsprechend dem gewünschten Wiederherstellungsplan ab.
Wiederherstellen der ursprünglichen Workload
Um die gesicherte Datenbank mit Daten vom Wiederherstellungspunkt zu überschreiben, geben Sie einfach das richtige Flag und den relevanten Wiederherstellungspunkt an, wie es in den folgenden Beispielen gezeigt ist.
Wiederherstellen des ursprünglichen Zustands mit eindeutigem Wiederherstellungspunkt
$OverwriteWithFullConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -RecoveryPoint $FullRP -OriginalWorkloadRestore -VaultId $testVault.ID
Wiederherstellen des ursprünglichen Zustands mit Protokollzeitpunkt
$OverwriteWithLogConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -PointInTime $PointInTime -Item $bkpItem -OriginalWorkloadRestore -VaultId $testVault.ID
Wiederherstellen einer anderen Workload
Wichtig
Eine gesicherte SQL-Datenbank kann nur auf einem virtuellen Azure-Computer, der beim entsprechenden Tresor „registriert“ ist, als eine neue Datenbank in einer anderen SQL-Instanz wiederhergestellt werden.
Wie oben beschrieben, stellen Sie im Fall einer SQL-Zielinstanz auf einem anderen virtuellen Azure-Computer sicher, dass dieser beim entsprechenden Tresor registriert ist und die relevante SQL-Instanz als schützbares Element angezeigt wird. In diesem Dokument gehen wir davon aus, dass der SQLInstance-Zielname MSSQLSERVER sich auf einem anderen virtuellen Computer namens „Contoso2“ befindet.
$TargetContainer = Get-AzRecoveryServicesBackupContainer -ContainerType AzureVMAppContainer -Status Registered -VaultId $testVault.ID -FriendlyName "Contoso2"
$TargetInstance = Get-AzRecoveryServicesBackupProtectableItem -WorkloadType MSSQL -ItemType SQLInstance -Name "MSSQLSERVER" -ServerName "Contoso2" -VaultId $testVault.ID
Übergeben Sie dann einfach den relevanten Wiederherstellungspunkt, die SQL-Zielinstanz mit dem richtigen Flag, wie unten dargestellt, und den Zielcontainer, unter dem sich die SQL-Zielinstanz befindet.
Wiederherstellen eines anderen Zustands mit eindeutigem Wiederherstellungspunkt
$AnotherInstanceWithFullConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -RecoveryPoint $FullRP -TargetItem $TargetInstance -AlternateWorkloadRestore -VaultId $testVault.ID -TargetContainer $TargetContainer
Wiederherstellen eines anderen Zustands mit Protokollzeitpunkt
$AnotherInstanceWithLogConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -PointInTime $PointInTime -Item $bkpItem -TargetItem $TargetInstance -AlternateWorkloadRestore -VaultId $testVault.ID -TargetContainer $TargetContainer
Wiederherstellen als Dateien
Um die Sicherungsdaten als BAK-Dateien und nicht als Datenbank wiederherzustellen, wählen Sie die Option Als Dateien wiederherstellen aus. Die gesicherte SQL-Datenbank kann auf allen virtuellen Zielcomputern wiederhergestellt werden, die für diesen Tresor registriert sind.
$TargetContainer= Get-AzRecoveryServicesBackupContainer -ContainerType AzureVMAppContainer -FriendlyName "VM name" -VaultId $vaultID
Wiederherstellen als Dateien mit eindeutigem Wiederherstellungspunkt
$FileRestoreWithFullConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -RecoveryPoint $FullRP -TargetContainer $TargetContainer -RestoreAsFiles -FilePath "<>" -VaultId $testVault.ID
Wiederherstellen als Dateien mit Protokollzeitpunkt von letzter vollständiger Sicherung
$FileRestoreWithLogConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -PointInTime $PointInTime -TargetContainer $TargetContainer -RestoreAsFiles -FilePath "<>" -VaultId $testVault.ID
Wiederherstellen als Dateien mit Protokollzeitpunkt von einer angegebenen vollständigen Sicherung
Wenn Sie eine bestimmte vollständige Sicherung angeben möchten, die für die Wiederherstellung verwendet werden soll, verwenden Sie den folgenden Befehl:
$FileRestoreWithLogAndSpecificFullConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -PointInTime $PointInTime -FromFull $FullRP -TargetContainer $TargetContainer -RestoreAsFiles -FilePath "<>" -VaultId $testVault.ID
Das endgültige Konfigurationsobjekt für den Wiederherstellungspunkt, das mit dem PowerShell-Cmdlet Get-AzRecoveryServicesBackupWorkloadRecoveryConfig abgerufen wird, enthält alle relevanten Informationen für die Wiederherstellung und ähnelt der folgenden Abbildung.
TargetServer : <SQL server name>
TargetInstance : <Target Instance name>
RestoredDBName : <Target Instance name>/azurebackup1_restored_3_19_2019_1850
OverwriteWLIfpresent : No
NoRecoveryMode : Disabled
targetPhysicalPath : {azurebackup1, azurebackup1_log}
ContainerId : /Subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/testRG/providers/Microsoft.RecoveryServices/vaults/testVault/backupFabrics/Azure/protectionContainers/vmappcontainer;compute;computeRG;SQLVMName
SourceResourceId : /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/computeRG/VMAppContainer/SQLVMName
RestoreRequestType : Alternate WL Restore
RecoveryPoint : Microsoft.Azure.Commands.RecoveryServices.Backup.Cmdlets.Models.AzureWorkloadRecoveryPoint
PointInTime : 1/1/0001 12:00:00 AM
Sie können den wiederhergestellten Datenbanknamen sowie der Felder „OverwriteWLIfpresent“, „NoRecoveryMode“ und „TargetPhysicalPath“ bearbeiten. Rufen Sie weitere Details für die Zieldateipfade ab, wie es nachfolgend gezeigt ist.
$AnotherInstanceWithFullConfig.targetPhysicalPath
MappingType SourceLogicalName SourcePath TargetPath
----------- ----------------- ---------- ----------
Data azurebackup1 F:\Data\azurebackup1.mdf F:\Data\azurebackup1_1553001753.mdf
Log azurebackup1_log F:\Log\azurebackup1_log.ldf F:\Log\azurebackup1_log_1553001753.ldf
Legen Sie die relevanten PowerShell-Eigenschaften als Zeichenfolgenwerte wie unten gezeigt fest.
$AnotherInstanceWithFullConfig.OverwriteWLIfpresent = "Yes"
$AnotherInstanceWithFullConfig | fl
TargetServer : <SQL server name>
TargetInstance : <Target Instance name>
RestoredDBName : <Target Instance name>/azurebackup1_restored_3_19_2019_1850
OverwriteWLIfpresent : Yes
NoRecoveryMode : Disabled
targetPhysicalPath : {azurebackup1, azurebackup1_log}
ContainerId : /Subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/testRG/providers/Microsoft.RecoveryServices/vaults/testVault/backupFabrics/Azure/protectionContainers/vmappcontainer;compute;computeRG;SQLVMName
SourceResourceId : /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/computeRG/VMAppContainer/SQLVMName
RestoreRequestType : Alternate WL Restore
RecoveryPoint : Microsoft.Azure.Commands.RecoveryServices.Backup.Cmdlets.Models.AzureWorkloadRecoveryPoint
PointInTime : 1/1/0001 12:00:00 AM
Wichtig
Stellen Sie sicher, dass das endgültige Wiederherstellungskonfigurationsobjekt alle erforderlichen und richtigen Werte aufweist, da der Wiederherstellungsvorgang auf dem Konfigurationsobjekt basiert.
Hinweis
Wenn Sie nicht die gesamte Kette, sondern nur eine Teilmenge von Dateien wiederherstellen möchten, befolgen Sie die Schritte, die hier dokumentiert sind.
Alternative Workloadwiederherstellung in einem Tresor in der sekundären Region
Wichtig
Unterstützung für die Wiederherstellung sekundärer Regionen für SQL mit PowerShell steht ab Az 6.0.0 zur Verfügung.
Wenn Sie die regionsübergreifende Wiederherstellung aktiviert haben, werden die Wiederherstellungspunkte auch in die sekundäre gekoppelte Region repliziert. Anschließend können Sie diese Wiederherstellungspunkte abrufen und eine Wiederherstellung auf einem Computer auslösen, der in dieser gekoppelten Region vorhanden ist. Wie bei der normalen Wiederherstellung sollte der Zielcomputer beim Zieltresor in der sekundären Region registriert werden. Die folgende Abfolge von Schritten sollte den End-to-End-Prozess verdeutlichen.
- Abrufen der Sicherungselemente, die in die sekundäre Region repliziert werden
- Rufen Sie für ein solches Element die Wiederherstellungspunkte (eindeutig und/oder Protokolle) ab, die in die sekundäre Region repliziert werden.
- Wählen Sie dann einen Zielserver aus, der bei einem Tresor innerhalb der sekundären gekoppelten Region registriert ist.
- Lösen Sie die Wiederherstellung auf diesem Server aus, und verfolgen Sie sie mithilfe der JobId nach.
Abrufen von Sicherungselementen aus der sekundären Region
Rufen Sie alle SQL-Sicherungselemente aus der sekundären Region mit dem üblichen Befehl ab, aber mit einem zusätzlichen Parameter, um anzugeben, dass diese Elemente aus der sekundären Region abgerufen werden sollen.
$secondaryBkpItems = Get-AzRecoveryServicesBackupItem -BackupManagementType AzureWorkload -WorkloadType MSSQL -VaultId $testVault.ID -UseSecondaryRegion
Abrufen eindeutiger Wiederherstellungspunkte aus der sekundären Region
Rufen Sie mit Get-AzRecoveryServicesBackupRecoveryPoint eindeutige (vollständige/differenzielle) Wiederherstellungspunkte für eine sicherungsbasierte SQL-Datenbank ab, und fügen Sie einen Parameter hinzu, um anzugeben, dass es sich um Wiederherstellungspunkte handelt, die aus der sekundären Region abgerufen werden.
$startDate = (Get-Date).AddDays(-7).ToUniversalTime()
$endDate = (Get-Date).ToUniversalTime()
Get-AzRecoveryServicesBackupRecoveryPoint -Item $secondaryBkpItems[0] -VaultId $testVault.ID -StartDate $startdate -EndDate $endDate -UseSecondaryRegion
Die Ausgabe sieht in etwa wie das folgende Beispiel aus:
RecoveryPointId RecoveryPointType RecoveryPointTime ItemName BackupManagemen
tType
--------------- ----------------- ----------------- -------- ---------------
6660368097802 Full 3/18/2019 8:09:35 PM MSSQLSERVER;model AzureWorkload
Verwenden Sie zum Abrufen des relevanten Wiederherstellungspunkts den Filter „RecoveryPointId“ oder einen Arrayfilter.
$FullRPFromSec = Get-AzRecoveryServicesBackupRecoveryPoint -Item $secondaryBkpItems[0] -VaultId $testVault.ID -RecoveryPointId "6660368097802" -UseSecondaryRegion
Abrufen von Protokollwiederherstellungspunkten aus der sekundären Region
Verwenden Sie das PowerShell-Cmdlet Get-AzRecoveryServicesBackupRecoveryLogChain mit dem Parameter -UseSecondaryRegion, das die Start- und Endzeiten einer ununterbrochenen, kontinuierlichen Protokollkette für diesen SQL-Sicherungsartikel aus der sekundären Region zurückgibt. Der gewünschte Zeitpunkt sollte innerhalb dieses Bereichs liegen.
Get-AzRecoveryServicesBackupRecoveryLogChain -Item $secondaryBkpItems[0] -VaultId $testVault.ID -UseSecondaryRegion
Die Ausgabe entspricht etwa folgendem Beispiel:
ItemName StartTime EndTime
-------- --------- -------
SQLDataBase;MSSQLSERVER;azu... 3/18/2019 8:09:35 PM 3/19/2019 12:08:32 PM
Die vorstehende Ausgabe bedeutet, dass Sie auf jeden beliebigen Zeitpunkt zwischen der angezeigten Start- und Endzeit wiederherstellen können. Die Zeitangaben sind in UTC. Erstellen Sie in PowerShell einen beliebigen Zeitpunkt innerhalb des oben gezeigten Bereichs.
Abrufen des Zielservers aus der sekundären Region
In der sekundären Region benötigen wir einen Tresor und einen Zielserver, der bei diesem Tresor registriert ist. Sobald der Zielcontainer der sekundären Region und die SQL vorhanden sind, können wir die vorhandenen Cmdlets erneut verwenden, um eine Wiederherstellungsworkload-Konfiguration zu generieren. In diesem Dokument gehen wir davon aus, dass der VM-Name „secondaryVM“ und der Instanzname auf diesem virtuellen Computer „MSSQLInstance“ ist.
Zunächst rufen wir den relevanten Tresor in der sekundären Region und dann die registrierten Container in diesem Tresor ab.
$PairedRegionVault = Get-AzRecoveryServicesVault -ResourceGroupName SecondaryRG -Name PairedVault
$secContainer = Get-AzRecoveryServicesBackupContainer -ContainerType AzureVMAppContainer -Status Registered -VaultId $PairedRegionVault.ID -FriendlyName "secondaryVM"
Nachdem der registrierte Container ausgewählt wurde, rufen wir die SQL-Instanzen innerhalb des Containers ab, in dem die Datenbank wiederhergestellt werden soll. Hier wird davon ausgegangen, dass in „secondaryVM“ eine SQL-Instanz vorhanden ist, und wir rufen diese Instanz ab.
$secSQLInstance = Get-AzRecoveryServicesBackupProtectableItem -WorkloadType MSSQL -ItemType SQLInstance -VaultId $PairedRegionVault.ID -Container $secContainer
Vorbereiten der Wiederherstellungskonfiguration
Wie oben für die normale SQL-Wiederherstellung dokumentiert, kann derselbe Befehl erneut verwendet werden, um die relevante Wiederherstellungskonfiguration zu generieren.
Für vollständige Wiederherstellungen aus der sekundären Region
Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -RecoveryPoint $FullRPFromSec[0] -TargetItem $secSQLInstance -AlternateWorkloadRestore -VaultId $vault.ID -TargetContainer $secContainer
Für Protokollzeitpunktwiederherstellungen aus der sekundären Region
Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -PointInTime $PointInTime -Item $secondaryBkpItems[0] -TargetItem $secSQLInstance -AlternateWorkloadRestore -VaultId $vault.ID -TargetContainer $secContainer
Sobald die relevante Konfiguration für die Wiederherstellung der primären oder sekundären Region abgerufen wurde, kann derselbe Wiederherstellungsbefehl verwendet werden, um Wiederherstellungen auszulösen, und später mithilfe der jobIDs nachverfolgt werden.
Wiederherstellen mit relevanter Konfiguration
Nachdem das relevante Wiederherstellungskonfigurationsobjekt abgerufen und überprüft wurde, starten Sie den Wiederherstellungsvorgang mit dem PowerShell-Cmdlet Restore-AzRecoveryServicesBackupItem.
Restore-AzRecoveryServicesBackupItem -WLRecoveryConfig $AnotherInstanceWithLogConfig -VaultId $testVault.ID -RestoreToSecondaryRegion
Der Wiederherstellungsvorgang gibt einen nachzuverfolgenden Auftrag zurück.
WorkloadName Operation Status StartTime EndTime JobID
------------ --------- ------ --------- ------- -----
MSSQLSERVER/m... Restore InProgress 3/17/2019 10:02:45 AM 3274xg2b-e4fg-5952-89b4-8cb566gc1748
Verwalten von SQL-Sicherungen
Bedarfsgesteuerte Sicherung
Nachdem die Sicherung für eine Datenbank aktiviert wurde, können Sie mit dem PowerShell-Cmdlet Backup-AzRecoveryServicesBackupItem auch eine bedarfsgesteuerte Sicherung für die Datenbank auslösen. Im folgenden Beispiel wird eine vollständige Kopiesicherung für eine SQL-Datenbank mit aktivierter Komprimierung ausgelöst, und die vollständige Kopiesicherung soll 60 Tage lang aufbewahrt werden.
Hinweis
Vollständige Kopiesicherungen sind ideal für die langfristige Aufbewahrung, da sie keine Abhängigkeiten von anderen Sicherungstypen wie Protokollen aufweisen. Eine „vollständige“ Sicherung wird als übergeordnetes Element nachfolgender Protokollsicherungen behandelt, und somit ist ihre Aufbewahrung an die Protokollaufbewahrung in der Richtlinie gebunden. Daher wird die vom Kunden angegebene Ablaufzeit für vollständige Kopiesicherungen und nicht für „vollständige“ Sicherungen berücksichtigt. Die Aufbewahrungszeit für eine vollständige Sicherung wird automatisch auf 45 Tage ab dem aktuellen Zeitpunkt festgelegt. Dies ist auch hier dokumentiert.
$bkpItem = Get-AzRecoveryServicesBackupItem -BackupManagementType AzureWorkload -WorkloadType MSSQL -Name "<backup item name>" -VaultId $testVault.ID
$endDate = (Get-Date).AddDays(45).ToUniversalTime()
Backup-AzRecoveryServicesBackupItem -Item $bkpItem -BackupType CopyOnlyFull -EnableCompression -VaultId $testVault.ID -ExpiryDateTimeUTC $endDate
Der Befehl zur bedarfsgesteuerten Sicherung gibt einen nachzuverfolgenden Auftrag zurück.
WorkloadName Operation Status StartTime EndTime JobID
------------ --------- ------ --------- ------- -----
MSSQLSERVER/m... Backup InProgress 3/18/2019 8:41:27 PM 2516bb1a-d3ef-4841-97a3-9ba455fb0637
Wenn die Ausgabe verloren geht oder Sie die relevante Auftrags-ID abrufen möchten, rufen Sie die Liste der Aufträge aus dem Azure Backup-Dienst ab, und verfolgen Sie dann die Liste und ihre Details.
Ändern der Richtlinie für Sicherungselemente
Sie können die Richtlinie des gesicherten Elements von Policy1 in Policy2 ändern. Zum Wechseln der Richtlinien für ein gesichertes Element rufen Sie die entsprechende Richtlinie und das Sicherungselement ab, und verwenden Sie den Befehl Enable-AzRecoveryServices mit dem Sicherungselement als Parameter.
$TargetPol1 = Get-AzRecoveryServicesBackupProtectionPolicy -Name <PolicyName>
$anotherBkpItem = Get-AzRecoveryServicesBackupItem -WorkloadType MSSQL -BackupManagementType AzureWorkload -Name "<BackupItemName>"
Enable-AzRecoveryServicesBackupProtection -Item $anotherBkpItem -Policy $TargetPol1
Der Befehl wartet, bis die Sicherungskonfiguration abgeschlossen ist, und gibt die folgende Ausgabe zurück.
WorkloadName Operation Status StartTime EndTime JobID
------------ --------- ------ --------- ------- -----
master ConfigureBackup Completed 3/18/2019 8:00:21 PM 3/18/2019 8:02:16 PM 654e8aa2-4096-402b-b5a9-e5e71a496c4e
Bearbeiten einer vorhandenen Sicherungsrichtlinie
Zum Bearbeiten einer vorhandenen Richtlinie verwenden Sie den Befehl Set-AzRecoveryServicesBackupProtectionPolicy.
Set-AzRecoveryServicesBackupProtectionPolicy -Policy $Pol -SchedulePolicy $SchPol -RetentionPolicy $RetPol
Überprüfen Sie die Sicherungsaufträge nach einiger Zeit, um eventuelle Fehler zu zu entdecken. Wenn es Probleme gibt, müssen Sie sie beheben. Führen Sie dann den Befehl „Richtlinie bearbeiten“ mit dem Parameter FixForInconsistentItems erneut aus, um die Bearbeitung der Richtlinie für alle Sicherungsobjekte, für die der Vorgang zuvor fehlgeschlagen ist, erneut zu versuchen.
Set-AzRecoveryServicesBackupProtectionPolicy -Policy $Pol -FixForInconsistentItems
Erneutes Registrieren von virtuellen SQL-Computern
Warnung
Lesen Sie vor dem Versuch einer erneuten Registrierung unbedingt dieses Dokument, um die Symptome und Ursachen von Fehlern zu verstehen.
Um die erneute Registrierung des virtuellen SQL-Computers auszulösen, rufen Sie den relevanten Sicherungscontainer ab, und übergeben Sie ihn an das Cmdlet „Register“.
$SQLContainer = Get-AzRecoveryServicesBackupContainer -ContainerType AzureVMAppContainer -FriendlyName <VM name> -VaultId $testVault.ID
Register-AzRecoveryServicesBackupContainer -Container $SQLContainer -BackupManagementType AzureWorkload -WorkloadType MSSQL -VaultId $testVault.ID
Schutz beenden
Beibehalten von Daten
Wenn Sie den Schutz verhindern möchten, können Sie dafür das PowerShell-Cmdlet Disable-AzRecoveryServicesBackupProtection verwenden. Dadurch werden die geplanten Sicherungen beendet, doch werden die bis zu diesem Zeitpunkt gesicherten Daten dauerhaft beibehalten.
$bkpItem = Get-AzRecoveryServicesBackupItem -BackupManagementType AzureWorkload -WorkloadType MSSQL -Name "<backup item name>" -VaultId $testVault.ID
Disable-AzRecoveryServicesBackupProtection -Item $bkpItem -VaultId $testVault.ID
Löschen von Sicherungsdaten
Um die gespeicherten Sicherungsdaten im Tresor vollständig zu entfernen, fügen Sie einfach das Flag/den Switch „-RemoveRecoveryPoints“ zum Befehl „Disable“ hinzu.
Disable-AzRecoveryServicesBackupProtection -Item $bkpItem -VaultId $testVault.ID -RemoveRecoveryPoints
Deaktivieren des automatischen Schutzes
Wenn der automatische Schutz für eine SQL-Instanz konfiguriert wurde, können Sie ihn mit dem PowerShell-Cmdlet Disable-AzRecoveryServicesBackupAutoProtection deaktivieren.
Suchen Sie die Instanzen, in denen der automatische Schutz mithilfe des folgenden PowerShell-Befehls aktiviert ist.
Get-AzRecoveryServicesBackupProtectableItem -WorkloadType MSSQL -VaultId $testVault.ID | Where-Object {$_.IsAutoProtected -eq $true}
Wählen Sie dann den relevanten schützbaren Elementnamen und Servernamen aus der Ausgabe aus und deaktivieren Sie den automatischen Schutz für diese Instanzen.
$SQLInstance = Get-AzRecoveryServicesBackupProtectableItem -workloadType MSSQL -ItemType SQLInstance -VaultId $testVault.ID -Name "<Protectable Item name>" -ServerName "<Server Name>"
Disable-AzRecoveryServicesBackupAutoProtection -InputItem $SQLInstance -BackupManagementType AzureWorkload -WorkloadType MSSQL -VaultId $testVault.ID
Aufheben der Registrierung des virtuellen SQL-Computers
Wenn alle Datenbanken eines SQL-Servers nicht mehr geschützt sind und es keine Sicherungsdaten gibt, können Sie die Registrierung des virtuellen SQL-Computers bei diesem Tresor aufheben. Erst dann können Sie Datenbanken in einem anderen Tresor schützen. Mit dem PowerShell-Cmdlet Unregister-AzRecoveryServicesBackupContainer können Sie die Registrierung des virtuellen SQL-Computers aufheben.
$SQLContainer = Get-AzRecoveryServicesBackupContainer -ContainerType AzureVMAppContainer -FriendlyName <VM name> -VaultId $testVault.ID
Unregister-AzRecoveryServicesBackupContainer -Container $SQLContainer -VaultId $testVault.ID
Nachverfolgen von Azure Backup-Aufträgen
Sie müssen beachten, dass Azure Backup nur vom Benutzer ausgelöste Aufträge in der SQL-Sicherung nachverfolgt. Geplante Sicherungen (einschließlich Protokollsicherungen) werden im Portal oder in PowerShell nicht angezeigt. Wenn jedoch Fehler bei geplanten Aufträgen auftreten, wird eine Sicherungswarnung generiert und im Portal angezeigt. Verwenden Sie Azure Monitor zum Nachverfolgen aller geplanten Aufträge und anderer relevanter Informationen.
Benutzer können bedarfsgesteuerte bzw. vom Benutzer ausgelöste Vorgänge anhand der Auftrags-ID nachverfolgen, die in der Ausgabe asynchroner Aufträge (z. B. einer Sicherung) zurückgegeben ist. Mit dem PowerShell-Cmdlet Get-AzRecoveryServicesBackupJobDetail können Sie einen Auftrag und seine Details nachverfolgen.
Get-AzRecoveryServicesBackupJobDetails -JobId 2516bb1a-d3ef-4841-97a3-9ba455fb0637 -VaultId $testVault.ID
Zum Abrufen der Liste von bedarfsgesteuerten Aufträgen und deren Status aus dem Azure Backup-Dienst verwenden Sie das PowerShell-Cmdlet Get-AzRecoveryServicesBackupJob. Im folgenden Beispiel werden alle in Bearbeitung befindlichen SQL-Aufträge zurückgegeben.
Get-AzRecoveryServicesBackupJob -Status InProgress -BackupManagementType AzureWorkload
Zum Abbrechen eines Auftrags in Bearbeitung verwenden Sie das PowerShell-Cmdlet Stop-AzRecoveryServicesBackupJob.
Verwalten von SQL-AlwaysOn-Verfügbarkeitsgruppen
Stellen Sie im Fall von SQL-AlwaysOn-Verfügbarkeitsgruppen sicher, dass alle Knoten der Verfügbarkeitsgruppe registriert werden. Nach der Registrierung aller Knoten wird unter den schützbaren Elementen ein SQL-Verfügbarkeitsgruppenobjekt logisch erstellt. Die Datenbanken unter der SQL-Verfügbarkeitsgruppe werden als „SQLDatabase“ aufgeführt. Die Knoten werden als eigenständige Instanzen angezeigt, und die darunter befindlichen SQL-Standarddatenbanken werden ebenfalls als SQL-Datenbanken aufgeführt.
Angenommen beispielsweise, eine SQL-Verfügbarkeitsgruppe hat zwei Knoten (sql-server-0 und sql-server-1) und eine SQL-Verfügbarkeitsgruppendatenbank. Wenn Sie nach der Registrierung dieser beiden Knoten die schützbaren Elemente auflisten, sind die folgenden Komponenten enthalten:
- Ein SQL-Verfügbarkeitsgruppenobjekt – Typ des schützbaren Elements ist „SQLAvailabilityGroup“
- Eine SQL-Verfügbarkeitsgruppendatenbank – Typ des schützbaren Elements ist „SQLDatabase“
- sql-server-0 – Typ des schützbaren Elements ist „SQLInstance“
- sql-server-1 – Typ des schützbaren Elements ist „SQLInstance“
- Alle SQL-Standarddatenbanken (Master, Modell, MSDB) unter „sql-server-0“ – Typ des schützbaren Elements ist „SQLDatabase“
- Alle SQL-Standarddatenbanken (Master, Modell, MSDB) unter „sql-server-1“ – Typ des schützbaren Elements ist „SQLDatabase“
Beim Auflisten von Sicherungscontainern werden auch „sql-server-0“ und „sql-server-1“ als „AzureVMAppContainer“ aufgeführt.
Rufen Sie einfach die entsprechende Datenbank ab, um die Sicherung zu aktivieren. Die PowerShell-Cmdlets für die bedarfsgesteuerte Sicherung und Wiederherstellung sind identisch.
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