Backup e restauração no Banco de Dados do Azure para PostgreSQL – Servidor Único

APLICA-SE A: Banco de Dados do Azure para PostgreSQL – Servidor Único

O Banco de Dados do Azure para PostgreSQL cria backups de servidor automaticamente e os armazena no armazenamento com redundância geográfica ou local configurado pelo usuário. Os backups podem ser usados para restaurar o servidor pontualmente. Os recursos de backup e restauração são uma parte essencial de qualquer estratégia de continuidade dos negócios, pois eles protegem seus dados contra exclusão ou corrupção acidentais.

Backups

O Banco de Dados do Azure para PostgreSQL faz backups dos arquivos de dados e do log de transações. Dependendo do tamanho máximo de armazenamento com suporte, fazemos backups totais e diferenciais (servidores de armazenamento máximo de 4 TB) ou backups de instantâneo (servidores de armazenamento máximo de até 16 TB). Esses backups permitem que você restaure um servidor pontualmente dentro de seu período de retenção de backup configurado. O período de retenção de backup padrão é de sete dias. Você pode, opcionalmente, configurá-lo para até 35 dias. Todos os backups são criptografados usando a criptografia AES de 256 bits.

Esses arquivos de backup não podem ser exportados. Os backups podem ser usados somente para operações de restauração no Banco de Dados do Azure para PostgreSQL. Você pode utilizar pg_dump para copiar um banco de dados.

Frequência de backup

Servidores com armazenamento de até 4 TB

Para servidores que dão suporte a até 4 TB de armazenamento máximo, os backups completos ocorrem uma vez a cada semana. Os backups diferenciais ocorrem duas vezes ao dia. Os backups de log de transações ocorrem a cada cinco minutos.

Servidores com armazenamento de até 16 TB

Em um subconjunto de regiões do Azure, todos os servidores recentemente provisionados podem dar suporte ao armazenamento de uso geral de até 16 TB. Os backups nos servidores de armazenamento de 16 TB são baseados em instantâneos. O primeiro backup de instantâneo completo é agendado imediatamente após a criação de um servidor. O primeiro backup de instantâneo completo é mantido como o backup de base do servidor. Os backups de instantâneo subsequentes são apenas backups diferenciais. Os backups de instantâneo diferenciais não ocorrem em um agendamento fixo. Em um dia, vários backups de instantâneo diferenciais são executados, mas apenas três backups são mantidos. Os backups de log de transações ocorrem a cada cinco minutos.

Observação

Os backups automáticos são executados para servidores de réplica que são configurados com até 4 TB de configuração de armazenamento.

Retenção de backup

Os backups são mantidos no servidor com base na configuração do período de retenção de backup. É possível definir um período de retenção de 7 a 35 dias. O período de retenção padrão é de 7 dias. É possível definir o período de retenção durante a criação do servidor ou posteriormente, atualizando a configuração de backup pelo portal do Azure ou pela CLI do Azure.

O período de retenção de backup determina até quando a restauração de pontos anteriores pode ser feita, já que ele se baseia em backups disponíveis. O período de retenção de backup também pode ser tratado como uma janela de recuperação sob uma perspectiva de restauração. Todos os backups necessários para executar uma restauração pontual dentro do período de retenção de backup são mantidos no armazenamento de backup. Por exemplo, se o período de retenção de backup for definido como 7 dias, a janela de recuperação será considerada nos últimos 7 dias. Nesse cenário, são mantidos todos os backups necessários para restaurar o servidor nos últimos 7 dias. Com uma janela de retenção de backup de sete dias:

  • Os servidores com armazenamento de até 4 TB manterão até dois backups de banco de dados completos, todos os backups diferenciais e backups de log de transações executados desde o backup de banco de dados completo mais antigo.
  • Os servidores com armazenamento de até 16 TB manterão o instantâneo completo do banco de dados, todos os instantâneos diferenciais e backups de log de transações dos últimos 8 dias.

Opções de redundância de backup

O Banco de Dados do Azure para PostgreSQL fornece a flexibilidade de escolher entre o armazenamento de backup com redundância local ou com redundância geográfica nas camadas de Uso Geral e Otimizado para Memória. Quando os backups são armazenados no armazenamento de backup com redundância geográfica, uma cópia de backup adicional é replicada para uma região emparelhada. Isso fornece maior proteção e capacidade de restaurar o servidor em uma região diferente em caso de desastre. A camada Básica oferece apenas o armazenamento de backup de redundância local.

Importante

A configuração do armazenamento com redundância local ou geográfica para backup só é permitida durante a criação do servidor. Quando o servidor é provisionado, você não pode alterar a opção de redundância do armazenamento de backup.

Custo do armazenamento de backup

O Banco de Dados do Azure para PostgreSQL fornece até 100% de seu armazenamento de servidor configurado como armazenamento de backup sem custo adicional. Qualquer armazenamento de backup adicional usado será cobrado em GB por mês. Por exemplo, caso tenha provisionado um servidor com 250 GB de armazenamento, terá 250 GB de armazenamento adicional disponíveis para backups de servidor, sem nenhum custo adicional. O armazenamento consumido para backups além de 250 GB será cobrado de acordo com o modelo de preços.

É possível usar a métrica Armazenamento de Backup usado no Azure Monitor, disponível no portal do Azure, para monitorar o armazenamento de backup consumido por um servidor. A métrica Armazenamento de Backup usado representa a soma do armazenamento consumido por todos os backups de banco de dados, backups diferenciais e backups de log retidos com base no período de retenção de backup definido para o servidor. A frequência dos backups é gerenciada pelo serviço e foi explicada anteriormente. Uma atividade transacional intensa no servidor pode fazer com que o uso do armazenamento de backup aumente, independentemente do tamanho total do banco de dados. Para o armazenamento com redundância geográfica, o uso de armazenamento de backup é o dobro do armazenamento com redundância local.

