Fazer backup do Banco de Dados do Azure para PostgreSQL usando a CLI do Azure

Artigo
07/30/2024

Este artigo explica como fazer backup do banco de dados Azure para PostgreSQLpor meio do CLI do Azure.

Neste artigo, você aprenderá a:

Criar um cofre de backup
Criar uma política de backup
Configurar um backup de um banco de dados Azure para PostgreSQL
Executar um trabalho de backup sob demanda

Para cenários e limitações com suporte para bancos de dados informgreSQL, consulte a matriz de suporte.

Criar um cofre de backup

O cofre de backup é uma entidade de armazenamento no Azure. Isso armazena os dados de backup para novas cargas de trabalho com suporte pelo Backup do Azure. Por exemplo, Banco de Dados do Azure para servidores PostgreSQL, blobs em uma conta de armazenamento e Azure Disks. Os cofres de Backup ajudam a organização dos dados de backup, minimizando a sobrecarga de gerenciamento. Os cofres de backup são baseados no modelo de Azure Resource Manager do Azure, que fornece recursos avançados para ajudar a proteger os dados de backup.

Para criar um cofre de backup, escolha a redundância de armazenamento dos dados no cofre. Depois, crie o cofre de backup com essa redundância de armazenamento e a localização.

Neste artigo, criaremos um Cofre de backup TestBkpVault, na região westus, no grupo de recursos testBkpVaultRG. Use o comando az dataprotection vault create para criar um Cofre de backup. Saiba mais sobre como criar um cofre de 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"
}

Depois que o cofre for criado, vamos criar uma política de Backup para proteger banco de dados Azure para PostgreSQL.

Criar uma política de backup

Noções básicas sobre a política de backup para PostGreSQL

Embora o backup em disco ofereça vários backups por dia e o backup de blob seja um backup contínuo sem gatilho, o backup do PostgreSQL oferece proteção contra arquivos. Os dados de backup enviados pela primeira vez para o cofre podem ser movidos para a camada de arquivo morto de acordo com uma regra definida ou um ciclo de vida. Nesse contexto, vamos entender o objeto de política de backup para PostgreSQL.

PolicyRule
- BackupRule
  - BackupParameter
    - BackupType (um backup completo de banco de dados nesse caso)
    - Armazenamento de dados inicial (onde os backups serão inicialmente alojados)
    - Gatilho (como o backup é disparado)
      - Baseado em agenda
      - Critérios de marcação padrão (uma 'marca' padrão para todos os backups agendados. Essa marca vincula os backups à regra de retenção)
- Regra de retenção padrão (uma regra que será aplicada a todos os backups, por padrão, no armazenamento de dados inicial)

Portanto, esse objeto define que tipo de backups são disparados, como eles são disparados (por meio de uma agenda), com o que eles são marcados, onde eles são lançados (um armazenamento de dados) e o ciclo de vida dos dados de backup em um armazenamento de dados. O objeto padrão do PowerShell para PostgreSQL diz para disparar um backup completo toda semana, e eles chegarão ao cofre, onde eles serão armazenados por três meses.

Se você quiser adicionar a camada de arquivo morto à política, será preciso decidir quando os dados serão movidos do cofre para o arquivo morto, por quanto tempo os dados permanecerão no arquivo morto e qual dos backups agendados deverá ser marcado como arquivamento. Portanto, você precisa adicionar uma regra de retenção, em que o ciclo de vida dos dados de backup será definido do armazenamento de dados do cofre para o armazenamento de dados de arquivos e por quanto tempo eles permanecerão no armazenamento de dados de arquivo morto. Em seguida, você precisa adicionar uma marca que marcará os backups agendados como qualificados para serem arquivados.

O objeto resultante do PowerShell é o seguinte:

