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

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

O Banco de Dados do Azure para PostgreSQL executa automaticamente backups regulares do seu servidor. Em seguida, podes realizar uma recuperação no ponto no tempo (PITR) dentro de um período de retenção que especifiques. O tempo total de restauro e recuperação depende tipicamente do tamanho dos dados e da quantidade de recuperação a realizar.

Descrição geral da Cópia de Segurança

O Banco de Dados do Azure para PostgreSQL faz backups instantâneos de arquivos de dados e os armazena com segurança em armazenamento com redundância de zona ou armazenamento com redundância local, dependendo da região. O servidor também faz cópias de segurança dos registos de transações quando o ficheiro de log de escrita prévia (WAL) está pronto para ser arquivado. Use estes backups para restaurar um servidor em qualquer momento dentro do seu período de retenção de backups configurado.

O período padrão de retenção de cópias de segurança é de sete dias, mas pode estendê-lo até um máximo de 35 dias. Todos os backups são criptografados através de criptografia AES de 256 bits para dados armazenados em repouso.

Não pode exportar estes ficheiros de backup nem usá-los para criar servidores fora da sua instância flexível do Base de Dados do Azure para PostgreSQL. Para isso, você pode usar as ferramentas PostgreSQL pg_dump e pg_restore/psql.

Frequência de backup

Os backups no Banco de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL são baseados em instantâneo. A primeira cópia de segurança de imagem é agendada imediatamente após a criação do servidor. Atualmente, as cópias de segurança de instantâneos são tiradas uma vez, diariamente. Se não fizer quaisquer modificações adicionais a quaisquer bases de dados do servidor após o último backup de snapshot, o sistema suspende temporariamente os backups de snapshot. Assim que modifica qualquer base de dados no servidor, o sistema tira imediatamente um novo snapshot para captar as alterações mais recentes. O primeiro snapshot é um backup completo e snapshots consecutivos são backups diferenciais.

As cópias de segurança dos registos de transações acontecem em frequências variadas, dependendo da carga de trabalho e de quando o ficheiro WAL está preenchido e pronto para ser arquivado. Em geral, o RPO de atraso (objetivo do ponto de recuperação) pode chegar a 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 transitórias de hardware, quedas de rede ou de energia e desastres naturais. A redundância de backup ajuda a garantir que seu banco de dados atenda às metas de disponibilidade e durabilidade, mesmo se ocorrerem falhas.

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

• Armazenamento de backup redundante por zonas: O Base de Dados do Azure para PostgreSQL seleciona automaticamente esta opção para regiões que suportam zonas de disponibilidade. Quando armazena backups em armazenamento redundante de zona, o serviço mantém três cópias dos dados dentro da zona de disponibilidade onde o seu servidor está alojado. Além disso, o serviço replica os dados para outra zona de disponibilidade para maior proteção.

  Esta opção oferece disponibilidade de dados de backup entre as zonas de disponibilidade e restringe a replicação dos dados dentro de um país ou região para cumprir os requisitos de residência de dados. Proporciona pelo menos 99,99999999999 por cento (12 noves) de durabilidade dos objetos de reserva ao longo de um ano.

• Armazenamento de backup redundante localmente: O Base de Dados do Azure para PostgreSQL seleciona automaticamente esta opção para regiões que ainda não suportam zonas de disponibilidade. Quando armazena backups em armazenamento de backup redundante localmente, o serviço armazena múltiplas cópias de backup no mesmo datacenter.

  Essa opção ajuda a proteger seus dados contra falhas de rack e unidade do servidor. Ele garante uma durabilidade de pelo menos 99,999999999% (11 noves) dos objetos de backup ao longo de um ano.

  Por predefinição, o serviço configura o armazenamento de cópias de segurança para servidores com alta disponibilidade (HA) na mesma zona ou sem configuração de alta disponibilidade como armazenamento localmente redundante.

• Armazenamento de backup com redundância geográfica: você pode escolher essa opção no momento da criação do servidor. Quando armazena cópias de segurança em armazenamento de cópias de segurança com georredundância, além das três cópias dos dados armazenadas na região onde o seu servidor está alojado, o serviço replica os dados para uma região emparelhada geograficamente.

  Esta opção permite-lhe restaurar o servidor numa região diferente em caso de desastre. Ele também fornece pelo menos 99,99999999999999 por cento (16 noves) de durabilidade de objetos de backup ao longo de um ano.

  A redundância geográfica é suportada para servidores alojados em qualquer uma das regiões emparelhadas do Azure.

