Freigeben über


Sichern einer Instanz von Azure Database for PostgreSQL – Flexibler Server mit der Azure CLI (Vorschau)

Dieser Artikel erklärt, wie Sie eine Instanz von Azure PostgreSQL Database – Flexibler Server mit der Azure CLI sichern.

In diesem Artikel werden folgende Vorgehensweisen behandelt:

  • Erstellen eines Sicherungstresors
  • Erstellen einer Sicherungsrichtlinie
  • Konfigurieren einer Sicherung von Azure Database for PostgreSQL – Flexibler Server
  • Ausführen eines bedarfsgesteuerten Sicherungsauftrag

Informationen zu den unterstützten Szenarien und Einschränkungen von PostgreSQL-Datenbanken finden Sie in der Unterstützungsmatrix.

Erstellen eines Sicherungstresors

Der Sicherungstresor ist eine Speicherentität in Azure. Dadurch werden die Sicherungsdaten für neue von Azure Backup unterstützte Workloads gespeichert. Beispiele: flexible Azure Database for PostgreSQL-Server, Blobs in einem Speicherkonto und Azure-Datenträger. Sicherungstresore vereinfachen die Organisation Ihrer Sicherungsdaten und minimieren gleichzeitig den Verwaltungsaufwand. Sicherungstresore basieren auf dem Azure Resource Manager-Modell von Azure, das erweiterte Funktionen bietet, die das Schützen von Sicherungsdaten erleichtern.

Bevor Sie einen Sicherungstresor erstellen, wählen Sie die Speicherredundanz der Daten im Tresor aus. Anschließend erstellen Sie den Sicherungstresor mit der ausgewählten Speicherredundanz und dem angegebenen Speicherort.

In diesem Artikel erstellen wir einen Sicherungstresor namens TestBkpVault in der Region „USA, Westen“ (westus) unter der Ressourcengruppe testBkpVaultRG. Verwenden Sie den Befehl az data protection vault create, um einen Sicherungstresor zu erstellen. Weitere Informationen finden Sie unter Erstellen eines Sicherungstresors.

az dataprotection backup-vault create -g testBkpVaultRG --vault-name TestBkpVault -l westus --type SystemAssigned --storage-settings datastore-type="VaultStore" type="LocallyRedundant"

{
  "eTag": null,
  "id": "/subscriptions/00001111-aaaa-2222-bbbb-3333cccc4444/resourcegroups/testBkpVaultRG/providers/Microsoft.DataProtection/BackupVaults/TestBkpVault",
  "identity": {
    "principalId": "00001111-aaaa-2222-bbbb-3333cccc4444",
    "tenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
    "type": "SystemAssigned"
  },
  "location": "westus",
  "name": "TestBkpVault",
  "properties": {
    "provisioningState": "Succeeded",
    "storageSettings": [
      {
        "datastoreType": "VaultStore",
        "type": "LocallyRedundant"
      }
    ]
  },
  "resourceGroup": "testBkpVaultRG",
  "systemData": null,
  "tags": null,
  "type": "Microsoft.DataProtection/backupVaults"
}

Nachdem der Tresor erstellt wurde, erstellen wir eine Backup-Richtlinie zum Schutz von Azure PostgreSQL – Flexibler Server.

Erstellen einer Sicherungsrichtlinie

Verständnis der PostGreSQL-Backup-Richtlinie

Sehen wir uns das Sicherungsrichtlinienobjekt für PostgreSQL – Flexibler Server näher an.

  • PolicyRule
    • BackupRule
      • BackupParameter
        • BackupType (In diesem Fall eine vollständige Serversicherung)
        • Anfänglicher Datenspeicher (wo die Sicherungen gespeichert werden)
        • Trigger (Wie die Sicherung ausgelöst wird)
          • Zeitplanbasiert
          • Standardtaggingkriterien (ein Standardtag für alle geplanten Sicherungen, das die Sicherungen mit der Aufbewahrungsregel verknüpft)
    • Standardaufbewahrungsregel (eine Regel, die standardmäßig auf alle Sicherungen im anfänglichen Datenspeicher angewendet wird)