PolicyRule
- BackupRule
  - BackupParameter
    - BackupType (um backup completo de banco de dados nesse caso)
    - Armazenamento de dados inicial (onde os backups serão inicialmente alojados)
    - Gatilho (como o backup é disparado)
      - Baseado em agenda
      - Critérios de marcação padrão (uma 'marca' padrão para todos os backups agendados. Essa marca vincula os backups à regra de retenção)
      - Novos critérios de marcação para a nova regra de retenção com o mesmo nome 'X'
- Regra de retenção padrão (uma regra que será aplicada a todos os backups, por padrão, no armazenamento de dados inicial)
- Uma nova regra de Retenção chamada 'X'
  - Ciclo de vida
    - Armazenamento de dados de origem
    - Excluir o Período posterior no armazenamento de dados de origem
    - Copiar para o armazenamento de dados de destino

Recuperar o modelo de política

Para entender os componentes internos de uma política de backup, para o backup do banco de dados Azure para PostgreSQL, recupere o modelo de política usando o comando az dataprotection backup-policy get-default-policy-template. Esse comando retorna um modelo de política padrão para um determinado tipo de fonte de dados. Use este modelo de política para criar uma nova política.

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"
    }
  ]
}

O modelo de política consiste em um gatilho (que decide o que dispara o backup) e um ciclo de vida (que decide quando excluir/copiar/mover o backup). No backup do banco de dados do Azure para PostgreSQL, o valor padrão do gatilho é um gatilho Semanal agendado (um backup a cada sete dias) e para manter cada backup por três meses.

Gatilho agendado:

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

Ciclo de vida de retenção padrão:

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

Modificando o modelo de política

Importante

No Azure PowerShell, os Objetos podem ser usados como locais de preparação para executar todas as modificações. No CLI do Azure, precisamos usar arquivos, pois não há nenhuma noção deObjetos. Cada operação de edição deve ser redirecionada para um novo arquivo, em que o conteúdo é lido do arquivo de entrada e redirecionado para o arquivo de saída. Posteriormente, você pode renomear o arquivo conforme necessário ao usar em um script.

Modificar o agendamento

O modelo de política padrão oferece um backup uma vez por semana. Você pode modificar a agenda para que o backup ocorra vários dias por semana. Para modificar o agendamento, use o comando az dataprotection backup-policy trigger set.

O exemplo a seguir modifica o backup semanal para que o backup ocorra em todos os domingo, quarta-feira e sexta-feira de cada semana. A matriz das datas de agendamento menciona as datas e os dias da semana dessas datas são tirados como dias da semana. Você também precisa especificar que essas agendas devem ser repetidas toda semana. Portanto, o intervalo de agendamento é 1 e o tipo de intervalo é Semanal.

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

Adicionar uma nova regra de retenção

Se você quiser adicionar a proteção de arquivo morto, precisará modificar o modelo de política conforme abaixo.

O modelo padrão terá um ciclo de vida para o armazenamento de dados inicial na regra de retenção padrão. Nesse cenário, a regra diz para excluir os dados de backup após três meses. Você deve adicionar uma nova regra de retenção que define quando os dados são movidos para o armazenamento de dados de arquivos, ou seja, os dados de backup são copiados primeiro para o armazenamento de dados de arquivos e, em seguida, excluídos no armazenamento de dados do cofre. Além disso, a regra deve definir por quanto tempo os dados são mantidos no armazenamento de dados de arquivo morto. Use o comando az dataprotection backup-policy retention-rule create-lifecycle para criar novos ciclos de vida e use o comando az dataprotection backup-policy retention-rule set para associá-las às novas regras ou às regras existentes.

O exemplo a seguir cria uma nova regra de retenção chamada Mensal, em que o primeiro backup bem-sucedido de cada mês deve ser mantido no cofre por seis meses, movido para a camada de arquivo morto e mantido na camada de arquivos por 24 meses.

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

Adicionar uma marca e os critérios relevantes