Mudança de outras opções de armazenamento 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 um servidor é provisionado, não é possível alterar a opção de redundância de armazenamento de backup.

Retenção de backup

O servidor mantém backups com base no período de retenção que definiste. Você pode selecionar um período de retenção entre 7 (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 mantém backups mesmo para servidores parados.

O período de retenção das cópias de segurança determina o intervalo de tempo para efetuar um restauro para um ponto específico no tempo (PITR) a partir das cópias de segurança disponíveis. Também pode considerar o período de retenção de cópias de segurança como uma janela de recuperação do ponto de vista da restauração.

O armazenamento de cópias de segurança conserva todas as cópias de segurança necessárias para efetuar uma PITR durante o período de retenção das cópias de segurança. Por exemplo, se definir o período de retenção de cópias para 7 dias, a janela de recuperação é dos últimos 7 dias. Neste cenário, o armazenamento de backup retém todos os dados e registos necessários para restaurar e recuperar o servidor nos últimos 7 dias.

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. Paga por qualquer armazenamento extra de backup que use em gigabytes por mês.

Por exemplo, se provisionar um servidor com 250 gibibytes (GiB) de armazenamento, obtém 250 GiB de capacidade de armazenamento de backup sem custo adicional. Se o uso diário de backup for de 25 GiB, pode ter até 10 dias de armazenamento de backup gratuito. Paga-se por um consumo de armazenamento de backup que ultrapasse 250 GiB, conforme definido no modelo de preços.

Se configurares o teu servidor com backup geo-redundante, os dados de backup também são copiados para a região emparelhada do Azure. Portanto, o tamanho do teu backup é o dobro do tamanho da cópia de backup local. A faturação é calculada como ((2 x tamanho de backup local) - tamanho de armazenamento provisionado) x preço @ gigabytes por mês.

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

Recuperação de ponto no tempo

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 do servidor de origem, mas você pode escolher a zona de disponibilidade. Ele é criado com a configuração do servidor de origem para o nível de preço, geração de computação, número de núcleos virtuais, tamanho do armazenamento, período de retenção de backup e opção de redundância de backup.

Os arquivos físicos do banco de dados são primeiro restaurados a partir das cópias de segurança instantâneas para o local de dados do servidor. O backup apropriado que foi feito antes do point-in-time desejado é automaticamente escolhido e restaurado. Em seguida, um processo de recuperação começa usando arquivos WAL para levar o banco de dados a um estado consistente.

Por exemplo, suponha que os backups são realizados às 23:00 todas as noites. Se o ponto de restauração for para 15 de agosto às 10h00, o backup diário de 14 de agosto será restaurado. A base de dados é recuperada até às 10:00 do dia 15 de agosto através do backup do registo de transações de 14 de agosto, 23:00, até 15 de agosto, 10:00.

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

• Restaure para o ponto de restauro mais recente.
• Restaure para o ponto de restauração personalizado.
• Restaure 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 dados bons por dados incorretos devido a um defeito do aplicativo.
• Você deseja clonar seu servidor para teste, desenvolvimento ou verificação de dados.

Ao usar backup contínuo dos registos de transações, pode restaurar para a última transação. Você pode escolher entre as seguintes opções de restauração:

• Último ponto de restauração (agora): Esta é a opção padrão, que restaura o servidor ao ponto mais recente no tempo.

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

• Ponto de restauro rápido: Esta opção restaura o servidor no menor tempo possível dentro do período de retenção definido para a sua instância de servidor flexível no Base de Dados do Azure para PostgreSQL. Para uma restauração mais rápida, basta escolher diretamente o timestamp na lista de backups. Esta operação de restauro prevê um servidor e simplesmente restaura o backup completo do snapshot. Não requer qualquer recuperação de registos, o que o torna rápido. Selecione uma data e hora da cópia de segurança posterior ao ponto de restauro mais antigo, para que a operação de restauro seja bem-sucedida.

O tempo necessário para recuperar utilizando as opções de ponto de restauro mais recentes e personalizadas varia consoante fatores como o volume de registos de transações a processar desde o último backup e o número total de bases de dados recuperadas simultaneamente na mesma região. O tempo total de recuperação costuma variar entre alguns minutos e 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 acesso público. Da mesma forma, se você configurou seu servidor com acesso público, não poderá restaurar para acesso à rede virtual privada.

Backup e restauração 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 backup com redundância geográfica, você pode restaurá-lo para uma região emparelhada geograficamente. Para obter mais informações, consulte as regiões suportadas 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ções são copiados para a região emparelhada de forma assíncrona por meio da replicação de armazenamento. Depois de criar um 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 se replique para a região emparelhada.

Mais tarde, os logs de transações e os backups diários são copiados de forma assíncrona para a região emparelhada. Pode haver até uma hora de atraso na transmissão de dados. Assim, você pode esperar até uma hora de RPO ao restaurar. Você pode restaurar apenas para os últimos dados de backup disponíveis na região emparelhada. Atualmente, o PITR dos backups geo-redundantes não está disponível.

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

Durante a restauração geográfica, pode alterar as configurações do servidor que incluem definições de rede virtual e a possibilidade de remover backups geo-redundantes do servidor restaurado. A alteração de outras configurações do servidor — como computação, armazenamento ou escalão de preço (expansível, fins gerais ou otimizado para memória) — não é suportada durante o restauro geográfico.

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

Restauração e configuração de rede

Recuperação de ponto no tempo

Se configurares o teu servidor de origem com uma rede de acesso público , só podes restaurar para acesso público.

Se configurar o seu servidor de origem com uma rede virtual de acesso privado , pode restaurar para a mesma rede virtual ou para uma rede virtual diferente. Não é possível executar o PITR em acesso público e privado.

Restauração Geográfica

Se configurares o teu servidor de origem com uma rede de acesso público , só podes restaurar para acesso público. Além disso, deve aplicar regras de firewall depois de concluída a operação de restauro.

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

Tarefas pós-restauração

Após restaurar o servidor, execute as seguintes tarefas para pôr os seus utilizadores e aplicações a funcionar 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 automaticamente aplicados ao novo servidor. Certifique-se de reconfigurar todos os parâmetros do novo servidor de acordo com os requisitos desse novo servidor.

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

• Aumente ou diminua a computação do servidor restaurado conforme necessário.

• Certifique-se de que os logins apropriados e as permissões no nível do banco de dados estejam em vigor.

• Configure alertas conforme apropriado.

• Se o servidor de origem a partir do qual restaurou estava configurado com alta disponibilidade, e quiser configurar o servidor restaurado com alta disponibilidade, siga estes passos.

• Se o servidor de origem de onde restauraste estava configurado com réplicas de leitura, e quiseres configurar réplicas de leitura no servidor restaurado, segue as instruções em Criar uma réplica de leitura.

Backups a pedido

Sua instância de 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, pode criar um backup a pedido sempre que necessário. Esta opção é ideal para cenários como a preparação para uma operação potencialmente arriscada ou a realização de atualizações periódicas fora do calendário habitual de backup.

Aceite backups sob demanda além dos backups automáticos programados. A janela de retenção de cópias determina quanto tempo devem ser mantidas essas cópias de segurança. Pode apagar backups on-demand a qualquer momento se já não forem necessários. Para iniciar um backup on-demand, selecione a instância da base de dados que deseja fazer backup e especifique um nome de backup. Estes backups são armazenados juntamente com backups automatizados, mas só os utilizadores podem eliminar backups sob demanda. O serviço gere e mantém backups automatizados para cumprir os requisitos de retenção de backups.

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

Limitações

• A camada de computação do servidor Burstable não suporta a funcionalidade de backup sob demanda.
• A camada de armazenamento SSDv2 não suporta a funcionalidade de backup on-demand.
• Pode aceitar até sete backups on-demand por instância de servidor flexível. A janela de retenção de cópias determina quanto tempo devem ser mantidas essas cópias de segurança.

Retenção a longo prazo

Os serviços Azure Backup e Base de Dados do Azure para PostgreSQL fornecem uma solução de backup de longo prazo de classe empresarial para instâncias flexíveis de servidor Base de Dados do Azure para PostgreSQL que mantém backups até 10 anos. Pode usar a retenção a longo prazo (LTR) de forma independente ou juntamente com a solução de backup automatizada oferecida pelo Base de Dados do Azure para PostgreSQL, que oferece retenção 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. Backups de longo prazo ajudam-no a satisfazer as suas necessidades de conformidade, são mais granulares e são considerados backups lógicos usando pg_dump nativa. 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.
• As cópias de segurança são armazenadas em domínios de segurança e falha separados. 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).
• Utilizar pg_dump proporciona maior flexibilidade na restauração de dados entre diferentes versões de bases 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.
• Suporte de backup LTR para servidores habilitados para CMK.

