Freigeben über


Wiederherstellen von SQL-Datenbanken in einer Azure-VM über die Azure CLI

Die Azure CLI dient zum Erstellen und Verwalten von Azure-Ressourcen über die Befehlszeile oder mit Skripts. In diesem Artikel wird beschrieben, wie Sie mit der Azure CLI eine gesicherte SQL-Datenbank auf einer Azure-VM wiederherstellen. Sie können diese Schritte auch im Azure-Portal ausführen.

Verwenden Sie Azure Cloud Shell, um die CLI-Befehle auszuführen.

Dieser Artikel setzt voraus, dass Sie eine auf einer Azure-VM ausgeführte SQL-Datenbank haben, die mit Azure Backup gesichert wurde. Falls Sie die Anleitung unter Sichern einer SQL-Datenbank in Azure mit der CLI befolgt haben, um Ihre SQL-Datenbank zu sichern, nutzen Sie die folgenden Ressourcen:

  • Eine Ressourcengruppe namens SQLResourceGroup.
  • Ein Tresor namens SQLVault.
  • Ein geschützter Container namens VMAppContainer;Compute;SQLResourceGroup;testSQLVM.
  • Eine gesicherte Datenbank/ein gesichertes Element namens sqldatabase;mssqlserver;master.
  • Ressourcen in der Region westus.

Hinweis

Weitere Informationen zu den unterstützten Konfigurationen und Szenarien finden Sie in der Supportmatrix für SQL-Backups.

Anzeigen von Wiederherstellungspunkten für eine gesicherte Datenbank

Um die Liste aller Wiederherstellungspunkte für eine Datenbank anzuzeigen, verwenden Sie den Befehl az backup recoverypoint list wie folgt:

az backup recoverypoint list --resource-group SQLResourceGroup \
    --vault-name SQLVault \
    --container-name VMAppContainer;Compute;SQLResourceGroup;testSQLVM \
    --item-name sqldatabase;mssqlserver;master \
   --output table

Die Liste der Wiederherstellungspunkte wird wie folgt angezeigt:

Name                      Time                               BackupManagementType   Item Name               		RecoveryPointType
-------------------       ---------------------------------  ---------------------  ----------------------  		------------------
7660777527047692711       2019-12-10T04:00:32.346000+00:00   AzureWorkload          sqldatabase;mssqlserver;master  Full
7896624824685666836       2019-12-15T10:33:32.346000+00:00   AzureWorkload          sqldatabase;mssqlserver;master  Differential
DefaultRangeRecoveryPoint                                    AzureWorkload          sqldatabase;mssqlserver;master  Log

Die obige Liste enthält drei Wiederherstellungspunkte: jeweils einen für die vollständige, differenzielle und Protokollsicherung.

Hinweis

Sie können auch die Start- und Endpunkte für alle ununterbrochenen Protokollsicherungsketten anzeigen, indem Sie dem Befehl az backup recoverypoint show-log-chain ausführen.

Voraussetzungen für die Wiederherstellung einer Datenbank

Stellen Sie vor dem Wiederherstellen einer Datenbank sicher, dass die folgenden Voraussetzungen erfüllt sind:

  • Sie können die Datenbank nur in einer SQL-Instanz wiederherstellen, die sich in derselben Region befindet.
  • Die Zielinstanz muss beim gleichen Tresor wie die Quelle registriert sein.

Wiederherstellen einer Datenbank

Azure Backup kann auf Azure-VMs ausgeführte SQL-Datenbanken wie folgt wiederherstellen:

  • Wiederherstellung eines bestimmten Datums oder einer bestimmten Uhrzeit (sekundengenau) mithilfe von Protokollsicherungen. Azure Backup ermittelt automatisch die geeigneten vollständige differenziellen Sicherungen 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.

Führen Sie zum Wiederherstellen einer Datenbank den Befehl az restore restore-azurewl aus. Hierfür ist als eine der Eingaben ein Objekt für die Wiederherstellungskonfiguration erforderlich. Sie können dieses Objekt mit dem Befehl az backup recoveryconfig show generieren. Das Objekt für die Wiederherstellungskonfiguration enthält alle Details zur Durchführung einer Wiederherstellung. Eines davon ist der Wiederherstellungsmodus: OriginalWorkloadRestore oder AlternateWorkloadRestore.

Hinweis

OriginalWorkloadRestore: Die Daten werden in der SQL-Instanz mit der ursprüngliche Quelle wiederhergestellt. Bei dieser Option wird die ursprüngliche Datenbank überschrieben. AlternateWorkloadRestore: Die Datenbank wird an einem alternativen Speicherort wiederhergestellt, und die ursprüngliche Quelldatenbank bleibt erhalten.

