Cópia de segurança e restauro na Base de Dados do Azure para PostgreSQL – Servidor Único

  • Artigo

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

Importante

O Banco de Dados do Azure para PostgreSQL - Servidor Único está no caminho da desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único PostgreSQL?.

O Banco de Dados do Azure para PostgreSQL cria automaticamente backups de servidor e os armazena em armazenamento localmente redundante ou com redundância geográfica configurado pelo usuário. As cópias de segurança podem ser utilizadas para restaurar o servidor para um ponto no tempo. A cópia de segurança e o restauro são uma parte essencial de qualquer estratégia de continuidade empresarial, uma vez que protegem os seus dados contra danos e a eliminação acidentais.

Cópias de Segurança

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 suportado, fazemos backups completos e diferenciais (servidores de armazenamento máximos de 4 TB) ou backups instantâneos (servidores de armazenamento máximos de 16 TB). Esses backups permitem que você restaure um servidor para qualquer point-in-time dentro do período de retenção de backup configurado. O período de retenção de backup padrão é de sete dias. Opcionalmente, você pode configurá-lo até 35 dias. Todas as cópias de segurança são encriptadas através da encriptação AES de 256 bits.

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

Frequência de cópia de segurança

Servidores com armazenamento de até 4 TB

Para servidores que suportam até 4 TB de armazenamento máximo, os backups completos ocorrem uma vez por semana. Os backups diferenciais ocorrem duas vezes por dia. As cópias de segurança de registo 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 recém-provisionados podem oferecer suporte a armazenamento de até 16 TB. Os backups nesses grandes servidores de armazenamento são baseados em snapshot. A primeira cópia de segurança de instantâneos completa é agendada imediatamente após a criação do servidor. Esse primeiro backup de snapshot completo é mantido como backup básico do servidor. As cópias de segurança de instantâneos subsequentes são apenas cópias de segurança diferenciais. As cópias de segurança de instantâneos diferenciais não ocorrem num agendamento fixo. Em um dia, vários backups de snapshot diferenciais são executados, mas apenas 3 backups são mantidos. As cópias de segurança de registo de transações ocorrem a cada cinco minutos.

Nota

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

Retenção da cópia de segurança

Os backups são retidos com base na configuração do período de retenção de backup no servidor. Você pode selecionar um período de retenção de 7 a 35 dias. O período de retenção padrão é de 7 dias. Você pode definir o período de retenção durante a criação do servidor ou posteriormente atualizando a configuração de backup usando o portal do Azure ou a CLI do Azure.

O período de retenção de backup controla até onde uma restauração point-in-time pode ser recuperada, uma vez que 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 de uma perspetiva de restauração. Todos os backups necessários para executar uma restauração point-in-time 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 estiver definido como 7 dias, a janela de recuperação será considerada como últimos 7 dias. Nesse cenário, todos os backups necessários para restaurar o servidor nos últimos 7 dias são mantidos. Com uma janela de retenção de backup de sete dias:

  • Servidores com até 4 TB de armazenamento reterão até 2 backups completos de banco de dados, todos os backups diferenciais e backups de log de transações executados desde o primeiro backup completo de banco de dados.
  • 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 nos últimos 8 dias.

opções de redundância de cópia de segurança

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

Importante

Só é permitido configurar o armazenamento localmente redundante ou georredundante para cópias de segurança durante a criação do servidor. Assim que o servidor tiver sido aprovisionado, não poderá alterar a opção de redundância do armazenamento de cópias de segurança.

Custo de armazenamento de cópias de segurança

O Banco de Dados do Azure para PostgreSQL fornece até 100% do seu armazenamento de servidor provisionado como armazenamento de backup sem custo extra. Qualquer armazenamento de backup adicional usado é cobrado em GB por mês. Por exemplo, se você provisionou um servidor com 250 GB de armazenamento, você tem 250 GB de armazenamento adicional disponível para backups do servidor sem custo extra. O armazenamento consumido para backups com mais de 250 GB é cobrado de acordo com o modelo de preços.

Você pode 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 de armazenamento de backup usada representa a soma do armazenamento consumido por todos os backups completos 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 explicada anteriormente. Uma atividade transacional intensa no servidor pode aumentar a utilização do armazenamento de cópias de segurança, independentemente do tamanho total da base de dados. Para armazenamento com redundância geográfica, o uso do armazenamento de backup é duas vezes maior do que o armazenamento com redundância local.

O principal meio de controlar o custo do armazenamento de backup é definir o período de retenção de backup apropriado e escolher as opções corretas de redundância de backup para atender às metas de recuperação desejadas. Você pode selecionar um período de retenção de um intervalo de 7 a 35 dias. Os servidores de uso geral e otimizados para memória podem optar por ter armazenamento com redundância geográfica para backups.

Restauro

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

Existem dois tipos de restauração disponíveis:

  • A restauração point-in-time está disponível com qualquer opção de redundância de backup e cria um novo servidor na mesma região do servidor original.
  • O Restauro Geográfico apenas está disponível se tiver configurado o servidor para o armazenamento georredundante e permite-lhe restaurar o servidor para uma região diferente.