Limitações e considerações

• Teste o seu backup e restauro LTR imediatamente após a configuração para garantir que cumprem os requisitos do seu negócio.
• As restaurações LTR estão atualmente disponíveis apenas através da opção Restaurar como ficheiros para contas de armazenamento, estando a funcionalidade Restaurar como servidor prevista para o futuro.
• O LTR faz backup de todas as bases de dados em instâncias de servidor flexíveis, e não podes selecionar bases de dados individuais para configuração do LTR.
• O backup LTR não é suportado em réplicas, mas podes fazê-lo em servidores principais.
• O tamanho máximo de banco de dados suportado para backups LTR (Long-Term Retention - retenção de longo prazo) é de 1 TiB.
• Podes agendar backups de longos períodos semanais, mensais ou anuais. O calendário de backup diário não é suportado neste momento.
• Backups LTR não suportam tabelas contendo uma linha com um comprimento BYTEA superior a 500 MB.
• Ao restaurar funções para utilizadores do Microsoft Entra, certifique-se de que a autenticação do Microsoft Entra está ativada e de que tem sessão iniciada como administrador do Microsoft Entra para criar utilizadores adicionais. Tentar criar funções Entra como utilizador regular resulta em erros.

Para mais informações sobre como realizar uma cópia de segurança a longo prazo, consulte o guia prático.

