Резервное копирование баз данных PostgreSQL с помощью Azure PowerShell

В этой статье описывается резервное копирование базы данных Azure для PostgreSQL с помощью Azure PowerShell. Вы также можете настроить резервное копирование с помощью портала Azure, Azure CLI и REST API для баз данных PostgreSQL.

Дополнительные сведения о поддерживаемых сценариях и часто задаваемых вопросах о резервном копировании баз данных PostgreSQL в Базе данных Azure для PostgreSQL.

Создание резервного хранилища

Хранилище резервных копий — это элемент хранилища в Azure. Он сохраняет данные резервного копирования для различных новых рабочих нагрузок, поддерживаемых Azure Backup, таких как серверы Базы данных Azure для PostgreSQL, диски Azure и большие двоичные объекты Azure. Хранилища Azure Backup упрощают организацию данных резервного копирования и одновременно снижают накладные затраты на управление. Хранилища резервных копий основаны на модели Azure Resource Manager, которая предоставляет расширенные возможности для защиты данных.

Перед созданием хранилища Backup выберите избыточность данных в хранилище. Затем приступите к созданию резервного хранилища с заданной избыточностью и местоположением.

В этой статье вы создадите хранилище резервных копий с именем TestBkpVaultв регионе westus в группе testBkpVaultRGресурсов. New-AzDataProtectionBackupVault Используйте команду для создания хранилища резервных копий. Дополнительные сведения о создании хранилища резервных копий.

$storageSetting = New-AzDataProtectionBackupVaultStorageSettingObject -Type LocallyRedundant/GeoRedundant -DataStoreType VaultStore
New-AzDataProtectionBackupVault -ResourceGroupName testBkpVaultRG -VaultName TestBkpVault -Location westus -StorageSetting $storageSetting
$TestBkpVault = Get-AzDataProtectionBackupVault -VaultName TestBkpVault
$TestBKPVault | fl
ETag                :
Id                  : /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx/resourceGroups/testBkpVaultRG/providers/Microsoft.DataProtection/backupVaults/TestBkpVault
Identity            : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.DppIdentityDetails
IdentityPrincipalId :
IdentityTenantId    :
IdentityType        :
Location            : westus
Name                : TestBkpVault
ProvisioningState   : Succeeded
StorageSetting      : {Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.StorageSetting}
SystemData          : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.SystemData
Tag                 : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.DppTrackedResourceTags
Type                : Microsoft.DataProtection/backupVaults

создание политики архивации;

После создания хранилища можно создать политику резервного копирования, чтобы защитить базы данных PostgreSQL. Вы также можете создать политику резервного копирования для баз данных PostgreSQL с помощью REST API.

Общие сведения о политике резервного копирования PostgreSQL

В то время как резервное копирование дисков предлагает несколько резервных копий в день, а резервное копирование BLOB-объектов — это непрерывная резервная копия без триггера, Служба архивации PostgreSQL обеспечивает защиту архива. Данные резервного копирования, которые сначала отправляются в хранилище, можно переместить на архивный уровень в соответствии с определенным правилом или жизненным циклом.

В этом контексте следующая иерархия поможет понять объект политики резервного копирования для PostgreSQL:

• Правило политики
  • Правило резервного копирования
    • Параметр резервного копирования
      • Тип резервного копирования (полная резервная копия базы данных в данном случае)
      • Начальное хранилище данных (где резервные копии изначально помещаются)
      • Триггер (активация резервной копии)
        • Расписание
        • Критерии тегов по умолчанию (тег по умолчанию, который связывает все запланированные резервные копии с правилом хранения).
  • Правило хранения по умолчанию (правило, применяемое ко всем резервным копиям по умолчанию в исходном хранилище данных)

Объект политики определяет, какие типы резервных копий активируются, как они активируются (с помощью расписания), то, что они помечены, где они находятся (хранилище данных) и жизненный цикл их данных в хранилище данных.

Объект PowerShell по умолчанию для PostgreSQL говорит, чтобы активировать полную резервную копию каждую неделю. Резервные копии достигают хранилища, где они хранятся в течение трех месяцев.

Если вы хотите добавить уровень архива в политику, необходимо решить, когда данные будут перемещены из хранилища в архив, как долго данные будут оставаться в архиве, и какие из запланированных резервных копий должны быть помечены как архивируемые. Необходимо добавить правило хранения, определяющее жизненный цикл данных резервных копий из хранилища сейфа в архивное хранилище данных. Правило хранения также определяет, как долго данные резервного копирования будут оставаться в архивном хранилище данных. Затем необходимо добавить тег, который помечает запланированные резервные копии как подходящие для архивирования.

