Backup e restauração no servidor flexível do Banco de Dados do Azure para PostgreSQL

Os backups são uma parte essencial de qualquer estratégia de continuidade de negócios. Eles ajudam a proteger os dados contra a corrupção ou exclusão acidental.

O Banco de Dados do Azure para PostgreSQL executa automaticamente backups regulares do servidor. Você pode, então, fazer uma PITR (recuperação pontual) dentro de um período de retenção especificado. O tempo geral para restaurar e recuperar normalmente depende do tamanho dos dados e da quantidade de recuperação a ser executada.

Visão geral do backup

O Banco de Dados do Azure para PostgreSQL faz backups de instantâneo de arquivos de dados e os armazena com segurança no armazenamento com redundância de zona ou armazenamento com redundância local, dependendo da região. O servidor também faz o backup dos logs de transações quando o arquivo WAL (log write-ahead) estiver pronto para ser arquivado. Use esses backups para restaurar um servidor a qualquer ponto no tempo dentro do período de retenção de backup configurado.

O período de retenção de backup padrão é de sete dias, mas você pode estender o período para um máximo de 35 dias. Todos os backups são criptografados por meio da criptografia AES de 256 bits para os dados inativos armazenados.

Você não pode exportar esses arquivos de backup ou usá-los para criar servidores fora de sua instância de servidor flexível Banco de Dados do Azure para PostgreSQL. Para essa finalidade, você pode usar as ferramentas do PostgreSQL pg_dump e pg_restore/psql.

Frequência de backup

Os backups em instâncias do servidor flexível do Banco de Dados do Azure para PostgreSQL baseiam-se em instantâneos. O primeiro backup de instantâneo é agendado imediatamente após a criação de um servidor. Atualmente, os backups de instantâneos são realizados uma vez ao dia, diariamente. Se você não fizer mais modificações em nenhum banco de dados no servidor após o último backup de instantâneo, o sistema suspenderá temporariamente os backups de instantâneo. Assim que você faz qualquer modificação em qualquer banco de dados no servidor, o sistema imediatamente cria um novo instantâneo para capturar as mudanças mais recentes. O primeiro instantâneo é um backup completo e instantâneos consecutivos são backups diferenciais.

Os backups de log de transações ocorrem a uma frequência variada, dependendo da carga de trabalho e de quando o arquivo WAL estiver preenchido e pronto para ser arquivado. Em geral, o atraso do RPO (objetivo de ponto de recuperação) pode ser de até cinco minutos.

Opções de redundância de backup

O Banco de Dados do Azure para PostgreSQL armazena várias cópias de seus backups para ajudar a proteger seus dados contra eventos planejados e não planejados. Esses eventos podem incluir falhas de hardware transitórias, falhas de rede ou energia e desastres naturais. A redundância de backup garante que seu banco de dados atenda suas metas de disponibilidade e durabilidade, mesmo na ocorrência de falhas.

O Banco de Dados do Azure para PostgreSQL oferece três opções:

• Armazenamento de backup com redundância entre zonas: o Banco de Dados do Azure para PostgreSQL seleciona automaticamente essa opção para regiões que oferecem suporte a zonas de disponibilidade. Quando você armazena backups no armazenamento de backup com redundância de zona, o serviço mantém três cópias dos dados dentro da zona de disponibilidade em que o servidor está hospedado. Além disso, o serviço replica os dados para outra zona de disponibilidade para proteção adicional.

  Essa opção fornece disponibilidade de dados de backup entre zonas de disponibilidade e restringe a replicação de dados para dentro de um país ou região para atender aos requisitos de residência de dados. Ele oferece pelo menos 99,9999999999% de durabilidade dos objetos de backup ao longo de um ano.