O principal meio de controlar o custo de armazenamento de backup é definir o período de retenção de backup apropriado e escolher as opções de redundância de backup corretas para atender aos objetivos de recuperação que você deseja. É possível definir um período de retenção no intervalo de 7 a 35 dias. Para servidores de uso geral e otimizados de memória existe a opção de armazenamento com redundância geográfica para backups.

Restaurar

No Banco de Dados do Azure para PostgreSQL, a execução de uma restauração cria um novo servidor de backup do servidor original.

Há dois tipos de restauração disponíveis:

  • A Restauração pontual está disponível em qualquer opção de redundância de backup e cria um novo servidor na mesma região do servidor original.
  • A Restauração geográfica está disponível somente se você configurou seu servidor para armazenamento com redundância geográfica; ele permite que você restaure o servidor em uma região diferente.

O tempo estimado de recuperação dependerá de vários fatores, incluindo os tamanhos dos bancos de dados, o tamanho do log de transações, a largura de banda de rede e o número total de bancos de dados de recuperação na mesma região e ao mesmo tempo. O tempo de recuperação varia dependendo do último backup de dados e da quantidade de recuperação que precisa ser executada. Geralmente é menor do que 12 horas.

Observação

Se o servidor PostgreSQL de origem estiver criptografado com chaves gerenciadas pelo cliente, consulte a documentação para obter considerações adicionais.

Observação

Se você quiser restaurar um servidor PostgreSQL excluído, siga o procedimento documentado aqui.

Restauração em um momento determinado

Independentemente de sua opção de redundância de backup, você pode executar uma restauração para qualquer ponto anterior dentro de seu período de retenção de backup. Um novo servidor é criado na mesma região do Azure do servidor original. Ele é criado com a configuração do servidor original para o tipo de preço, a geração de computação, o número de núcleos virtuais, o tamanho do armazenamento, o período de retenção de backup e a opção de redundância de backup.

A Restauração pontual é útil em vários cenários. Por exemplo, quando um usuário exclui dados acidentalmente, descarta uma tabela ou um banco de dados importante, ou se um aplicativo acidentalmente substitui dados bons por dados inválidos devido a um defeito no aplicativo.

Talvez seja necessário aguardar a execução do próximo backup de log de transações antes de poder restaurar para um ponto anterior nos últimos cinco minutos.

Se você quiser restaurar uma tabela descartada,

  1. Restaure o servidor de origem usando o método pontual.
  2. Faça uma cópia de backup da tabela usando pg_dump do servidor restaurado.
  3. Renomeie a tabela de origem no servidor original.
  4. Importe a tabela usando a linha de comando psql no servidor original.
  5. Opcionalmente, você pode excluir o servidor restaurado.

Observação

É recomendável não criar várias restaurações para o mesmo servidor ao mesmo tempo.

Restauração geográfica

É possível restaurar um servidor para outra região do Azure onde o serviço está disponível caso você tenha configurado o servidor para backups com redundância geográfica. Os servidores que dão suporte a até 4 TB de armazenamento podem ser restaurados para a região emparelhada geograficamente ou para qualquer região que ofereça suporte a até 16 TB de armazenamento. Para servidores que dão suporte a até 16 TB de armazenamento, os backups geográficos podem ser restaurados em qualquer região que ofereça suporte a servidores de 16 TB também. Examine os tipos de preço do Banco de Dados do Azure para PostgreSQL para ver a lista de regiões com suporte.

A restauração geográfica é a opção de recuperação padrão quando o servidor não está disponível devido a um incidente na região em que ele está hospedado. Se um incidente de grande escala em uma região resultar na indisponibilidade do seu aplicativo de banco de dados, você poderá restaurar um servidor do backup com redundância geográfica para um servidor em qualquer outra região. Há um atraso entre quando um backup é feito e quando ele é replicado em uma região diferente. Esse atraso pode ser de até uma hora, então, em caso de desastre pode haver perda de dados de até uma hora.

Durante a restauração geográfica, as configurações de servidor que podem ser alteradas incluem as opções de geração de computação, vCore, período de retenção de backup e redundância de backup. Não há suporte para alterar o tipo de preço (básico, uso geral ou com otimização de memória) ou tamanho de armazenamento.

Observação

Se o servidor de origem usar a criptografia dupla de infraestrutura, para restaurar o servidor, haverá limitações, incluindo regiões disponíveis. Veja a infraestrutura de criptografia dupla para obter mais detalhes.

Executar tarefas de pós-restauração

Após uma restauração de um dos mecanismos de recuperação, você deve executar as seguintes tarefas para colocar os usuários e os aplicativos novamente em execução:

  • Para acessar o servidor restaurado, uma vez que ele tem um nome diferente do servidor original, altere o nome do servidor para o nome do servidor restaurado e o nome de usuário para na cadeia username@new-restored-server-name de conexão.
  • Se o novo servidor for usado para substituir o servidor original, redirecione clientes e aplicativos cliente para o novo servidor.
  • Verifique se as regras de VNet e de firewall no nível do servidor adequadas estão em vigor para que os usuários se conectem. Essas regras não são copiadas do servidor original.
  • Verifique se as permissões e os logons adequados no nível do banco de dados estão em vigor
  • Configurar os alertas, conforme apropriado

Próximas etapas