Compartilhar via

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

  • Artigo

APPLIES TO: Banco de Dados do Azure para PostgreSQL - Servidor Flexível

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

O servidor flexível do 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. Normalmente, o tempo geral de restauração e recuperação depende do tamanho dos dados e do volume da recuperação a ser realizada.

Visão geral do backup

O servidor flexível do Banco de Dados do Azure para PostgreSQL faz backups de instantâneos dos arquivos de dados e, em seguida, os armazena com segurança no armazenamento com redundância de zona ou no 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. É possível usar esses backups para restaurar um servidor para qualquer momento específico dentro de seu período de retenção de backup configurado.

O período de retenção de backup padrão é de 7 dias, mas você pode estendê-lo 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.

Esses arquivos de backup não podem ser exportados ou usados para criar servidores fora do servidor flexível do 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 nenhuma outra modificação for feita em bancos de dados no servidor após o último backup de instantâneo, os backups de instantâneo serão temporariamente suspensos. Assim que um banco de dados no servidor é modificado, um novo instantâneo é imediatamente tirado para capturar as alterações 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 RPO (objetivo de ponto de recuperação) de atraso pode ser de até 5 minutos.

Opções de redundância de backup

O servidor flexível do Banco de Dados do Azure para PostgreSQL armazena várias cópias de seus backups para ajudar a proteger os 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 servidor flexível do Banco de Dados do Azure para PostgreSQL oferece três opções:

  • Armazenamento de backup com redundância de zona: esta opção é escolhida automaticamente para regiões que dão suporte a zonas de disponibilidade. Quando os backups são armazenados no armazenamento de backup com redundância geográfica, três cópias dos dados são mantidas na região em que o servidor está hospedado. Além disso, os dados são replicados para uma região emparelhada 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/região para atender aos requisitos de residência de dados. Essa opção fornece pelo menos 99,9999999999% de durabilidade (12 noves) de objetos de backup em um determinado ano.

  • Armazenamento de backup com redundância local: esta opção é escolhida automaticamente para regiões que ainda não dão suporte a zonas de disponibilidade. Quando os backups são armazenados no armazenamento de backup com redundância local, várias cópias de backups são armazenadas no mesmo datacenter.

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

    Por padrão, o armazenamento de backup para servidores com HA (alta disponibilidade) na mesma zona ou nenhuma configuração de alta disponibilidade é definida como com redundância local.

  • Armazenamento de backup com redundância geográfica: você pode escolher essa opção no momento da criação do servidor. Quando os backups são armazenados no armazenamento de backup com redundância geográfica, além das três cópias de dados armazenados dentro da região em que o servidor está hospedado, os dados são replicados em sua região emparelhada geograficamente.

    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.

Mover de outras opções de armazenamento de backup para o 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

Os backups são mantidos com base no período de retenção configurado para o servidor. Você pode selecionar um período de retenção entre sete (padrão) e 35 dias. Você pode definir o período de retenção durante a criação do servidor ou pode alterá-lo posteriormente. Os backups são mantidos até mesmo para servidores interrompidos.

O período de retenção de backup rege o período de tempo do qual um PITR pode ser recuperado usando os backups disponíveis. Você também pode tratar o período de retenção de backup 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 sete dias, a janela de recuperação será os últimos sete dias. Nesse cenário, todos os dados e logs necessários para restaurar e recuperar o servidor nos últimos sete dias são mantidos.

Custo do armazenamento de backup

O servidor flexível do Banco de Dados do Azure para PostgreSQL fornece até 100% de seu armazenamento de servidor provisionado como armazenamento de backup sem custo adicional. Todo armazenamento de backup extra usado é cobrado em gigabytes por mês.

Por exemplo, se você tiver provisionado um servidor com 250 GiB (gibibytes) de armazenamento, terá 250 GiB de capacidade de armazenamento de backup sem mais custos. Se o uso diário do backup for 25 GiB, você poderá ter até dez dias de armazenamento de backup gratuito. O consumo de armazenamento de backup que exceda 250 GiB é cobrado conforme definido no modelo de preços.

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