• Armazenamento de backup com redundância local: Banco de Dados do Azure para PostgreSQL seleciona automaticamente essa opção para regiões que ainda não dão suporte a zonas de disponibilidade. Quando você armazena backups no armazenamento de backup com redundância local, o serviço armazena várias cópias de backups no mesmo datacenter.

  Essa opção ajuda a proteger seus dados contra falhas de rack e de unidade do servidor. Ela fornece pelo menos 99,999999999% de durabilidade (11 noves) de objetos de backups em um determinado ano.

  Por padrão, o serviço define o armazenamento de backup para servidores com alta disponibilidade (HA) na mesma zona ou sem configuração de alta disponibilidade como localmente redundante.

• Armazenamento de backup com redundância geográfica: você pode escolher essa opção no momento da criação do servidor. Ao armazenar backups em um armazenamento de backup georredundante, além de três cópias dos dados armazenadas na região onde o servidor está hospedado, o serviço replica os dados para uma região geograficamente correspondente.

  Essa opção fornece a capacidade de restaurar o servidor em uma região diferente em caso de desastre. Ela também fornece pelo menos 99,99999999999999% de durabilidade (16 noves) de objetos de backups em um determinado ano.

  Há suporte para redundância geográfica para servidores hospedados em qualquer uma das regiões emparelhadas do Azure.

Mudança de outras opções de backup para armazenamento de backup com redundância geográfica

Você pode configurar o armazenamento com redundância geográfica para backup somente durante a criação do servidor. Depois que o servidor estiver provisionado, você não poderá alterar a opção de redundância do armazenamento de backup.

Retenção de backup

O servidor retém backups com base no período de retenção definido. Você pode selecionar um período de retenção entre sete (padrão) e 35 dias. Defina o período de retenção durante a criação do servidor ou altere-o mais tarde. O servidor retém backups mesmo para servidores parados.

O período de retenção de backup determina o intervalo de tempo para recuperar uma restauração pontual (PITR) a partir dos backups disponíveis. Você também pode considerar o período de retenção de backup como uma janela de recuperação do ponto de vista da restauração.

O armazenamento de backup retém todos os backups necessários para executar um PITR durante o período de retenção de backups. Por exemplo, se você definir o período de retenção de backup como 7 dias, a janela de recuperação será os últimos 7 dias. Nesse cenário, o armazenamento de backup retém todos os dados e logs necessários para restaurar e recuperar o servidor nos últimos 7 dias.

Custo do armazenamento de backup

O Banco de Dados do Azure para PostgreSQL fornece até 100% do armazenamento do servidor provisionado como armazenamento de backup sem custo adicional. Você paga por qualquer armazenamento de backup extra usado em gigabytes por mês.

Por exemplo, se você provisionar um servidor com 250 gibibytes (GiB) de armazenamento, obterá 250 GiB de capacidade de armazenamento de backup sem custo adicional. Se o uso diário de backup for de 25 GiB, você poderá ter até 10 dias de armazenamento de backup gratuito. Você paga pelo consumo de armazenamento de backup que excede 250 GiB, conforme definido no modelo de preços.

Se você configurar o servidor com backup com redundância geográfica, os dados de backup também serão copiados para a região emparelhada Azure. Portanto, o tamanho do backup é o dobro do tamanho da cópia de backup local. A cobrança é calculada como ((2 x tamanho de backup local) – tamanho de armazenamento provisionado) x preço @ gigabytes por mês.

Use a métrica armazenamento de backup usado no portal Azure para monitorar o armazenamento de backup que um servidor consome. A métrica Armazenamento de Backup Usado representa a soma do armazenamento consumido por todos os backups de banco de dados e backups de log mantidos com base no período de retenção de backup definido para o servidor.

Recuperação pontual

Em uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, a execução de um PITR cria um novo servidor na mesma região que o servidor de origem, mas você pode escolher a zona de disponibilidade. Ele é criado com a configuração do servidor de origem para o tipo de preço, a geração da 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.

Os arquivos de banco de dados físicos são restaurados primeiro dos backups de instantâneo para o local de dados do servidor. O backup apropriado que foi feito antes do ponto desejado é automaticamente escolhido e restaurado. Então, inicia-se um processo de recuperação usando arquivos WAL para colocar o banco de dados em um estado consistente.

