Создание резервной копии базы данных Azure для PostgreSQL с использованием Azure CLI
Эта статья содержит сведения о резервном копировании базы данных Azure для PostgreSQL с использованием Azure CLI.
В этой статье вы узнаете, как выполнять следующие задачи.
- создание хранилища Azure Backup;
- создание политики архивации;
- настройка резервной копии базы данных Azure для PostgreSQL;
- Выполнение задания резервного копирования по запросу
Чтобы узнать о поддерживаемых сценариях и ограничениях для баз данных informgreSQL, см. матрицу поддержки.
создание хранилища Azure Backup;
Хранилище Azure Backup представляет собой сущность хранилища в Azure. В нем хранятся данные резервных копий для новых рабочих нагрузок, поддерживаемых службой Azure Backup. Сюда относятся, к примеру, серверы Базы данных Azure для PostgreSQL, BLOB-объекты в учетной записи хранения и Диски Azure. Хранилища Azure Backup упрощают организацию данных резервного копирования и одновременно снижают накладные затраты на управление. Хранилища резервных копий основаны на модели Azure Resource Manager в экосистеме Azure, которая предоставляет расширенные возможности для защиты данных, резервная копия которых создается.
Перед созданием хранилища Backup выберите избыточность данных в хранилище. Затем перейдите к созданию хранилища Backup с указанной избыточностью и расположением.
В этой статье показано, как создать хранилище Backup с именем TestBkpVault в регионе westus и группе ресурсов testBkpVaultRG. Выполните команду az dataprotection vault create, чтобы создать хранилище Backup. Дополнительные сведения о создании хранилища Azure Backup.
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/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/testBkpVaultRG/providers/Microsoft.DataProtection/BackupVaults/TestBkpVault",
"identity": {
"principalId": "2ca1d5f7-38b3-4b61-aa45-8147d7e0edbc",
"tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"type": "SystemAssigned"
},
"location": "westus",
"name": "TestBkpVault",
"properties": {
"provisioningState": "Succeeded",
"storageSettings": [
{
"datastoreType": "VaultStore",
"type": "LocallyRedundant"
}
]
},
"resourceGroup": "testBkpVaultRG",
"systemData": null,
"tags": null,
"type": "Microsoft.DataProtection/backupVaults"
}
После создания хранилища создадим политику резервного копирования для защиты баз данных Azure для PostgreSQL.
Создание политики резервного копирования
Политика резервного копирования PostGreSQL
Резервное копирование дисков обеспечивает создание нескольких резервных копий в день, а резервное копирование BLOB-объектов — это непрерывное резервное копирование без триггера, но резервное копирование PostgreSQL обеспечивает защиту архива. Данные резервной копии, которые сначала отправляются в хранилище, можно затем перенаправить на архивный уровень в соответствии с определенным правилом или жизненным циклом. В этом контексте рассмотрим объект политики резервного копирования для PostgreSQL.
- PolicyRule
- BackupRule
- BackupParameter
- BackupType (тип резервной копии — в этом случае полная резервная копия базы данных)
- Исходное хранилище данных (где первоначально будут храниться резервные копии)
- Триггер (активация резервной копии)
- По расписанию
- Стандартные условия добавления тегов (тег по умолчанию для всех запланированных операций резервного копирования; этот тег связывает резервные копии с правилом хранения)
- BackupParameter
- Правило хранения по умолчанию (правило, которое будет по умолчанию применяться ко всем резервным копиям в начальном хранилище данных)
- BackupRule
Таким образом, этот объект определяет, какой тип резервных копий активируется, как они активируются (с помощью расписания), то, что они помечены, где они находятся (хранилище данных) и жизненный цикл резервных данных в хранилище данных. Объект PowerShell по умолчанию для PostgreSQL говорит, чтобы активировать полную резервную копию каждую неделю, и они будут достигать хранилища, где они хранятся в течение трех месяцев.
Если вы хотите добавить архивный уровень хранения в политику, необходимо решить, когда данные будут перемещены из хранилища в архив, как долго данные будут находиться в архиве и какие из резервных копий, предусмотренных расписанием, должны быть помечены как архивируемые. Поэтому необходимо добавить правило хранения, в котором жизненный цикл резервных данных будет определен из хранилища данных в архивное хранилище данных и как долго они будут оставаться в архивном хранилище данных. Затем нужно добавить тег, который пометит резервные копии, предусмотренные расписанием, как подходящие для архивации.
Объект PowerShell, получаемый в результате:
- PolicyRule
- BackupRule
- BackupParameter
- BackupType (тип резервной копии — в этом случае полная резервная копия базы данных)
- Исходное хранилище данных (где первоначально будут храниться резервные копии)
- Триггер (активация резервной копии)
- По расписанию
- Стандартные условия добавления тегов (тег по умолчанию для всех запланированных операций резервного копирования; этот тег связывает резервные копии с правилом хранения)
- Новые условия добавления тегов для нового правила хранения с тем же именем "X"
- BackupParameter
- Правило хранения по умолчанию (правило, которое будет по умолчанию применяться ко всем резервным копиям в начальном хранилище данных)
- Новое правило хранения с именем "X"
- Жизненный цикл
- Исходное хранилище данных
- Удаление по истечении периода хранения в исходном хранилище данных
- Копирование в целевое хранилище данных
- Жизненный цикл
- BackupRule
Извлечение шаблона политики
Чтобы понять внутренние компоненты политики Azure Backup для резервного копирования базы данных Azure для PostgreSQL, извлеките шаблон политики с помощью команды az dataprotection backup-policy get-default-policy-template. Эта команда возвращает шаблон политики по умолчанию для заданного типа источника данных. Используйте этот шаблон политики для создания новой политики.
az dataprotection backup-policy get-default-policy-template --datasource-type AzureDatabaseForPostgreSQL
{
"datasourceTypes": [
"Microsoft.DBforPostgreSQL/servers/databases"
],
"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"
}
]
}
Шаблон политики состоит из триггера (который определяет, что активирует резервное копирование) и жизненного цикла (который принимает решение об удалении, копировании и перемещении резервной копии). Для резервного копирования Базы данных Azure для PostgreSQL по умолчанию настраивается расписание с еженедельным триггером (1 резервное копирование каждые 7 дней) и хранение каждой резервной копии в течение трех месяцев.
Триггер по расписанию:
"trigger": {
"objectType": "ScheduleBasedTriggerContext",
"schedule": {
"repeatingTimeIntervals": [
"R/2021-08-15T06:30:00+00:00/P1W"
],
"timeZone": "UTC"
}
Жизненный цикл правила хранения по умолчанию:
{
"isDefault": true,
"lifecycles": [
{
"deleteAfter": {
"duration": "P3M",
"objectType": "AbsoluteDeleteOption"
},
"sourceDataStore": {
"dataStoreType": "VaultStore",
"objectType": "DataStoreInfoBase"
},
"targetDataStoreCopySettings": []
}
],
"name": "Default",
"objectType": "AzureRetentionRule"
}
Изменение шаблона политики
Внимание
В Azure PowerShell можно использовать объекты в качестве промежуточного расположения для выполнения всех изменений. В Azure CLI мы должны использовать файлы, так как понятия объекты не существует. Каждую операцию редактирования следует перенаправлять в новый файл, в котором содержимое читается из входного файла и перенаправляется на выходной файл. Позже вы можете переименовать файл, как требуется, при использовании в скрипте.
Изменение расписания
Шаблон политики по умолчанию предлагает резервное копирование один раз в неделю. Вы можете изменить расписание резервного копирования, чтобы оно выполнялось несколько дней в неделю. Чтобы изменить расписание, используйте команду az dataprotection backup-policy trigger set.
В следующем примере еженедельное резервное копирование изменяется на резервное копирование каждую неделю в воскресенье, среду и пятницу. В массиве дат расписания упоминаются даты, а дни недели этих дат принимаются за дни недели. Кроме того, необходимо указать, что эти расписания должны повторяться каждую неделю. Таким образом, интервал расписания — 1, а тип интервала — Weekly (Еженедельно).
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
Добавление нового правила хранения
Если вы хотите добавить защиту архива, измените шаблон политики по образцу ниже.
У шаблона по умолчанию будет жизненный цикл для исходного хранилища данных в соответствии с правилом хранения по умолчанию. В этом сценарии правило предписывает удалять резервные копии данных через три месяца. Необходимо добавить новое правило хранения, которое определяет, когда данные перемещаются в архивное хранилище данных, то есть резервная копия данных сначала копируется в архивное хранилище, а затем удаляется из основного хранилища данных. Кроме того, правило должно определять, как долго данные хранятся в архивном хранилище. Чтобы создать новый жизненный цикл, используйте команду az dataprotection backup-policy retention-rule create-lifecycle и используйте команду az dataprotection backup-policy retention-rule set, чтобы связать их с новыми или существующими правилами.
В следующем примере создается новое правило хранения Ежемесячно, где первая удачная резервная копия каждого месяца должна храниться в хранилище в течение шести месяцев, перенаправляться на архивный уровень и храниться на архивном уровне в течение 24 месяцев.
az dataprotection backup-policy retention-rule create-lifecycle --retention-duration-count 6 --retention-duration-type Months --source-datastore VaultStore --target-datastore ArchiveStore --copy-option CopyOnExpiryOption > VaultToArchiveLifeCycle.JSON
az dataprotection backup-policy retention-rule create-lifecycle --retention-duration-count 24 --retention-duration-type Months -source-datastore ArchiveStore > OnArchiveLifeCycle.JSON
az dataprotection backup-policy retention-rule set --lifecycles .\VaultToArchiveLifeCycle.JSON .\OnArchiveLifeCycle.JSON --name Monthly --policy .\EditedOSSPolicy.JSON > AddedRetentionRulePolicy.JSON
Добавление тега и соответствующих критериев
После создания правила хранения необходимо создать соответствующий тег в свойстве Триггер политики резервного копирования. Используйте команду az dataprotection backup-policy tag create-absolute-criteria для создания нового критерия маркировки, а затем используйте команду az dataprotection backup-policy tag set для обновления существующего тега или создания нового.
В следующем примере создается новый тег и критерий, определяющий первую успешную резервную копию за месяц. Имя этого тега совпадает с именем правила хранения, которое здесь нужно применить.
В этом примере условия тега должны называться Monthly (Ежемесячно).
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
Предположим, что расписание предполагает создание нескольких резервных копий в неделю (каждое воскресенье, среду и четверг, как указано в примере выше) и вы хотите архивировать резервные копии по понедельникам и пятницам. Условия маркировки можно изменить следующим образом, используя команду az dataprotection backup-policy tag create-generic-criteria.
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
Создание политики резервного копирования PostgreSQL
После изменения шаблона с помощью команды az dataprotection backup-policy create создайте политику с использованием измененного шаблона.
az dataprotection backup-policy create --backup-policy-name FinalOSSPolicy --policy AddedRetentionRuleAndTag.JSON --resource-group testBkpVaultRG --vault-name TestBkpVault
Настроить резервное копирование
После создания хранилища и политики вам следует принять во внимание три важных аспекта, касающихся защиты базы данных Azure для PostgreSQL.
Используемые ключевые сущности
Защищенная база данных PostGreSQL
Получить защищенный ИД Azure Resource Manager (ARM) в PostgreSQL. Он служит идентификатором базы данных. В качестве примера базы данных с именем empdb11 мы используем тест PostgreSQL Serverposgresql,который находится в группе ресурсов ossrg по другой подписке.
В следующем примере используется Bash.
ossId="/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx/resourcegroups/ossrg/providers/Microsoft.DBforPostgreSQL/servers/archive-postgresql-ccy/databases/empdb11"
Хранилище ключей Azure
Служба Azure Backup не хранит имя пользователя и пароль для подключения к базе данных PostgreSQL. Вместо этого администратор резервной копии должен задать ключи в хранилище ключей. Затем служба Azure Backup обращается к хранилищу ключей, получает ключи и выполняет доступ к базе данных. Обратите внимание на секретный идентификатор соответствующего ключа.
В следующем примере используется Bash.
keyURI="https://testkeyvaulteus.vault.azure.net/secrets/ossdbkey"
Хранилище резервных копий
Хранилище Azure Backup должно подключаться к серверу PostgreSQL, а затем получать доступ к базе данных с помощью ключей, присутствующих в хранилище ключей. Поэтому для этого требуется доступ к серверу PostgreSQL и хранилищу ключей. Доступ предоставляется по идентификатору управляемой службы (MSI) хранилища резервных копий.
Разрешения, которые вы должны предоставить удостоверению управляемой службы Azure Backup на сервере PostgreSQL и в хранилище ключей Azure Key Vault, где находятся ключи для базы данных, описаны здесь.
Подготовка запроса
После установки всех соответствующих разрешений выполняется конфигурация резервного копирования, состоящая из двух этапов.
- Сначала мы подготовим соответствующий запрос, передав параметры хранилища, политики и учетной записи хранения, используя команду az dataprotection backup-instance initialize.
- Затем мы отправим запрос для защиты диска с использованием команды az dataprotection backup-instance create.
az dataprotection backup-instance initialize --datasource-id $ossId --datasource-type AzureDatabaseForPostgreSQL -l <vault-location> --policy-id <policy_arm_id> --secret-store-type AzureKeyVault --secret-store-uri $keyURI > OSSBkpInstance.JSON
az dataprotection backup-instance create --resource-group testBkpVaultRG --vault-name TestBkpVault TestBkpvault --backup-instance .\OSSBkpInstance.JSON
Выполнение резервного копирования по требованию
При запуске резервного копирования необходимо указать правило хранения. Чтобы просмотреть правила хранения в политике, перейдите к правилам хранения в файле политики JSON. В следующем примере есть два правила хранения с именами По умолчанию и Ежемесячно. Для резервной копии по запросу будет применяться правило Ежемесячно.
az dataprotection backup-policy show -g ossdemorg --vault-name ossdemovault-1 --subscription e3d2d341-4ddb-4c5d-9121-69b7e719485e --name osspol5
{
"id": "/subscriptions/e3d2d341-4ddb-4c5d-9121-69b7e719485e/resourceGroups/ossdemorg/providers/Microsoft.DataProtection/backupVaults/ossdemovault-1/backupPolicies/osspol5",
"name": "osspol5",
"properties": {
"datasourceTypes": [
"Microsoft.DBforPostgreSQL/servers/databases"
],
"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"
}
Активируйте резервное копирование по запросу с помощью команды az dataprotection backup-instance adhoc-backup.
az dataprotection backup-instance adhoc-backup --name "ossrg-empdb11" --rule-name "Monthly" --resource-group testBkpVaultRG --vault-name TestBkpVault
Отслеживание заданий
Для отслеживания заданий используется команда az dataprotection job list. Можно вывести список всех заданий и получить сведения о конкретном задании.
Для отслеживания всех заданий во всех хранилищах Backup можно также использовать Az.ResourceGraph. Используйте команду az dataprotection job list-from-resourcegraph для получения соответствующего задания, которое может находиться в любом из хранилищ Azure Backup.
az dataprotection job list-from-resourcegraph --datasource-type AzureDatabaseForPostgreSQL --status Completed