Полученный объект PowerShell выглядит следующим образом:

• Правило политики
  • Правило резервного копирования
    • Параметр резервного копирования
      • Тип резервного копирования (полная резервная копия базы данных в данном случае)
      • Начальное хранилище данных (где резервные копии изначально помещаются)
      • Триггер (активация резервной копии)
        • Расписание
        • Критерии тегов по умолчанию (тег по умолчанию, который связывает все запланированные резервные копии с правилом хранения)
        • Новые критерии тегов для нового правила хранения с тем же именем
  • Правило хранения по умолчанию (правило, применяемое ко всем резервным копиям по умолчанию в исходном хранилище данных)
  • Новое правило хранения
    • Жизненный цикл
      • Исходное хранилище данных
      • Период времени удаления в исходном хранилище данных
      • Копирование в целевое хранилище данных

Извлеките шаблон политики

Чтобы понять внутренние компоненты политики резервного копирования для резервной копии базы данных PostgreSQL, получите шаблон политики с помощью Get-AzDataProtectionPolicyTemplate команды. Эта команда возвращает шаблон политики по умолчанию для типа источника данных. Используйте этот шаблон политики для создания новой политики.

$policyDefn = Get-AzDataProtectionPolicyTemplate -DatasourceType AzureDatabaseForPostgreSQL
$policyDefn | fl


DatasourceType : {Microsoft.DBforPostgreSQL/servers/databases}
ObjectType     : BackupPolicy
PolicyRule     : {BackupWeekly, Default}

$policyDefn.PolicyRule | fl


BackupParameter           : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210701.AzureBackupParams
BackupParameterObjectType : AzureBackupParams
DataStoreObjectType       : DataStoreInfoBase
DataStoreType             : VaultStore
Name                      : BackupWeekly
ObjectType                : AzureBackupRule
Trigger                   : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210701.ScheduleBasedTriggerCo
                            ntext
TriggerObjectType         : ScheduleBasedTriggerContext

IsDefault  : True
Lifecycle  : {Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210701.SourceLifeCycle}
Name       : Default
ObjectType : AzureRetentionRule

Шаблон политики состоит из триггера (который решает, что активирует резервную копию) и жизненный цикл (который решает, когда следует удалять, копировать или перемещать резервную копию). В резервной копии базы данных PostgreSQL значение по умолчанию для триггера — это запланированный еженедельный триггер (одна резервная копия каждые семь дней). Каждая резервная копия сохраняется в течение трех месяцев.

 $policyDefn.PolicyRule[0].Trigger | fl


ObjectType                    : ScheduleBasedTriggerContext
ScheduleRepeatingTimeInterval : {R/2021-08-22T02:00:00+00:00/P1W}
ScheduleTimeZone              : UTC
TaggingCriterion              : {Default}

$policyDefn.PolicyRule[1].Lifecycle | fl


DeleteAfterDuration        : P3M
DeleteAfterObjectType      : AbsoluteDeleteOption
SourceDataStoreObjectType  : DataStoreInfoBase
SourceDataStoreType        : VaultStore
TargetDataStoreCopySetting : {}

Изменение шаблона политики

Изменение расписания

Шаблон политики по умолчанию предлагает резервное копирование один раз в неделю. Вы можете изменить расписание резервного копирования, чтобы оно выполнялось несколько дней в неделю. Чтобы изменить расписание, используйте Edit-AzDataProtectionPolicyTriggerClientObject команду.

Следующий пример изменяет еженедельную резервную копию в воскресенье, среду и пятницу каждой недели. Массив дат расписания упоминает даты и дни недели для этих дат принимаются в качестве дней недели. Кроме того, необходимо указать, что эти расписания должны повторяться каждую неделю. Таким образом, интервал расписания - 1, а тип интервала - Weekly.

$schDates = @(
  (
    (Get-Date -Year 2021 -Month 08 -Day 15 -Hour 22 -Minute 0 -Second 0)
  ), 
  (
    (Get-Date -Year 2021 -Month 08 -Day 18 -Hour 22 -Minute 0 -Second 0)
  ),
  (
    (Get-Date -Year 2021 -Month 08 -Day 20 -Hour 22 -Minute 0 -Second 0)
  )
)
$trigger = New-AzDataProtectionPolicyTriggerScheduleClientObject -ScheduleDays $schDates -IntervalType Weekly -IntervalCount 1 
Edit-AzDataProtectionPolicyTriggerClientObject -Schedule $trigger -Policy $policyDefn   