Perguntas frequentes

Perguntas relacionadas ao backup

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

  Por defeito, o Base de Dados do Azure para PostgreSQL permite backups automáticos de todo o seu servidor (abrangendo todas as bases de dados criadas) com um período de retenção padrão de sete dias. Os backups automatizados incluem um instantâneo diário incremental da base de dados. Os arquivos de log (WAL) são arquivados no Armazenamento de Blobs do Azure continuamente.

• Posso configurar backups automatizados para reter 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 a longo prazo usando o Azure Backup.

• Como faço backup manual do meu Banco de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL?

  Pode tirar manualmente um snapshot físico usando a funcionalidade de backup on-demand. Também pode fazer cópias de segurança lógicas usando a ferramenta PostgreSQL pg_dump. Para obter exemplos, consulte Migrar seu Banco de Dados do Azure para banco de dados PostgreSQL usando despejo e restauração.

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

  O Azure gerencia janelas de backup e você não pode personalizá-las. A primeira cópia de segurança completa de snapshot é agendada imediatamente após a criação do servidor. Os backups de snapshot subsequentes são incrementais e ocorrem uma vez por dia.

• As minhas cópias de segurança estão encriptadas?

  Yes. 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 AES (Advanced Encryption Standard) de 256 bits. A encriptação de armazenamento está sempre ativada e não pode ser desativada.

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

  Restaurar uma única base de dados ou algumas bases de dados ou tabelas não é suportado diretamente. No entanto, você pode restaurar todo o servidor para um novo servidor e, em seguida, descartar tabelas ou bancos de dados que não são necessários no novo servidor.

• O meu servidor está disponível enquanto uma cópia de segurança está em curso?

  Yes. Os backups são operações online que usam snapshots. A operação de snapshot leva apenas alguns segundos e não interfere nas cargas de trabalho de produção, ajudando a garantir a alta disponibilidade do servidor.

• Quando estou configurando a janela de manutenção para o servidor, preciso levar em conta a janela de backup?

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

• Onde meus backups automatizados são armazenados e como faço para gerenciar sua retenção?

  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 onde há suporte para várias zonas.
  • Armazenamento localmente redundante, em regiões que ainda não suportam várias zonas.
  • A região emparelhada, se você configurar o backup com redundância geográfica.

  Não pode exportar estes ficheiros de backup porque estão armazenados em contas de armazenamento geridas pela Microsoft. Tens acesso apenas de leitura para restaurar estes ficheiros, mas não podes modificá-los nem apagá-los. Os ficheiros de backup são automaticamente eliminados após o período de retenção.

  Você pode usar backups para restaurar o servidor a 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 até 35 dias.

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

  Quando configuras o servidor com backup geo-redundante, os dados de backup são armazenados numa conta de armazenamento geo-redundante. A conta de armazenamento copia arquivos de dados para a região emparelhada quando o backup diário ocorre no servidor primário. O backup dos arquivos WAL é feito quando estão prontos para serem arquivados.

  Os dados de backup são copiados de forma assíncrona e contínua para a região emparelhada. Você pode esperar até uma hora de atraso no recebimento de dados de backup.