Por exemplo, vamos supor que os backups são executados às 23h todas as noites. Se o ponto de restauração for de 15 de agosto às 10h, o backup diário de 14 de agosto será restaurado. O banco de dados é restaurado até as 10h de 15 de agosto por meio do backup do log de transações de 14 de agosto, às 23h, até 15 de agosto, às 10h.

Para restaurar o servidor de banco de dados, consulte qualquer um dos seguintes:

• Restaurar para o ponto de restauração mais recente.
• Restaurar para o ponto de restauração personalizado.
• Restaurar para backup completo (restauração rápida).
• Restaurar para a região emparelhada (restauração geográfica).

O PITR é útil em cenários como estes:

• Um usuário exclui acidentalmente dados, uma tabela ou um banco de dados.
• Um aplicativo substitui acidentalmente os dados corretos por incorretos devido a um defeito no aplicativo.
• Você deseja clonar seu servidor para teste, desenvolvimento ou verificação de dados.

Ao usar o backup contínuo de logs de transações, você pode restaurar até a última transação. Você pode escolher uma das seguintes opções de restauração:

• Ponto de restauração mais recente (agora): essa é a opção padrão, que restaura o servidor para o ponto mais recente no tempo.

• Ponto de restauração personalizado: essa opção permite que você escolha um ponto dentro do período de retenção definido para esta instância do servidor flexível do Banco de Dados do Azure para PostgreSQL. Por padrão, a hora mais recente em UTC é selecionada automaticamente. A seleção automática é útil se você quiser restaurar para a última transação confirmada para fins de teste. Você tem a opção de escolher outros dias e horários.

• Ponto de restauração rápida: Esta opção restaura o servidor no menor tempo possível dentro do período de retenção definido para a instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. A restauração mais rápida é possível ao escolher diretamente a data e hora na lista de backups. Essa operação de restauração provisiona um servidor e apenas restaura o backup completo do snapshot. Ele não requer nenhuma recuperação de logs, o que o torna rápido. Selecione uma data e hora de backup posterior ao ponto de restauração mais antigo para que a operação de restauração seja bem-sucedida.

O tempo necessário para recuperação usando as opções de ponto de restauração mais recentes e personalizadas varia de acordo com fatores como o volume de logs de transações a serem processados desde o último backup e o número total de bancos de dados sendo recuperados simultaneamente na mesma região. O tempo de recuperação geral geralmente leva de alguns minutos até algumas horas.

Se você configurar seu servidor em uma rede virtual, poderá restaurar para a mesma rede virtual ou para uma rede virtual diferente. No entanto, não é possível restaurar para um acesso público. Da mesma forma, se você configurou o servidor com acesso público, não será possível restaurar o acesso à rede virtual privada.

Restauração e backup com redundância geográfica

Para habilitar o backup com redundância geográfica do painel Computação + armazenamento no portal do Azure, consulte Criar um Banco de Dados do Azure para PostgreSQL.

Depois de configurar o servidor com o backup com redundância geográfica, você poderá restaurá-lo para uma região emparelhada geograficamente. Para obter mais informações, consulte as regiões com suporte para backup com redundância geográfica.

Quando você configura o servidor com backup com redundância geográfica, os dados de backup e os logs de transação são copiados para a região emparelhada de forma assíncrona por meio da replicação de armazenamento. Após a criação do servidor, aguarde pelo menos uma hora antes de iniciar uma restauração geográfica. Esse período de espera permite que o primeiro conjunto de dados de backup seja replicado para a região emparelhada.

Posteriormente, os logs de transações e os backups diários são copiados de forma assíncrona para a região emparelhada. Pode ocorrer até uma hora de atraso na transmissão de dados. Portanto, você pode esperar até uma hora de RPO ao restaurar. Você só pode restaurar para os últimos dados de backup disponíveis que são disponibilizados na região emparelhada. Atualmente, o PITR de backups com redundância geográfica não está disponível.

O tempo estimado para recuperar o servidor RTO (objetivo de tempo de recuperação) depende de fatores como o tamanho do banco de dados, o horário do último backup do banco de dados e a quantidade de WAL a ser processado até os dados de backup recebidos mais recentes. Normalmente, o tempo de recuperação geral demora de alguns minutos até algumas horas.