Você pode usar a métrica Armazenamento de backup usado no portal do 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.

Observação

Independentemente do tamanho do banco de dados, a atividade transacional pesada no servidor gera mais arquivos WAL. O aumento nos arquivos, por sua vez, aumenta o armazenamento de backup.

Recuperação pontual

No servidor flexível do Banco de Dados do Azure para PostgreSQL, a execução de uma restauração pontual 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 será recuperado até as 10h do dia 15 de agosto usando o backup de logs de transações de 14 de agosto às 23h até 15 de agosto às 10h.

Para restaurar o servidor de banco de dados, confira essas etapas.

Importante

Uma operação de restauração no servidor flexível do Banco de Dados do Azure para PostgreSQL sempre cria um novo servidor de banco de dados com o nome que você fornecer. Ela não substitui o servidor de banco de dados existente.

A restauração pontual é ú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.

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

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

  • 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ápido: essa opção permite que os usuários restaurem o servidor no tempo mais rápido possível, dentro do período de retenção definido para instância do servidor flexível do Banco de Dados do Azure para PostgreSQL. A restauração mais rápida é possível com a escolha direta do carimbo de data/hora na lista de backups. Essa operação de restauração provisiona um servidor e, simplesmente, restaura o backup completo do instantâneo e não exige recuperação de logs, fazendo com que ele fique rápido. Recomendamos que você selecione um carimbo de data/hora de backup que seja maior do que o ponto de restauração mais antigo no tempo para uma operação de restauração bem-sucedida.

O tempo necessário para se recuperar 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.

Importante

Servidores excluídos podem ser restaurados. Se excluir o servidor, você poderá seguir nossas diretrizes em Restaurar um Banco de Dados do Azure para PostgreSQL removido – Servidor Flexível para recuperá-lo. Use o bloqueio de recursos do Azure para ajudar a evitar a exclusão acidental do seu servidor.

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

Para habilitar o backup com redundância geográfica no painel Computação + armazenamento no portal do Azure, consulte o Guia de início rápido.

Importante

O backup com redundância geográfica só pode ser configurado no momento da criação do servidor.

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 o servidor é configurado com o backup com redundância geográfica, os dados de backup e os logs de transações 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. Isso 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, a restauração pontual de backups com redundância geográfica não está disponível.

O tempo estimado para recuperar o RTO (objetivo de tempo de recuperação) de servidor depende de fatores como o tamanho do banco de dados, a última hora de backup do banco de dados e a quantidade de WAL para processar até os últimos dados de backup recebidos. Normalmente, o tempo de recuperação geral demora de alguns minutos até algumas horas.

Durante a restauração geográfica, as configurações de servidor que podem ser alteradas incluem configurações da rede virtual e a capacidade de remover o backup com redundância geográfica do servidor restaurado. Não há suporte para a alteração de outras configurações de servidor, como computação, armazenamento ou tipo de preço (com capacidade de intermitência, uso geral ou otimizado para memória) durante a restauração geográfica.

Para obter mais informações sobre como executar uma restauração geográfica, consulte o Guia de instruções.

Importante

Quando a região primária está inativa, você não pode criar servidores com redundância geográfica na respectiva região emparelhada geograficamente, pois o armazenamento não pode ser provisionado na região primária. Antes de provisionar servidores com redundância geográfica na região emparelhada geograficamente é necessário aguardar que a região primária fique ativa.

Com a região primária inoperante, ainda é possível restaurar geograficamente o servidor de origem para a região emparelhada geograficamente. Para obter mais informações sobre como executar uma restauração geográfica, consulte o Guia de instruções. Você deve usar réplicas geográficas como sua estratégia de DR (recuperação de desastre) se precisar configurar a DR para qualquer região ou se a região primária não der suporte a backups com redundância geográfica

Restauração e rede

Recuperação pontual

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