Wiederherstellen an einem alternativen Speicherort

Verwenden Sie AlternateWorkloadRestore als Wiederherstellungsmodus, wenn Sie eine Datenbank an einem anderen Speicherort wiederherstellen möchten. Anschließend müssen Sie den Wiederherstellungspunkt auswählen. Dies kann entweder ein früherer Zeitpunkt oder einer der vorherigen Wiederherstellungspunkte sein.

Fahren wir mit der Wiederherstellung eines vorherigen Wiederherstellungspunkts fort. Zeigen Sie die Liste mit den Wiederherstellungspunkten für die Datenbank an, und wählen Sie den Wiederherstellungspunkt aus. Hier wählen wir den Wiederherstellungspunkt mit dem Namen 7660777527047692711.

Unter Verwendung des obigen Wiederherstellungspunktnamens und des Wiederherstellungsmodus erstellen Sie mit dem Befehl az backup recoveryconfig show das Objekt für die Wiederherstellungskonfiguration. Überprüfen Sie die restlichen Parameter in diesem Befehl:

  • --target-item-name: der für die wiederhergestellte Datenbank zu verwendende Name. In diesem Szenario haben wir den Namen restored_database genutzt.
  • --target-server-name: der Name einer SQL Server-Instanz, die erfolgreich für einen Recovery Services-Tresor registriert wurde und sich in derselben Region wie die wiederherzustellende Datenbank befindet. Hier stellen Sie die Datenbank in derselben SQL Server-Instanz wieder her, die Sie geschützt haben und testSQLVM heißt.
  • --target-server-type: Für die Wiederherstellung von SQL-Datenbanken müssen Sie SQLInstance verwenden.

az backup recoveryconfig show --resource-group SQLResourceGroup \
    --vault-name SQLVault \
    --container-name VMAppContainer;Compute;SQLResourceGroup;testSQLVM \
    --item-name SQLDataBase;mssqlserver;master \
    --restore-mode AlternateWorkloadRestore \
    --rp-name 7660777527047692711 \
    --target-item-name restored_database \
    --target-server-name testSQLVM \
    --target-server-type SQLInstance \
    --workload-type SQLDataBase \
    --output json

Die Antwort auf die obige Abfrage ist ein Wiederherstellungskonfigurationsobjekt, das wie folgt aussieht:

{
  "container_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.RecoveryServices/vaults/SQLVault/backupFabrics/Azure/protectionContainers/vmappcontainer;compute;SQLResourceGroup;testSQLVM",
  "container_uri": "VMAppContainer;compute;SQLResourceGroup;testSQLVM",
  "database_name": "MSSQLSERVER/restored_database",
  "filepath": null,
  "item_type": "SQL",
  "item_uri": "SQLDataBase;mssqlserver;master",
  "log_point_in_time": null,
  "recovery_mode": null,
  "recovery_point_id": "7660777527047692711",
  "restore_mode": "AlternateLocation",
  "source_resource_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.Compute/virtualMachines/testSQLVM",
  "workload_type": "SQLDataBase",
  "alternate_directory_paths": []
}

Führen Sie nun zum Wiederherstellen der Datenbank den Befehl az restore restore-azurewl aus. Für diesen Befehl geben wir die obige JSON-Ausgabe ein, die in einer Datei mit dem Namen recoveryconfig.json gespeichert wurde.

az backup restore restore-azurewl --resource-group SQLResourceGroup \
    --vault-name SQLVault \
    --recovery-config recoveryconfig.json \
    --output table

Die Ausgabe sieht wie folgt aus:

Name                                  Operation    Status      Item Name                          Backup Management Type    Start Time UTC                    Duration
------------------------------------  -----------  ----------  ---------------------------------  ------------------------  --------------------------------  --------------
be7ea4a4-0752-4763-8570-a306b0a0106f  Restore      InProgress  master [testSQLVM]  				  AzureWorkload             2022-06-21T03:51:06.898981+00:00  0:00:05.652967

Die Antwort liefert Ihnen den Jobnamen. Dieser Auftragsname kann zum Nachverfolgen des Auftragsstatus mit dem Befehl az backup job show verwendet werden.

Wiederherstellen und Überschreiben

Verwenden Sie OrignialWorkloadRestore als Wiederherstellungsmodus für die Wiederherstellung am ursprünglichen Speicherort. Anschließend müssen Sie den Wiederherstellungspunkt auswählen. Dies kann ein früherer Zeitpunkt oder einer der vorherigen Wiederherstellungspunkte sein.