Durante a restauração geográfica, você pode alterar as configurações do servidor que incluem as configurações de rede virtual e a capacidade de remover o backup com redundância geográfica do servidor restaurado. Não há suporte para alterar outras configurações do servidor — como computação, armazenamento ou camada de preço (Burstable, General Purpose ou Memory Optimized) — durante a restauração geográfica.

Para obter mais informações, confira a região Restaurar para região emparelhada (restauração geográfica).

Restauração e conexão de rede

Recuperação pontual

Se você configurar o servidor de origem com uma rede de acesso público , só poderá restaurar o acesso público.

Se você configurar o servidor de origem com uma rede virtual de acesso privado , poderá restaurar para a mesma rede virtual ou para uma rede virtual diferente. Não é possível executar a restauração pontual em acesso público e privado.

Restauração geográfica

Se você configurar o servidor de origem com uma rede de acesso público , só poderá restaurar o acesso público. Além disso, você deve aplicar regras de firewall após a conclusão da operação de restauração.

Se você configurar o servidor de origem com uma rede virtual de acesso privado , só poderá restaurar para uma rede virtual diferente, pois as redes virtuais não podem abranger regiões. Não é possível executar a restauração geográfica em acesso público e privado.

Tarefas de pós-restauração

Depois de restaurar o servidor, execute as seguintes tarefas para fazer com que seus usuários e aplicativos sejam executados novamente:

• Se o novo servidor substituir o servidor original, redirecione clientes e aplicativos cliente para o novo servidor. Altere o nome do servidor da cadeia de conexão para apontar para o novo servidor.

• Os valores de todos os parâmetros no servidor original não são aplicados automaticamente ao novo servidor. Verifique se você reconfigurou todos os parâmetros no novo servidor de acordo com os requisitos desse novo servidor.

• Verifique se as regras apropriadas de firewall no nível do servidor, os pontos de extremidade privados e as regras de rede virtual estão em vigor para as conexões dos usuários. Essas regras não são copiadas do servidor original.

• Aumente ou diminua a capacidade de processamento do servidor restaurado, conforme necessário.

• Verifique se os logons e as permissões de nível de banco de dados adequados estão em vigor.

• Configure os alertas conforme apropriado.

• Se o servidor de origem do qual você restaurou foi configurado com alta disponibilidade e deseja configurar o servidor restaurado com alta disponibilidade, siga estas etapas.

• Se o servidor de origem do qual você restaurou foi configurado com réplicas de leitura e deseja configurar réplicas de leitura no servidor restaurado, siga as instruções em Criar uma réplica de leitura.

Backups sob demanda

Sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL gera automaticamente snapshots de volumes de armazenamento de toda a sua instância de banco de dados, abrangendo todos os bancos de dados, como parte dos backups agendados. Além disso, você pode criar um backup sob demanda sempre que necessário. Essa opção é ideal para cenários como a preparação para uma operação potencialmente arriscada ou a execução de atualizações periódicas fora do agendamento de backup habitual.

Faça backups sob demanda além de backups automáticos agendados. A janela de retenção de backup determina quanto tempo manter esses backups. Você pode excluir backups sob demanda a qualquer momento se eles não forem mais necessários. Para iniciar um backup sob demanda, selecione a instância de banco de dados que você deseja fazer backup e especifique um nome de backup. Esses backups são armazenados junto com backups automatizados, mas somente os usuários podem excluir backups sob demanda. O serviço gerencia e retém backups automatizados para atender aos requisitos de retenção de backup.

Para obter mais informações, consulte Executar backups sob demanda.

Limitações

• A camada de computação de servidor intermitível não dá suporte ao recurso de backup sob demanda.
• A camada de armazenamento SSDv2 não dá suporte ao recurso de backup sob demanda.
• Você pode fazer até sete backups sob demanda por instância de servidor flexível. A janela de retenção de backup determina quanto tempo manter esses backups.