• Posso fazer PITR na região remota?

  Não. Os dados são recuperados do último backup disponível na região remota.

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

  Os volumes de dados numa instância de servidor flexível da Base de Dados do Azure para PostgreSQL são apoiados através de instantâneos incrementais de discos geridos do servidor primário. O backup WAL é executado a partir do servidor primário ou do servidor em espera.

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

  A melhor maneira de verificar backups é executar PITR periódicos e garantir que os backups sejam válidos e restauráveis. As operações de backup ou ficheiros não estão expostos aos utilizadores finais.

• Onde posso ver o uso do backup?

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

• O que acontece aos 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 os recursos do servidor contra exclusão acidental ou alterações inesperadas após a implantação, os administradores podem usar bloqueios de gerenciamento.

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

  Nenhum novo backup é executado para servidores interrompidos. O serviço mantém todas as cópias de segurança mais antigas (dentro da janela de retenção) no momento da parada do servidor até que este seja reiniciado. Depois disso, a retenção de backup para o servidor ativo é determinada pela sua janela de retenção.

• Como é que sou cobrado e faturado pelos meus backups?

  O Banco de Dados do Azure para PostgreSQL fornece até 100% do seu armazenamento de servidor provisionado como armazenamento de backup sem custo extra. Paga por qualquer armazenamento de backup adicional que utilize, 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 selecionados, juntamente com a atividade transacional no servidor, afetam diretamente o armazenamento total de backup e o faturamento.

• Como é que me cobram por um servidor parado?

  Enquanto a instância do servidor é interrompida, nenhum novo backup é executado. Paga por armazenamento provisionado e armazenamento de backup (backups armazenados dentro do prazo de retenção especificado).

  O armazenamento de backup gratuito é limitado ao tamanho do banco de dados provisionado. Paga pelos dados de cópia de segurança excedentários de acordo com o preço da cópia de segurança.

• Configurei o meu servidor com redundância de zona para alta disponibilidade. Vocês fazem dois backups e serei cobrado duas vezes?

  Não. Independentemente de servidores HA ou não-HA, o serviço mantém apenas um conjunto de cópias de segurança. Só pagas uma vez.

Perguntas relacionadas à restauração

• Como restauro o meu servidor?

  O Azure suporta PITR para todos os servidores. Pode restaurar para o ponto de restauro mais recente ou para um ponto de restauro personalizado usando o portal Azure, a CLI do Azure e a API.

  Para restaurar o seu servidor a partir de backups manuais usando ferramentas como pg_dump, pode primeiro criar uma instância de servidor Base de Dados do Azure para PostgreSQL flexível e depois restaurar as suas bases de dados no servidor usando pg_restore.

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

  Yes. Se a região oferecer suporte a várias zonas de disponibilidade, o backup será armazenado em uma conta de armazenamento com redundância de zona para que você possa restaurar para outra zona.

• Quanto tempo demora um PITR? Porque é que o meu restauro está a demorar tanto tempo?

  A operação de restauração de dados a partir de um instantâneo não depende do tamanho dos dados. Mas o tempo do processo de recuperação que aplica os registos (atividades de transação a reproduzir) pode variar, dependendo da cópia de segurança anterior à data e hora solicitadas e do número de registos a processar. Esta condição aplica-se tanto à restauração dentro da mesma zona como à restauração de dados numa 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 da Base de Dados do Azure para PostgreSQL. Após a conclusão da restauração, você pode, opcionalmente, configurar o servidor com alta disponibilidade.

• Eu configurei meu servidor dentro de uma rede virtual. Posso restaurar para outra rede virtual?

  Yes. No momento da restauração, escolha uma rede virtual diferente para 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 oferece 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á como rastrear a operação de restauração. Você pode monitorar o registro de atividades para ver se a operação está em andamento ou concluída.

Conteúdo relacionado

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