Добавление нового правила хранения

Если вы хотите добавить защиту архива, необходимо изменить шаблон политики.

Шаблон по умолчанию имеет жизненный цикл для исходного хранилища данных в соответствии с правилом хранения по умолчанию. В этом сценарии правило предписывает удалять резервные копии данных через три месяца. Необходимо добавить новое правило хранения, определяющее, когда данные перемещаются в архивное хранилище данных. То есть данные резервного копирования сначала копируются в архивное хранилище данных, а затем удаляются в откатном хранилище.

Кроме того, правило должно определить, как долго хранить данные в архивном хранилище данных. Чтобы создать новые жизненные циклы, используйте New-AzDataProtectionRetentionLifeCycleClientObject команду. Чтобы связать эти жизненные циклы с новыми или существующими правилами Edit-AzDataProtectionPolicyRetentionRuleClientObject , используйте команду.

В следующем примере создается новое правило хранения с именем Monthly. В этом правиле первая успешная резервная копия каждого месяца хранится в хранилище в течение шести месяцев, перемещается на архивный уровень и хранится на архивном уровне в течение 24 месяцев.

$VaultToArchiveLifeCycle = New-AzDataProtectionRetentionLifeCycleClientObject -SourceDataStore VaultStore -SourceRetentionDurationType Months -SourceRetentionDurationCount 6 -TargetDataStore ArchiveStore -CopyOption CopyOnExpiryOption

$OnArchiveLifeCycle = New-AzDataProtectionRetentionLifeCycleClientObject -SourceDataStore ArchiveStore -SourceRetentionDurationType Months -SourceRetentionDurationCount 24

Edit-AzDataProtectionPolicyRetentionRuleClientObject -Policy $policyDefn -Name Monthly -LifeCycles $VaultToArchiveLifeCycle, $OnArchiveLifeCycleLifeCycle -IsDefault $false

Добавление тега и соответствующих критериев

После создания правила хранения необходимо создать соответствующий тег в Trigger свойстве политики резервного копирования. Чтобы создать новые критерии тегов, используйте команду New-AzDataProtectionPolicyTagCriteriaClientObject. Чтобы обновить существующий тег или создать новый тег, используйте команду Edit-AzDataProtectionPolicyTagClientObject .

В следующем примере создается новый тег вместе с критерием, которым является первая успешная копия резервной копии месяца. Имя этого тега совпадает с именем правила хранения, которое здесь нужно применить.

В этом примере критерии тега называются Monthly:

$tagCriteria = New-AzDataProtectionPolicyTagCriteriaClientObject -AbsoluteCriteria FirstOfMonth
Edit-AzDataProtectionPolicyTagClientObject -Policy $policyDefn -Name Monthly -Criteria $tagCriteria

Если расписание состоит из нескольких резервных копий в неделю (каждый воскресенье, среду и четверг, как указано в предыдущем примере), и вы хотите архивировать резервные копии воскресенье и пятницу, можно изменить критерии тегов следующим образом:

$tagCriteria = New-AzDataProtectionPolicyTagCriteriaClientObject -DaysOfWeek @("Sunday", "Friday")
Edit-AzDataProtectionPolicyTagClientObject -Policy $policyDefn -Name Monthly -Criteria $tagCriteria

Создание политики резервного копирования PostgreSQL

После изменения шаблона в соответствии с требованиями используйте New-AzDataProtectionBackupPolicy команду для создания политики с помощью измененного шаблона:

$polOss = New-AzDataProtectionBackupPolicy -ResourceGroupName testBkpVaultRG -VaultName TestBkpVault -Name "TestOSSPolicy" -Policy $policyDefn

Настроить резервное копирование

После создания хранилища и политики необходимо рассмотреть три критически важные точки для резервного копирования базы данных PostgreSQL в Базе данных Azure для PostgreSQL.

Понимание ключевых сущностей

База данных PostgreSQL для резервного копирования

Получите идентификатор Resource Manager базы данных PostgreSQL для его резервирования. Этот идентификатор служит идентификатором базы данных. В следующем примере используется база данных с именем empdb11 под сервером testposgresqlPostgreSQL, которая присутствует в группе ossrg ресурсов в другой подписке:

$ossId = "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx/resourcegroups/ossrg/providers/Microsoft.DBforPostgreSQL/servers/archive-postgresql-ccy/databases/empdb11"

Хранилище ключей