Retenção de longo prazo

Backup do Azure e serviços de Banco de Dados do Azure para PostgreSQL fornecem uma solução de backup de longo prazo de classe empresarial para Banco de Dados do Azure para PostgreSQL instâncias de servidor flexíveis que retém backups por até 10 anos. Você pode usar a LTR (retenção de longo prazo) independentemente ou ao lado da solução de backup automatizada oferecida pelo Banco de Dados do Azure para PostgreSQL, que oferece retenção de até 35 dias. Backups automatizados são backups físicos adequados para recuperações operacionais, especialmente quando você deseja restaurar a partir dos backups mais recentes. Os backups de longo prazo ajudam você a atender aos seus requisitos de conformidade, são mais detalhados e são realizados como backups lógicos usando o pg_dump nativo. Além da retenção de longo prazo, a solução oferece os seguintes recursos:

• Backups agendados e sob demanda controlados pelo cliente no nível do banco de dados individual.
• Monitoramento centralizado de todas as operações e trabalhos.
• Os backups são armazenados em domínios separados de segurança e falha. Se o servidor de origem ou a assinatura estiverem comprometidos, os backups permanecerão seguros no cofre de Backup (em contas de armazenamento gerenciadas do Backup do Azure).
• O uso de pg_dump oferece maior flexibilidade na restauração de dados em diferentes versões de banco de dados.
• Os cofres de backup do Azure dão suporte a recursos de imutabilidade e exclusão temporária (versão prévia), protegendo seus dados.
• Suporte de backup LTR para servidores habilitados para CMK.

Limitações e considerações

• Teste o backup e a restauração do LTR imediatamente após a configuração para garantir que eles atendam aos seus requisitos de negócios.
• No momento, as restaurações LTR estão disponíveis apenas como Restaurar como Arquivos para contas de armazenamento, com a funcionalidade Restaurar como Servidor planejada para o futuro.
• O LTR faz backup de todos os bancos de dados em instâncias de servidor flexíveis e você não pode selecionar bancos de dados individuais para a configuração de LTR.
• Não há suporte para backup ltr em réplicas, mas você pode executá-lo em servidores primários.
• O tamanho máximo de banco de dados com suporte para backups de LTR (Retenção de Longo Prazo) é 1 TiB.
• Você pode agendar backups LTR semanalmente, mensais ou anois. No momento, não há suporte para o agendamento diário de backup.
• Os backups LTR não dão suporte a tabelas que contêm uma linha com um comprimento BYTEA superior a 500 MB.
• Ao restaurar funções para Microsoft Entra usuários, verifique se Microsoft Entra autenticação está habilitada e se você está conectado como um administrador Microsoft Entra para criar usuários adicionais. A tentativa de criar funções do Entra como um usuário regular resulta em erros.

Para obter mais informações sobre como executar um backup de longo prazo, consulte o guia de instruções.

Perguntas frequentes

Perguntas relacionadas ao backup

• Como o Azure lida com o backup do meu servidor?

  Por padrão, Banco de Dados do Azure para PostgreSQL habilita backups automatizados de todo o servidor (abrangendo todos os bancos de dados criados) com um período de retenção padrão de sete dias. Os backups automatizados incluem um instantâneo incremental diário do banco de dados. Os arquivos de logs (WAL) são arquivados continuamente no Armazenamento de Blobs do Azure.

• Posso configurar backups automatizados para manter os dados a longo prazo?

  Não. Atualmente, o Banco de Dados do Azure para PostgreSQL dá suporte a um máximo de 35 dias de retenção. Use backups manuais para um requisito de retenção de longo prazo usando Backup do Azure.

• Como fazer backup manualmente das minhas instâncias do servidor flexível do Banco de Dados do Azure para PostgreSQL?

  Você pode tirar manualmente um instantâneo físico usando o recurso de backup sob demanda. Você também pode fazer backups lógicos usando a ferramenta PostgreSQL pg_dump. Para obter exemplos, consulte Migrar seu banco de dados do Banco de Dados do Azure para PostgreSQL usando despejo e restauração.