Dieses Objekt legt fest, welche Art von Sicherungen ausgelöst werden, wie sie ausgelöst werden (über einen Zeitplan), mit welchen Tags sie versehen werden, wo sie abgelegt werden (ein Datenspeicher) und wie der Lebenszyklus der Sicherungsdaten in einem Datenspeicher aussieht. Das Standardobjekt für PostgreSQL gibt an, dass jede Woche eine vollständige Sicherung ausgelöst werden soll. Diese erreichen den Tresor, in dem sie drei Monate lang gespeichert werden.

Abrufen der Richtlinienvorlage

Um die inneren Komponenten einer Sicherungsrichtlinie für die Azure PostgreSQL-Datenbanksicherung zu verstehen, rufen Sie die Richtlinienvorlage mit dem Befehl az data protection backup-policy get-default-policy-template ab. Dieser Befehl gibt eine Standardrichtlinienvorlage für einen angegebenen DataSource-Typ zurück. Verwenden Sie diese Richtlinienvorlage, um eine neue Richtlinie zu erstellen.

az dataprotection backup-policy get-default-policy-template --datasource-type AzureDatabaseForPostgreSQLFlexibleServer
{
  "datasourceTypes": [
    "Microsoft.DBforPostgreSQL/flexibleServers"
  ],
  "name": "OssPolicy1",
  "objectType": "BackupPolicy",
  "policyRules": [
    {
      "backupParameters": {
        "backupType": "Full",
        "objectType": "AzureBackupParams"
      },
      "dataStore": {
        "dataStoreType": "VaultStore",
        "objectType": "DataStoreInfoBase"
      },
      "name": "BackupWeekly",
      "objectType": "AzureBackupRule",
      "trigger": {
        "objectType": "ScheduleBasedTriggerContext",
        "schedule": {
          "repeatingTimeIntervals": [
            "R/2021-08-15T06:30:00+00:00/P1W"
          ],
          "timeZone": "UTC"
        },
        "taggingCriteria": [
          {
            "isDefault": true,
            "tagInfo": {
              "id": "Default_",
              "tagName": "Default"
            },
            "taggingPriority": 99
          }
        ]
      }
    },
    {
      "isDefault": true,
      "lifecycles": [
        {
          "deleteAfter": {
            "duration": "P3M",
            "objectType": "AbsoluteDeleteOption"
          },
          "sourceDataStore": {
            "dataStoreType": "VaultStore",
            "objectType": "DataStoreInfoBase"
          },
          "targetDataStoreCopySettings": []
        }
      ],
      "name": "Default",
      "objectType": "AzureRetentionRule"
    }
  ]
}

Die Richtlinienvorlage besteht aus einem Trigger (der entscheidet, was die Sicherung auslöst) und einem Lebenszyklus (der entscheidet, wann die Sicherung gelöscht/kopiert bzw. verschoben werden soll). Bei der Sicherung von Azure PostgreSQL – Flexibler Server ist der Standardwert für den Trigger ein geplanter wöchentlicher Trigger (eine Sicherung alle sieben Tage) und die Aufbewahrung jeder Sicherung für drei Monate.

Geplanter Trigger:

"trigger": {
        "objectType": "ScheduleBasedTriggerContext",
        "schedule": {
          "repeatingTimeIntervals": [
            "R/2021-08-15T06:30:00+00:00/P1W"
          ],
          "timeZone": "UTC"
        }

Standardlebenszyklus der Aufbewahrungsregel:

 {
      "isDefault": true,
      "lifecycles": [
        {
          "deleteAfter": {
            "duration": "P3M",
            "objectType": "AbsoluteDeleteOption"
          },
          "sourceDataStore": {
            "dataStoreType": "VaultStore",
            "objectType": "DataStoreInfoBase"
          },
          "targetDataStoreCopySettings": []
        }
      ],
      "name": "Default",
      "objectType": "AzureRetentionRule"
    }

Ändern der Richtlinienvorlage

Wichtig

In Azure PowerShell können Objekte als Bereitstellungsorte verwendet werden, um alle Änderungen durchzuführen. In Azure CLI müssen wir Dateien verwenden, da es keinen Begriff für Objekte gibt. Jeder Bearbeitungsvorgang sollte in eine neue Datei umgeleitet werden, wobei der Inhalt aus der Eingabedatei gelesen und in die Ausgabedatei umgeleitet wird. Sie können die Datei später nach Bedarf umbenennen, wenn Sie sie in einem Skript verwenden.

Ändern Sie den Zeitplan

Die Standardrichtlinienvorlage bietet einmal pro Woche eine Sicherung an. Sie können den Zeitplan für die Sicherung auf mehrere Tage pro Woche ändern. Um den Zeitplan zu ändern, verwenden Sie den Befehl az data protection backup-policy trigger set.

Im folgenden Beispiel wird die wöchentliche Sicherung so geändert, dass die Sicherung jede Woche an jedem Sonntag, Mittwoch und Freitag erfolgt. Das Datumsarray für den Zeitplan erwähnt die Datumsangaben. Die Wochentage dieser Datumsangaben werden als Wochentage verwendet. Sie müssen auch angeben, dass diese Zeitpläne jede Woche wiederholt werden sollen. Das Zeitplanintervall ist also 1 und der Intervalltyp ist Wöchentlich.

az dataprotection backup-policy trigger create-schedule --interval-type Weekly --interval-count 1 --schedule-days 2021-08-15T22:00:00 2021-08-18T22:00:00 2021-08-20T22:00:00
[
  "R/2021-08-15T22:00:00+00:00/P1W",
  "R/2021-08-18T22:00:00+00:00/P1W",
  "R/2021-08-20T22:00:00+00:00/P1W"
]

az dataprotection backup-policy trigger set --policy .\OSSPolicy.json  --schedule R/2021-08-15T22:00:00+00:00/P1W R/2021-08-18T22:00:00+00:00/P1W R/2021-08-20T22:00:00+00:00/P1W > EditedOSSPolicy.json

Hinzufügen einer neuen Aufbewahrungsregel

Die Standardvorlage hat einen Lebenszyklus für den ursprünglichen Datenspeicher unter der Standardaufbewahrungsregel. In diesem Szenario besagt die Regel, dass die Sicherungsdaten nach drei Monaten zu löschen sind. Verwenden Sie den Befehl az data protection backup-policy retention-rule create-lifecycle, um neue Lebenszyklen zu erstellen, und verwenden Sie den Befehl az data protection backup-policy retention-rule set, um sie mit den neuen Regeln oder den vorhandenen Regeln zu verknüpfen.

Im folgenden Beispiel wird eine neue Aufbewahrungsregel mit dem Namen Monatlich erstellt, bei der die erste erfolgreiche Sicherung jedes Monats sechs Monate lang im Tresor aufbewahrt werden soll.

az dataprotection backup-policy retention-rule create-lifecycle --retention-duration-count 6 --retention-duration-type Months --source-datastore VaultStore > VaultLifeCycle.JSON

az dataprotection backup-policy retention-rule set --lifecycles .\VaultLifeCycle.JSON --name Monthly --policy .\EditedOSSPolicy.json > AddedRetentionRulePolicy.JSON

Hinzufügen eines Tags und der relevanten Kriterien

Sobald eine Aufbewahrungsregel erstellt ist, müssen Sie einen entsprechenden Tag in der Eigenschaft Trigger der Backup-Richtlinie erstellen. Verwenden Sie den Befehl az data protection backup-policy tag create-absolute-criteria, um ein neues Tagging-Kriterium zu erstellen, und verwenden Sie den Befehl az data protection backup-policy tag set, um das vorhandene Tag zu aktualisieren oder ein neues Tag zu erstellen.

Im folgenden Beispiel wird ein neues Tag zusammen mit den Kriterien erstellt, der ersten erfolgreichen Sicherung des Monats. Das Tag hat denselben Namen wie die entsprechende anzuwendende Aufbewahrungsregel.

In diesem Beispiel sollten die Tag-Kriterien Monatlich heißen.

az dataprotection backup-policy tag create-absolute-criteria --absolute-criteria FirstOfMonth > tagCriteria.JSON
az dataprotection backup-policy tag set --criteria .\tagCriteria.JSON --name Monthly --policy .\AddedRetentionRulePolicy.JSON > AddedRetentionRuleAndTag.JSON

Wenn der bevorzugte Zeitplan mehrere Sicherungen pro Woche vorsieht (jeden Sonntag, Mittwoch und Donnerstag, wie in diesem Beispiel angegeben) und Sie die Sicherungen von Sonntag und Freitag archivieren möchten, dann können die Tagging-Kriterien mit dem Befehl az data protection backup-policy tag create-generic-criteria wie folgt geändert werden.

az dataprotection backup-policy tag create-generic-criteria --days-of-week Sunday Friday > tagCriteria.JSON
az dataprotection backup-policy tag set --criteria .\tagCriteria.JSON --name Monthly --policy .\AddedRetentionRulePolicy.JSON > AddedRetentionRuleAndTag.JSON

Erstellen einer neuen Sicherungsrichtlinie für PostgreSQL – Flexibler Server

Sobald die Vorlage entsprechend den Anforderungen geändert wurde, verwenden Sie den Befehl az data protection backup-policy create, um eine Richtlinie mit der geänderten Vorlage zu erstellen.

az dataprotection backup-policy create --backup-policy-name FinalOSSPolicy --policy AddedRetentionRuleAndTag.JSON --resource-group testBkpVaultRG --vault-name TestBkpVault

Konfigurieren der Sicherung

Nach dem Erstellen des Tresors und der Richtlinie gibt es drei wichtige Punkte, die Sie für den Schutz einer Azure PostgreSQL-Datenbank beachten müssen.

Wichtige involvierte Entitäten

Zu schützende PostGreSQL-Datenbank

Rufen Sie die Azure Resource Manager-ID (ARM-ID) der zu schützenden Instanzen von PostgreSQL – Flexibler Server ab. Diese ID fungiert als Bezeichner des Servers. Als Beispiel wird ein PostgreSQL-Server mit dem Namen testpgflex in der Ressourcengruppe ossrg unter einem anderen Abonnement verwendet.

Das folgende Beispiel verwendet bash.

ossId="/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/ossrg/providers/Microsoft.DBforPostgreSQL/flexibleServers/testpgflex"

Sicherungstresor

Der Sicherungstresor muss eine Verbindung mit der Instanz von PostgreSQL – Flexibler Server herstellen, daher erfordert er Zugriff auf diesen Server. Der verwalteten Systemidentität (Managed System Identity, MSI) des Sicherungstresors wird Zugriff gewährt.

Sehen Sie sich die Berechtigungen an, die Sie der verwalteten Systemidentität (MSI) des Sicherungstresors auf dem flexiblen PostgreSQL-Server gewähren sollten.

Vorbereiten der Anforderung

Nachdem alle relevanten Berechtigungen festgelegt wurden, führen Sie die Konfiguration der Sicherung in zwei Schritten aus.

  1. Wir bereiten die entsprechende Anforderung vor, indem wir den entsprechenden Tresor, die Richtlinie und die PostgreSQL-Datenbank mit dem Befehl az data protection backup-instance initialize verwenden.
  2. Die Anforderung zum Schutz des Servers wird mit dem Befehl az data protection backup-instance create übermittelt.
az dataprotection backup-instance initialize --datasource-id $ossId --datasource-type AzureDatabaseForPostgreSQLFlexibleServer -l <vault-location> --policy-id <policy_arm_id>   > OSSBkpInstance.JSON

az dataprotection backup-instance create --resource-group testBkpVaultRG --vault-name TestBkpVault TestBkpvault --backup-instance .\OSSBkpInstance.JSON

Ausführen einer On-Demand-Sicherung

Sie müssen eine Aufbewahrungsregel angeben, während Sie die Sicherung auslösen. Um die Aufbewahrungsregeln in der Richtlinie anzuzeigen, navigieren Sie durch die JSON-Datei der Richtlinie für Aufbewahrungsregeln. Im folgenden Beispiel gibt es zwei Aufbewahrungsregeln mit den Namen Standard und Monatlich. Wir verwenden die Regel Monatlich für die bedarfsgesteuerte Sicherung.

az dataprotection backup-policy show  -g ossdemorg --vault-name ossdemovault-1 --subscription eaaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e --name osspol5
{
  "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ossdemorg/providers/Microsoft.DataProtection/backupVaults/ossdemovault-1/backupPolicies/osspol5",
  "name": "osspol5",
  "properties": {
    "datasourceTypes": [
      "Microsoft.DBforPostgreSQL/flexibleServers"
    ],
    "objectType": "BackupPolicy",
    "policyRules": [
      {
        "backupParameters": {
          "backupType": "Full",
          "objectType": "AzureBackupParams"
        },
        "dataStore": {
          "dataStoreType": "VaultStore",
          "objectType": "DataStoreInfoBase"
        },
        "name": "BackupWeekly",
        "objectType": "AzureBackupRule",
        "trigger": {
          "objectType": "ScheduleBasedTriggerContext",
          "schedule": {
            "repeatingTimeIntervals": [
              "R/2020-04-04T20:00:00+00:00/P1W",
              "R/2020-04-01T20:00:00+00:00/P1W"
            ],
            "timeZone": "UTC"
          },
          "taggingCriteria": [
            {
              "criteria": [
                {
                  "absoluteCriteria": [
                    "FirstOfMonth"
                  ],
                  "daysOfMonth": null,
                  "daysOfTheWeek": null,
                  "monthsOfYear": null,
                  "objectType": "ScheduleBasedBackupCriteria",
                  "scheduleTimes": null,
                  "weeksOfTheMonth": null
                }
              ],
              "isDefault": false,
              "tagInfo": {
                "eTag": null,
                "id": "Monthly_",
                "tagName": "Monthly"
              },
              "taggingPriority": 15
            },
            {
              "criteria": null,
              "isDefault": true,
              "tagInfo": {
                "eTag": null,
                "id": "Default_",
                "tagName": "Default"
              },
              "taggingPriority": 99
            }
          ]
        }
      },
      {
        "isDefault": false,
        "lifecycles": [
          {
            "deleteAfter": {
              "duration": "P10Y",
              "objectType": "AbsoluteDeleteOption"
            },
            "sourceDataStore": {
              "dataStoreType": "VaultStore",
              "objectType": "DataStoreInfoBase"
            },
            "targetDataStoreCopySettings": []
          }
        ],
        "name": "Monthly",
        "objectType": "AzureRetentionRule"
      },
      {
        "isDefault": true,
        "lifecycles": [
          {
            "deleteAfter": {
              "duration": "P1Y",
              "objectType": "AbsoluteDeleteOption"
            },
            "sourceDataStore": {
              "dataStoreType": "VaultStore",
              "objectType": "DataStoreInfoBase"
            },
            "targetDataStoreCopySettings": []
          }
        ],
        "name": "Default",
        "objectType": "AzureRetentionRule"
      }
    ]
  },
  "resourceGroup": "ossdemorg",
  "systemData": null,
  "type": "Microsoft.DataProtection/backupVaults/backupPolicies"
}

Verwenden Sie den Befehl az data protection backup-instance adhoc-backup, um eine bedarfsgesteuerte Sicherung auszulösen.

az dataprotection backup-instance adhoc-backup --name "ossrg-testpgflex" --rule-name "Monthly" --resource-group testBkpVaultRG --vault-name TestBkpVault

Nachverfolgen von Aufträgen

Verfolgen Sie alle Aufträge mithilfe des Befehls az data protection job list nach. Sie können alle Aufträge auflisten und ein bestimmtes Auftragsdetail abrufen.

Sie können auch Az.ResourceGraph verwenden, um alle Aufträge über alle Backup-Depots hinweg zu verfolgen. Verwenden Sie den Befehl az data protection job list-from-resourcegraph, um die relevanten Aufträge zu finden, die sich in den Sicherungstresoren befinden.

az dataprotection job list-from-resourcegraph --datasource-type AzureDatabaseForPostgreSQLFlexibleServer --status Completed

Nächste Schritte