Depois que uma regra de retenção é criada, você precisa criar uma marca correspondente na propriedade Gatilho da política de Backup. Use o comando az dataprotection backup-policy tag create-absolute-criteria para criar um novo critério de marcação e usar o comando az dataprotection backup-policy tag set para atualizar a marca existente ou criar uma nova marca.

O exemplo a seguir cria uma nova marca juntamente com os critérios, o primeiro backup bem-sucedido do mês. A marca tem o mesmo nome que a regra de retenção correspondente a ser aplicada.

Neste exemplo, os critérios de marca devem ser nomeados Mensalmente.

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

Suponha que, se o agendamento for vários backups por semana (todos os domingo, quarta-feira, quinta-feira, conforme especificado no exemplo acima) e você quiser arquivar os backups de domingo e sexta-feira, os critérios de marcação poderão ser alterados da seguinte forma, usando o comando 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

Criar uma nova política de backup do PostgreSQL

Depois que o modelo for modificado de acordo com os requisitos, use o comando az dataprotection backup-policy create para criar uma política usando o modelo modificado.

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

Configurar backup

Depois que o cofre e a política forem criados, haverá três pontos críticos a serem considerados para proteger um banco de dados Azure para PostgreSQL.

Entidades-chave envolvidas

Banco de dados PostGreSQL a ser protegido

Busque a Azure Resource Manager ID do ARM (ID do ARM) do PostgreSQL a ser protegida. Isso serve como o identificador do banco de dados. Vamos usar um exemplo de um banco de dados chamado empdb11 em um servidor PostgreSQL testposgresql, que está presente no grupo de recursos ossrg em uma assinatura diferente.

O exemplo a seguir usa bash.

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

Cofre de chaves do Azure

O serviço do Backup do Azure não armazena o nome de usuário e a senha para se conectar ao banco de dados PostgreSQL. Em vez disso, o administrador de backup precisa propagar as chaves no cofre de chaves. Em seguida, o serviço de Backup acessará o cofre de chaves, lerá as chaves, e em seguida acessará o banco de dados. Observe o identificador secreto da chave relevante.

O exemplo a seguir usa bash.

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

Cofre de backup

O cofre de backup precisa se conectar ao servidor PostgreSQL e, em seguida, acessar o banco de dados por meio das chaves presentes no cofre de chaves. Portanto, ele requer acesso ao servidor PostgreSQL e ao cofre de chaves. O acesso é concedido à MSI (Identidade de Serviço Gerenciado) do cofre de backup.

Consulte as permissões que você deve conceder ao MSI (Identidade de Serviço Gerenciado) do cofre de backup no servidor PostgreSQL e no cofre de Chave do Azure que armazena chaves para o banco de dados.

Preparar a solicitação

Depois que todas as permissões relevantes forem definidas, a configuração do backup será executada em duas etapas.

Preparamos a solicitação relevante usando o cofre, a política e o banco de dados PostgreSQL relevantes por meio do comando az dataprotection backup-instance initialize.
Enviamos a solicitação para proteger o banco de dados usando o comando 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

Executar um backup sob demanda

Você precisa especificar uma regra de retenção enquanto dispara o backup. Para exibir as regras de retenção na política, navegue pelo arquivo JSON de política para regras de retenção. No exemplo a seguir, há duas regras de retenção com nomes Padrão e Mensal. Vamos usar a regra Mensal para o backup sob demanda.

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"
}

Para disparar um backup sob demanda, use o comando az dataprotection backup-instance adhoc-backup.

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

Acompanhar trabalhos

Acompanhe todos os trabalhos usando o comando az dataprotection job list. Você pode listar todos os trabalhos e buscar um detalhe de trabalho específico.

Você também pode usar o Az.ResourceGraph para acompanhar todos os trabalhos em todos os cofres de backup. Use o comando az dataprotection job list-from-resourcegraph para buscar os trabalhos relevantes que está em todos os cofres de Backup.

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

Próximas etapas

Restaurar banco de dados Azure para PostgreSQL usando a CLI do Azure

Compartilhar via