• Quais são as janelas de backup para o meu servidor? Posso personalizá-las?

  O Azure gerencia as janelas de backup e você não pode personalizá-las. O primeiro backup de instantâneo completo é agendado imediatamente após a criação de um servidor. Backups de instantâneo subsequentes são incrementais e ocorrem uma vez por dia.

• Meus backups são criptografados?

  Sim. Todos os dados de instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, backups e arquivos temporários criados durante a execução da consulta são criptografados por meio da criptografia de 256 bits do AES (Advanced Encryption Standard). A criptografia de armazenamento está sempre ativada e não pode ser desabilitada.

• Posso restaurar um banco de dados individual ou alguns bancos de dados em um servidor?

  Não há suporte direto para restaurar um banco de dados individual ou alguns bancos de dados ou tabelas. No entanto, você pode restaurar o servidor inteiro em um novo servidor e excluir tabelas ou bancos de dados que não precisa no novo servidor.

• Meu servidor está disponível enquanto o backup está em andamento?

  Sim. Backups são operações online que usam instantâneos. A operação de instantâneo leva apenas alguns segundos e não interfere nas cargas de trabalho de produção para ajudar a garantir a alta disponibilidade do servidor.

• Ao configurar a janela de manutenção do servidor, preciso levar em conta a janela de backup?

  Não. Os backups são disparados internamente como parte do serviço gerenciado e não têm nenhuma influência na janela de manutenção.

• Onde meus backups automatizados são armazenados e como gerencio a retenção deles?

  Sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL cria automaticamente backups de servidor e os armazena em:

  • Armazenamento com redundância de zona, em regiões em que há suporte para várias zonas.
  • Armazenamento com redundância local, em regiões que ainda não dão suporte a várias zonas.
  • A região emparelhada, se você configurou o backup com redundância geográfica.

  Você não pode exportar esses arquivos de backup, pois eles são armazenados em contas de armazenamento gerenciadas por Microsoft. Você tem acesso somente leitura para restaurar esses arquivos, mas não pode modificá-los ou excluí-los. Os arquivos de backup são excluídos automaticamente após o período de retenção.

  Você pode usar backups para restaurar o servidor para um ponto específico no tempo. O período de retenção de backup padrão é de sete dias. Opcionalmente, você pode configurar a retenção de backup por até 35 dias.

• Com o backup com redundância geográfica, com que frequência o backup é copiado para a região emparelhada?

  Quando você configura o servidor com backup com redundância geográfica, os dados de backup são armazenados em uma conta de armazenamento com redundância geográfica. A conta de armazenamento copia os arquivos de dados para a região emparelhada quando o backup diário ocorre no servidor primário. Os arquivos WAL são armazenados em backup assim estiverem prontos para serem arquivados.

  Os dados de backup são continuamente copiados de forma assíncrona para a região emparelhada. Você pode esperar até uma hora de atraso ao receber dados de backup.

• Posso fazer PITR na região remota?

  Não. Os dados são recuperados até o backup mais recente disponível na região remota.

• Como os backups são realizados em servidores habilitados para HA?

  Os volumes de dados em uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL têm backup por meio de instantâneos incrementais de disco gerenciado do servidor primário. O backup WAL é realizado a partir do servidor primário ou do servidor em espera.

• Como posso validar que os backups são realizados em meu servidor?

  A melhor maneira de verificar os backups é executar restaurações pontuais periódicas e garantir que eles sejam válidos e restauráveis. Operações ou arquivos de backup não são expostos aos usuários finais.

• Onde posso ver o uso do backup?

  No portal do Azure, em Monitoramento, selecione Métricas. Em Armazenamento de Backup Usado, você pode monitorar o uso de backup total.

• O que acontece com meus backups se eu excluir meu servidor?

  Se você excluir um servidor, todos os backups que pertencem ao servidor também serão excluídos e não poderão ser recuperados. Para ajudar a proteger recursos do servidor de exclusão acidental ou de alterações inesperadas após implantações, os administradores podem usar bloqueios de gerenciamento.