Служба Azure Backup не хранит имя пользователя и пароль для подключения к базе данных PostgreSQL. Вместо этого администратор резервного копирования загружает ключи в хранилище ключей. Затем служба Azure Backup обращается к хранилищу ключей, считывает ключи и обращается к базе данных. Обратите внимание на секретный идентификатор соответствующего ключа.

$keyURI = "https://testkeyvaulteus.vault.azure.net/secrets/ossdbkey"

Хранилище резервных копий

Необходимо подключить хранилище резервных копий к серверу PostgreSQL, а затем получить доступ к базе данных с помощью ключей, присутствующих в хранилище ключей. Таким образом, хранилище резервных копий требует доступа к серверу PostgreSQL и хранилищу ключей. Доступ предоставляется управляемому удостоверению хранилища резервных копий.

Ознакомьтесь с соответствующими разрешениями, которые необходимо предоставить управляемому удостоверению хранилища резервных копий на сервере PostgreSQL и в Azure Key Vault, где хранятся ключи базы данных.

Подготовка запроса

После установки всех соответствующих разрешений выполните настройку резервной копии двумя шагами:

1. Подготовьте запрос с помощью соответствующего хранилища, политики и базы данных PostgreSQL в команде Initialize-AzDataProtectionBackupInstance .
2. Отправьте запрос на резервное копирование базы данных с помощью New-AzDataProtectionBackupInstance команды.

$instance = Initialize-AzDataProtectionBackupInstance -DatasourceType AzureDatabaseForPostgreSQL -DatasourceLocation $TestBkpvault.Location -PolicyId $polOss[0].Id -DatasourceId $ossId -SecretStoreURI $keyURI -SecretStoreType AzureKeyVault
ConvertTo-Json -InputObject $instance -Depth 4 
New-AzDataProtectionBackupInstance -ResourceGroupName "testBkpVaultRG" -VaultName $TestBkpVault.Name -BackupInstance $instance

Name                        Type                                         BackupInstanceName
----                        ----                                          ------------------
ossrg-empdb11       Microsoft.DataProtection/backupVaults/backupInstances ossrg-empdb11

Выполнение резервного копирования по требованию

Получите соответствующий экземпляр резервного копирования, на котором необходимо активировать резервную копию с помощью Get-AzDataProtectionBackupInstance команды:

$instance = Get-AzDataProtectionBackupInstance -SubscriptionId "xxxx-xxx-xxx" -ResourceGroupName "testBkpVaultRG" -VaultName $TestBkpVault.Name -Name "BackupInstanceName"

Правило хранения можно указать при активации резервной копии. Чтобы просмотреть правила хранения в политике, просмотрите объект политики. В следующем примере отображается правило с именем Default . В этой статье используется это пример правила для резервного копирования по запросу.

$ossPol.PolicyRule | fl


BackupParameter           : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.AzureBackupParams
BackupParameterObjectType : AzureBackupParams
DataStoreObjectType       : DataStoreInfoBase
DataStoreType             : OperationalStore
Name                      : BackupHourly
ObjectType                : AzureBackupRule
Trigger                   : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.ScheduleBasedTriggerContext
TriggerObjectType         : ScheduleBasedTriggerContext

IsDefault  : True
Lifecycle  : {Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.SourceLifeCycle}
Name       : Default
ObjectType : AzureRetentionRule

Чтобы активировать резервное копирование по запросу Backup-AzDataProtectionBackupInstanceAdhoc , используйте команду:

$AllInstances = Get-AzDataProtectionBackupInstance -ResourceGroupName "testBkpVaultRG" -VaultName $TestBkpVault.Name
Backup-AzDataProtectionBackupInstanceAdhoc -BackupInstanceName $AllInstances[0].Name -ResourceGroupName "testBkpVaultRG" -VaultName $TestBkpVault.Name -BackupRuleOptionRuleName "Default"

Отслеживание вакансий

Отслеживайте все задания с помощью Get-AzDataProtectionJob команды. Можно вывести список всех заданий и получить сведения о конкретном задании.

Вы также можете отслеживать Az.ResourceGraph все задания во всех хранилищах резервных копий. Используйте команду Search-AzDataProtectionJobInAzGraph, чтобы получить соответствующие задания во всех хранилищах резервных копий.

  $job = Search-AzDataProtectionJobInAzGraph -Subscription $sub -ResourceGroupName "testBkpVaultRG" -Vault $TestBkpVault.Name -DatasourceType AzureDisk -Operation OnDemandBackup

Связанный контент

• Восстановление базы данных PostgreSQL с помощью Azure PowerShell.
• Восстановление базы данных PostgreSQL с помощью портала Azure, Azure CLI и REST API.