Als Beispiel wählen wir den vorherigen Zeitpunkt 28-11-2019-09:53:00 für die Wiederherstellung. Sie können diesen Wiederherstellungspunkt in den folgenden Formaten angeben: tt-mm-jjjj, „tt-mm-jjjj-hh:mm:ss. Verwenden Sie den Befehl az backup recoverypoint show-log-chain, um einen gültigen Zeitpunkt für die Wiederherstellung auszuwählen. Hiermit werden die Intervalle ununterbrochener Protokollkettensicherungen aufgelistet.

az backup recoveryconfig show --resource-group SQLResourceGroup \
    --vault-name SQLVault \
    --container-name VMAppContainer;Compute;SQLResourceGroup;testSQLVM \
    --item-name sqldatabase;mssqlserver;master \
    --restore-mode OriginalWorkloadRestore \
    --log-point-in-time 20-06-2022-09:02:41 \
    --output json

Die Antwort auf die obige Abfrage ist ein Wiederherstellungskonfigurationsobjekt, das wie folgt aussieht:

{
  "alternate_directory_paths": null,
  "container_id": null,
  "container_uri": "VMAppContainer;compute;petronasinternaltest;sqlserver-11",
  "database_name": null,
  "filepath": null,
  "item_type": "SQL",
  "item_uri": "SQLDataBase;mssqlserver;msdb",
  "log_point_in_time": "20-06-2022-09:02:41",
  "recovery_mode": null,
  "recovery_point_id": "DefaultRangeRecoveryPoint",
  "restore_mode": "OriginalLocation",
  "source_resource_id": "/subscriptions/62b829ee-7936-40c9-a1c9-47a93f9f3965/resourceGroups/petronasinternaltest/providers/Microsoft.Compute/virtualMachines/sqlserver-11",
  "workload_type": "SQLDataBase"
}

Führen Sie nun zum Wiederherstellen der Datenbank den Befehl az restore restore-azurewl aus. Für diesen Befehl geben wir die obige JSON-Ausgabe ein, die in einer Datei mit dem Namen recoveryconfig.json gespeichert wurde.

az backup restore restore-azurewl --resource-group sqlResourceGroup \
    --vault-name sqlVault \
    --recovery-config recoveryconfig.json \
    --output table

Die Ausgabe sieht wie folgt aus:

Name                                  Operation    Status      Item Name                        Backup Management Type    Start Time UTC                    Duration
------------------------------------  -----------  ----------  -------------------------------  ------------------------  --------------------------------  --------------
1730ec49-166a-4bfd-99d5-93027c2d8480  Restore      InProgress  master [testSQLVM]  				AzureWorkload             2022-06-21T04:04:11.161411+00:00  0:00:03.118076

Die Antwort liefert Ihnen den Jobnamen. Dieser Auftragsname kann zum Nachverfolgen des Auftragsstatus mit dem Befehl az backup job show verwendet werden.

Wiederherstellung in einer sekundären Region

Um eine Datenbank in der sekundären Region wiederherzustellen, geben Sie in der Wiederherstellungskonfiguration einen Zieldatenspeicher und einen Server in der sekundären Region an.

az backup recoveryconfig show --resource-group SQLResourceGroup \
    --vault-name SQLVault \
    --container-name VMAppContainer;compute;SQLResourceGroup;testSQLVM \
    --item-name sqldatabase;mssqlserver;master \
    --restore-mode AlternateWorkloadRestore \
    --from-full-rp-name 293170069256531 \
    --rp-name 293170069256531 \
    --target-server-name targetSQLServer \
    --target-container-name VMAppContainer;compute;SQLResourceGroup;targetSQLServer \
    --target-item-name testdb_restore_1 \
    --target-server-type SQLInstance \
    --workload-type SQLDataBase \
    --target-resource-group SQLResourceGroup \
    --target-vault-name targetVault \
    --backup-management-type AzureWorkload

Die Antwort ist ein Objekt für die Wiederherstellungskonfiguration, das wie folgt angezeigt wird:

 {
  "container_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.RecoveryServices/vaults/targetVault/backupFabrics/Azure/protectionContainers/vmappcontainer;compute;SQLResourceGroup;targetSQLServer",
  "container_uri": "VMAppContainer;compute;SQLResourceGroup;testSQLVM",
  "database_name": "MSSQLSERVER/sqldatabase;mssqlserver;testdb_restore_1",
  "filepath": null,
  "item_type": "SQL",
  "item_uri": "SQLDataBase;mssqlserver;master",
  "log_point_in_time": null,
  "recovery_mode": null,
  "recovery_point_id": "932606668166874635",
  "restore_mode": "AlternateLocation",
  "source_resource_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.Compute/virtualMachines/testSQLVM",
  "workload_type": "SQLDataBase",
  "alternate_directory_paths": [],
}