• Como os backups são retidos nos servidores parados?

  Não são executados backups novos de servidores interrompidos. O serviço retém todos os backups mais antigos (dentro da janela de retenção) no momento da interrupção do servidor até que o servidor seja reiniciado. Depois disso, a retenção de backup para o servidor ativo é regida por sua janela de retenção.

• Como são cobrados e faturados os meus backups?

  O Banco de Dados do Azure para PostgreSQL fornece até 100% do armazenamento do servidor provisionado como armazenamento de backup sem custo adicional. Você paga por qualquer armazenamento de backup adicional usado, que é cobrado em gigabytes por mês, conforme definido no modelo de preços.

  O período de retenção de backup e a opção de redundância de backup que você seleciona, juntamente com atividade transacional no servidor, afetam diretamente o armazenamento de backup total e a cobrança.

• Como sou cobrado por um servidor parado?

  Enquanto a instância do servidor está interrompida, nenhum backup novo é realizado. Você paga pelo armazenamento provisionado e pelo armazenamento de backup (backups armazenados na janela de retenção especificada).

  O armazenamento de backup gratuito é limitado ao tamanho do banco de dados provisionado. Você paga por qualquer excesso de dados de backup de acordo com o preço do backup.

• Configurei meu servidor com alta disponibilidade com redundância de zona. Você considera isso como dois backups e serei cobrado duas vezes?

  Não. Independentemente de serem servidores HA ou não HA, o serviço mantém apenas um conjunto de cópias de backup. Você paga apenas uma vez.

Perguntas relacionadas à restauração

• Como fazer a restauração do meu servidor?

  O Azure dá suporte a restauração pontual para todos os servidores. Você pode restaurar para o ponto de restauração mais recente ou um ponto de restauração personalizado usando o portal Azure, o CLI do Azure e a API.

  Para restaurar seu servidor de backups manuais usando ferramentas comopg_dump, primeiro, você pode criar uma instância de servidor Banco de Dados do Azure para PostgreSQL flexível e, em seguida, restaurar seus bancos de dados para o servidor usando pg_restore.

• Posso restaurar para outra zona de disponibilidade dentro da mesma região?

  Sim. Se a região dá suporte a várias zonas de disponibilidade, o backup é armazenado em uma conta de armazenamento com redundância de zona para que você restaure para outra zona.

• Quanto tempo leva uma restauração pontual? Por que a minha restauração está demorando tanto?

  A operação de restauração de dados de um instantâneo não depende do tamanho dos dados. Mas o tempo do processo de recuperação que aplica os logs (atividades de transação a serem reproduzidas) pode variar, dependendo do backup anterior da data e hora solicitadas e do número de logs a serem processados. Essa condição se aplica tanto à restauração dentro da mesma zona quanto à restauração de dados para uma zona diferente.

• Se eu restaurar meu servidor habilitado para HA, o servidor de restauração será configurado automaticamente com alta disponibilidade?

  Não. O servidor é restaurado como uma instância única do servidor flexível do Banco de Dados do Azure para PostgreSQL. Após a conclusão da restauração, opcionalmente, você pode configurar o servidor com alta disponibilidade.

• Configurei meu servidor em uma rede virtual. Posso restaurar para outra rede virtual?

  Sim. No momento da restauração, escolha uma rede virtual diferente para a qual restaurar.

• Posso restaurar meu servidor de acesso público para uma rede virtual ou vice-versa?

  Não. Atualmente, o Banco de Dados do Azure para PostgreSQL não dá suporte à restauração de servidores em acesso público e privado.

• Como faço para acompanhar minha operação de restauração?

  Atualmente, não há nenhuma maneira de acompanhar a operação de restauração. Você pode monitorar o log de atividades para ver se a operação está em andamento ou foi concluída.

Conteúdo relacionado

• Restaurar para o ponto de restauração mais recente.
• Restaurar para o ponto de restauração personalizado.
• Restaurar para backup completo (restauração rápida).
• Restaurar para a região emparelhada (restauração geográfica).