Se o servidor de origem estiver configurado com uma rede virtual de acesso privado, você 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 o servidor de origem estiver configurado com uma rede de acesso público, você só poderá restaurar para um acesso público. As regras de firewall existentes no servidor de origem são copiadas para o servidor restaurado. Os pontos de extremidade privados não são retomados. Após a conclusão da operação de restauração, verifique se você precisa ajustar qualquer regra de firewall transferida e crie os pontos de extremidade privados dos quais poderá precisar.

Se o servidor de origem estiver configurado com uma rede virtual de acesso privado, você 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

Após a restauração do servidor, você deverá executar as seguintes tarefas para colocar os usuários e os aplicativos novamente em execução:

  • Se o novo servidor for usado para 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 de servidor no servidor original não são aplicados automaticamente ao novo servidor. Verifique se todos os parâmetros de servidor no novo servidor estão reconfigurados conforme os requisitos desse novo servidor.

  • Verifique se as regras adequadas de firewall, pontos de extremidade privados e rede virtual no nível do servidor estão implementadas para as conexões dos usuários. Na rede de acesso público, as regras são copiadas do servidor original, mas podem não ser as exigidas no ambiente restaurado. Portanto, ajuste-as de acordo com seus requisitos. Os pontos de extremidade privados não são transferidos. Crie quaisquer pontos de extremidade privados que possam ser necessários no servidor restaurado. Na rede virtual de acesso privado, a restauração não copia nenhum artefato de infraestrutura de rede da origem para as redes do servidor restaurado. Tudo o que for relacionado à configuração de VNET (Rede Virtual), sub-redes ou Grupos de Segurança de Rede deve ser tratado como uma tarefa pós-restauração.

  • Escale ou reduza verticalmente a computação 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 você deseja configurar o servidor restaurado com alta disponibilidade, você poderá seguir essas etapas.

  • Se o servidor de origem do qual você restaurou foi configurado com réplicas de leitura e você deseja configurar réplicas de leitura no servidor restaurado, você pode seguir essas etapas.

Backups sob demanda (versão prévia)

O servidor flexível do Banco de Dados do Azure para PostgreSQL gera automaticamente instantâneos de volume de armazenamento de toda a instância do banco de dados, abrangendo todos os bancos de dados, como parte de seus backups agendados. Além disso, é possível criar um backup sob demanda sempre que necessário, o que é ideal em 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.

Backups sob demanda podem ser feitos de forma adicional aos backups automáticos agendados. Esses backups são mantidos de acordo com a janela de retenção de backup. Você pode excluir esses backups sob demanda a qualquer momento se eles não forem mais necessários. Para iniciar um backup sob demanda, basta selecionar a instância de banco de dados que deseja fazer backup e especificar um nome de backup. Esses backups são armazenados junto aos backups automatizados, mas somente backups sob demanda podem ser excluídos pelos usuários, pois os backups automatizados são gerenciados e mantidos pelo serviço do servidor flexível para atender aos requisitos de retenção de backup.

Para mais informações sobre como realizar um backup sob demanda, visite o guia de instruções.

Limitações

Não há suporte para o recurso Backup sob demanda com a camada de computação do servidor com capacidade de intermitência.

Problemas conhecidos

Estamos cientes de um bug existente que permite fazer backups sob demanda em Réplicas, embora a Restauração Pontual (PITR) não tenha suporte nesse contexto. Esse problema será resolvido para garantir que os backups sob demanda só possam ser realizados no servidor Primário.

Retenção de longo prazo (versão prévia)