Verwenden Sie diese Wiederherstellungskonfiguration im Befehl az restore restore-azurewl. Wählen Sie das Kennzeichen --use-secondary-region, um die Datenbank in der sekundären Region wiederherzustellen.

az backup restore restore-azurewl --resource-group SQLResourceGroup \
    --vault-name testSQLVault \
    --recovery-config recoveryconfig.json \
    --use-secondary-region \
    --output table

Die Ausgabe sieht wie folgt aus:

Name                                  Operation           Status      Item Name                  Backup Management Type    Start Time UTC                    Duration
------------------------------------  ------------------  ----------  -------------------------  ------------------------  --------------------------------  --------------
0d863259-b0fb-4935-8736-802c6667200b  CrossRegionRestore  InProgress  master [testSQLVM] 		 AzureWorkload             2022-06-21T08:29:24.919138+00:00  0:00:12.372421

Hinweis

Das RPO für die Verfügbarkeit der Sicherungsdaten in der sekundären Region beträgt 12 Stunden. Wenn Sie CRR aktivieren, beträgt das RPO für die sekundäre Region daher 12 Stunden + Protokollhäufigkeitsdauer (die auf mindestens 15 Minuten festgelegt werden kann).

Wiederherstellen als Dateien

Um die Sicherungsdaten als Dateien anstatt als Datenbank wiederherzustellen, wählen wir als Wiederherstellungsmodus RestoreAsFiles. Wählen Sie anschließend den Wiederherstellungspunkt. Dies kann entweder ein früherer Zeitpunkt oder einer der vorherigen Wiederherstellungspunkte sein. Nachdem die Dateien in einem angegebenen Pfad ausgegeben wurden, können Sie diese Dateien auf jeden Computer verschieben, auf dem sie als Datenbank wiederhergestellt werden sollen. Da Sie diese Dateien auf einen beliebigen Computer verschieben können, können Sie nun die Daten über Abonnements und Regionen hinweg wiederherstellen.

Hier wählen Sie den vorherigen Zeitpunkt 28-11-2019-09:53:00 für die Wiederherstellung und den Speicherort für Sicherungsdateikopien als /home/sql/restoreasfiles in derselben SQL Server-Instanz aus. Sie können diesen Wiederherstellungspunkt in einem der folgenden Formate angeben: tt-mm-jjjj oder tt-mm-jjjj-hh:mm:ss. Verwenden Sie den Befehl az backup recoverypoint show-log-chain, um einen gültigen Zeitpunkt für die Wiederherstellung auszuwählen. Hiermit werden die Intervalle ununterbrochener Protokollkettensicherungen aufgelistet.

Unter Verwendung des obigen Wiederherstellungspunktnamens und des Wiederherstellungsmodus erstellen Sie mit dem Befehl az backup recoveryconfig show das Objekt für die Wiederherstellungskonfiguration. Überprüfen Sie nacheinander die restlichen Parameter in diesem Befehl:

  • --target-container-name: der Name einer SQL Server-Instanz, die erfolgreich für einen Recovery Services-Tresor registriert wurde und sich in derselben Region wie die wiederherzustellende Datenbank befindet. Lassen Sie uns die Datenbank als Dateien in derselben SQL Server-Instanz wiederherstellen, die Sie geschützt haben und hxehost heißt.
  • --rp-name: Für eine Zeitpunktwiederherstellung lautet der Wiederherstellungspunktname DefaultRangeRecoveryPoint.
az backup recoveryconfig show --resource-group SQLResourceGroup \
    --vault-name SQLVault \
    --container-name VMAppContainer;Compute;SQLResourceGroup;testSQLVM \
    --item-name sqldatabase;mssqlserver;master \
    --restore-mode RestoreAsFiles \
    --rp-name 932606668166874635 \
    --target-container-name VMAppContainer;Compute;SQLResourceGroup;testSQLVM \
    --filepath /sql/restoreasfiles \
    --output json

Die Antwort auf die obige Abfrage ist ein Objekt für die Wiederherstellungskonfiguration, das wie folgt aussieht:

{
  "alternate_directory_paths": null,
  "container_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.RecoveryServices/vaults/SQLVault/backupFabrics/Azure/protectionContainers/VMAppContainer;Compute;SQLResourceGroup;testSQLVM",
  "container_uri": "VMAppContainer;compute;SQLResourceGroup;testSQLVM",
  "database_name": null,
  "filepath": "/sql/restoreasfiles",
  "item_type": "SQL",
  "item_uri": "SQLDataBase;mssqlserver;master",
  "log_point_in_time": null,
  "recovery_mode": "FileRecovery",
  "recovery_point_id": "932606668166874635",
  "restore_mode": "AlternateLocation",
  "source_resource_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.Compute/virtualMachines/testSQLVM",
  "workload_type": "SQLDataBase"
}

Führen Sie nun zum Wiederherstellen der Datenbank als Dateien den Befehl az restore restore-azurewl aus. Für diesen Befehl geben wir die obige JSON-Ausgabe ein, die in einer Datei mit dem Namen recoveryconfig.json gespeichert wurde.

az backup restore restore-azurewl --resource-group SQLResourceGroup \
    --vault-name SQLVault \
    --restore-config recoveryconfig.json \
    --output json

Die Ausgabe sieht wie folgt aus:

{
  "eTag": null,
  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.RecoveryServices/vaults/SQLVault/backupJobs/e9cd9e73-e3a3-425a-86a9-8dd1c500ff56",
  "location": null,
  "name": "e9cd9e73-e3a3-425a-86a9-8dd1c500ff56",
  "properties": {
    "actionsInfo": [
      "1"
    ],
    "activityId": "9e7c8ee4-f1ef-11ec-8a2c-3c52826c1a9a",
    "backupManagementType": "AzureWorkload",
    "duration": "0:00:04.304322",
    "endTime": null,
    "entityFriendlyName": "master [testSQLVM]",
    "errorDetails": > [!NOTE]
> Information the user should notice even if skimmingnull,
    "extendedInfo": {
      "dynamicErrorMessage": null,
      "propertyBag": {
        "Job Type": "Restore as files"
      },
      "tasksList": [
        {
          "status": "InProgress",
          "taskId": "Transfer data from vault"
        }
      ]
    },
    "isUserTriggered": true,
    "jobType": "AzureWorkloadJob",
    "operation": "Restore",
    "startTime": "2022-06-22T05:53:32.951666+00:00",
    "status": "InProgress",
    "workloadType": "SQLDataBase"
  },
  "resourceGroup": "SQLResourceGroup",
  "tags": null,
  "type": "Microsoft.RecoveryServices/vaults/backupJobs"
}

Die Antwort liefert Ihnen den Jobnamen. Dieser Auftragsname kann zum Nachverfolgen des Auftragsstatus mit dem Befehl az backup job show verwendet werden.

Hinweis

Wenn Sie nicht die gesamte Kette, sondern nur eine Teilmenge von Dateien wiederherstellen möchten, befolgen Sie die Schritte, die hier dokumentiert sind.

Abonnementübergreifende Wiederherstellung

Mit der Abonnementübergreifenden Wiederherstellung (Cross Subscription Restore, CSR) haben Sie die Flexibilität, jedes Abonnement und jeden Tresor unter Ihrem Mandanten wiederherzustellen, wenn Wiederherstellungsberechtigungen verfügbar sind. Standardmäßig ist CSR für alle Recovery Services-Tresore (vorhandene und neu erstellte Tresore) aktiviert.

Hinweis

  • Sie können die abonnementübergreifende Wiederherstellung aus dem Recovery Services-Tresor auslösen.
  • CSR wird nur für streamingbasierte Sicherungen und nicht für Momentaufnahme-basierte Sicherungen unterstützt.
  • Cross Regional Restore (CRR) mit CSR wird nicht unterstützt.
az backup vault create

Fügen Sie den Parameter cross-subscription-restore-state hinzu, mit dem Sie den CSR-Status des Tresors während der Erstellung und Aktualisierung des Tresors festlegen können.

az backup recoveryconfig show

Fügen Sie den Parameter „--target-subscription-id“ hinzu, mit dem Sie das Zielabonnement als Eingabe beim Auslösen von Cross Subscription Restore für SQL- oder HANA-Datenquellen angeben können.

Beispiel:

   az backup vault create -g {rg_name} -n {vault_name} -l {location} --cross-subscription-restore-state Disable
   az backup recoveryconfig show --restore-mode alternateworkloadrestore --backup-management-type azureworkload -r {rp} --target-container-name {target_container} --target-item-name {target_item} --target-resource-group {target_rg} --target-server-name {target_server} --target-server-type SQLInstance --target-subscription-id {target_subscription} --target-vault-name {target_vault} --workload-type SQLDataBase --ids {source_item_id}

Nächster Schritt