O tempo estimado de recuperação depende de vários fatores, incluindo o tamanho da base de dados, o tamanho do registo de transações, a largura de banda da rede e o número total de bases de dados a recuperar na mesma região 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 é menos de 12 horas.

Nota

Se o servidor PostgreSQL de origem estiver encriptado com chaves geridas pelo cliente, veja a documentação para obter considerações adicionais.

Nota

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

Restauro para um ponto anterior no tempo

Independentemente da opção de redundância de backup, você pode executar uma restauração em qualquer point-in-time dentro do período de retenção de backup. Um novo servidor é criado na mesma região do Azure que o servidor original. Ele é criado com a configuração do servidor original para a camada de preço, geração de computação, número de vCores, tamanho do armazenamento, período de retenção de backup e opção de redundância de backup.

A restauração point-in-time é útil em vários cenários. Por exemplo, quando um usuário exclui dados acidentalmente, descarta uma tabela ou banco de dados importante ou se um aplicativo substitui acidentalmente dados bons por dados incorretos devido a um defeito do aplicativo.

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

Se você quiser restaurar uma tabela descartada,

  1. Restaure o servidor de origem usando o método Point-in-time.
  2. Despeje a 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.

Nota

Recomenda-se não criar várias restaurações para o mesmo servidor ao mesmo tempo.

Restauro geográfico

Você pode restaurar um servidor para outra região do Azure onde o serviço está disponível se tiver configurado seu servidor para backups com redundância geográfica. Os servidores que suportam até 4 TB de armazenamento podem ser restaurados para a região emparelhada geograficamente ou para qualquer região que suporte até 16 TB de armazenamento. Para servidores que suportam até 16 TB de armazenamento, os backups geográficos também podem ser restaurados em qualquer região que suporte servidores de 16 TB. Consulte as camadas de preços do Banco de Dados do Azure para PostgreSQL para obter 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 onde o servidor está hospedado. Se um incidente em grande escala em uma região resultar na indisponibilidade do seu aplicativo de banco de dados, você poderá restaurar um servidor dos backups 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 para uma região diferente. Esse atraso pode ser de até uma hora, portanto, se ocorrer um desastre, pode haver perda de dados de até uma hora.

Durante o restauro geográfico, as configurações do servidor que podem ser alteradas incluem a geração de computação, vCore, período de retenção e opções de redundância de cópias de segurança. Não há suporte para alterar o nível de preço (Básico, Uso Geral ou Otimizado para memória) ou o tamanho do armazenamento.

Nota

Se o servidor de origem usa criptografia dupla de infraestrutura, para restaurar o servidor, há limitações, incluindo regiões disponíveis. Consulte a criptografia dupla da infraestrutura para obter mais detalhes.

Executar tarefas pós-restauração

Após uma restauração de qualquer mecanismo de recuperação, você deve executar as seguintes tarefas para que seus usuários e aplicativos voltem a funcionar:

  • 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 sua cadeia de username@new-restored-server-name conexão.

  • Se o novo servidor quiser substituir o servidor original, redirecione os clientes e as aplicações cliente para o novo servidor.

  • Verifique se o firewall no nível do servidor e as regras de rede virtual apropriadas estão em vigor para que os usuários se conectem. Essas regras não são copiadas do servidor original.

  • Verifique se os logins apropriados e as permissões no nível do banco de dados estão em vigor

  • Configurar alertas, conforme adequado

  • Retenção de longa duração

    Os serviços de servidor Backup do Azure e Banco de Dados do Azure para PostgreSQL criaram uma solução de backup de longo prazo de classe empresarial para instâncias de servidor único do Banco de Dados do Azure para PostgreSQL que retém backups por até 10 anos. Você pode usar a retenção de longo prazo de forma independente ou além da solução de backup automatizado oferecida pelo Banco de Dados do Azure para servidor único PostgreSQL, que oferece retenção de até 35 dias. Os backups automatizados são backups físicos adequados para recuperações operacionais, especialmente quando deseja restaurar a partir dos backups mais recentes. Os backups de longo prazo ajudam você com suas necessidades de conformidade, são mais granulares e são tomados como backups lógicos usando pg_dump nativas. Além da retenção a longo prazo, a solução oferece os seguintes recursos:

Cópias de segurança ad-hoc e agendadas controladas pelo cliente ao nível de bases de dados individuais. Monitorização central de todos os trabalhos e operações. Cópias de segurança armazenadas num domínio de segurança e falha separado. Se o servidor de origem ou a assinatura for comprometido, os backups permanecerão seguros no cofre de Backup (nas contas de armazenamento gerenciado do Backup do Azure). O uso do pg_dump permite maior flexibilidade na restauração de dados em diferentes versões de banco de dados. Os cofres de cópia de segurança do Azure suportam funcionalidades de imutabilidade e eliminação suave (pré-visualização), protegendo os seus dados.

  • Para obter mais informações sobre como executar um backup de longo prazo, visite o guia de instruções.
  • [Problemas de LTR conhecidos ].

Próximos passos

  • Saiba como restaurar usando o portal do Azure.
  • Saiba como restaurar usando a CLI do Azure.
  • Para saber mais sobre continuidade de negócios, consulte a visão geral de continuidade de negócios.