O Backup do Azure e os serviços do servidor flexível do Banco de Dados do Azure para PostgreSQL criaram uma solução de backup de longo prazo de classe empresarial para instâncias do servidor flexível do Banco de Dados do Azure para PostgreSQL que retêm backups por até 10 anos. Você pode usar a LTR (retenção de longo prazo) de forma independente ou de forma adicional à solução de backup automatizada oferecida pelo servidor flexível do 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. Backups de longo prazo ajudam você com suas necessidades de conformidade, são mais granulares e são usados como backups lógicos usando 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.
  • Backups armazenados em domínios separados de falha e segurança. 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).
  • Usar pg_dump permite 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

  • As restaurações LTR estão atualmente disponíveis apenas como "Restaurar como Arquivos" para contas de armazenamento, com a funcionalidade de "Restaurar como Servidor" planejada para o futuro.
  • O LTR faz backup de todos os bancos de dados em instâncias de servidor flexível, e bancos de dados individuais não podem ser selecionados para configuração de LTR.
  • Não há suporte para backup LTR em réplicas geográficas, mas pode ser realizado de servidores primários.
  • O tamanho máximo de banco de dados com suporte para backups de Retenção de Longo Prazo (LTR) é 4 TiB. Embora seja possível tentar fazer backup em servidores com mais de 4 TiB, eles não são oficialmente compatíveis, e o sucesso dos backups LTR para esses servidores não pode ser garantido.
  • Os backups LTR podem ser agendados semanalmente, mensalmente ou anualmente. No momento, não há suporte para o agendamento de backup diário.

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

Perguntas frequentes

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

    Por padrão, o servidor flexível do Banco de Dados do Azure para PostgreSQL permite backups automatizados de todo o servidor (abrangendo todos os bancos de dados criados) com 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 servidor flexível do Banco de Dados do Azure para PostgreSQL dá suporte a um máximo de 35 dias de retenção. Você pode utilizar backups manuais para um requisito de retenção de longo prazo com o 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 fazer um instantâneo físico manualmente usando o recurso de backup sob demanda, e também pode fazer backups lógicos usando a ferramenta pg_dump do PostgreSQL. Para obter exemplos, confira Migrar seu banco de dados do servidor flexível 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, backups e arquivos temporários do servidor flexível do Banco de Dados do Azure para PostgreSQL criados durante a execução da consulta são criptografados por meio da AES (criptografia AES) de 256 bits. 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 a restauração de 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?

    O servidor flexível do Banco de Dados do Azure para PostgreSQL cria backups do servidor automaticamente e armazena-os 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.

    Esses arquivos de backup não podem ser exportados.

    Você pode usar backups para restaurar o servidor apenas pontualmente. 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 o servidor é configurado 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 para os últimos dados de backup disponíveis na região remota.

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

    O backup dos volumes de dados no servidor flexível do Banco de Dados do Azure para PostgreSQL é feito por meio de instantâneos incrementais de disco gerenciado no 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. Os arquivos ou operações de backup não ficam 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. Todos os backups mais antigos (dentro da janela de retenção) no momento da interrupção do servidor são mantidos 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 eu vou ser cobrado e pagarei pelos meus backups?

    O servidor flexível do Banco de Dados do Azure para PostgreSQL fornece até 100% de seu armazenamento de servidor provisionado como armazenamento de backup sem custo adicional. Qualquer armazenamento de backup adicional que você usar será 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 eu vou ser cobrado por um servidor parado?

    Enquanto a instância do servidor está interrompida, nenhum backup novo é realizado. Você é cobrado 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. Todos os dados de backup em excesso serão cobrados de acordo com o preço de 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 os servidores serem de HA ou não, apenas um conjunto de cópias de backup é mantido. Você será cobrado apenas uma vez.

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

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

    Para restaurar seu servidor dos backups manuais usando ferramentas como o pg_dump, você pode criar primeiro uma instância do servidor flexível do Banco de Dados do Azure para PostgreSQL e, então, restaurar seus bancos de dados no servidor usando o 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 transacionais a serem repetidas) pode variar, dependendo do backup anterior da data/hora solicitada e o número de logs a serem processados. Isso é aplicável à restauração dentro da mesma zona ou à 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 servidor flexível do Banco de Dados do Azure para PostgreSQL não dá suporte para a restauração de servidores em acesso público e privado.

  • Como fazer 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.

Próximas etapas