Cópia de segurança e restauro na Base de Dados do Azure para PostgreSQL – Servidor Flexível

APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Flexível

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

O servidor flexível do Banco de Dados do Azure para PostgreSQL executa automaticamente backups regulares do seu servidor. Em seguida, você pode fazer uma recuperação point-in-time (PITR) dentro de um período de retenção que você especificar. O tempo total de restauração e recuperação normalmente depende do tamanho dos dados e da quantidade de recuperação a ser executada.

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

O servidor flexível do 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 localmente redundante, dependendo da região. O servidor também faz backup de logs de transações quando o arquivo de log write-ahead (WAL) está pronto para ser arquivado. Você pode usar esses backups para restaurar um servidor para qualquer point-in-time dentro do período de retenção de backup configurado.

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

Esses arquivos de backup não podem ser exportados ou usados para criar servidores fora do Banco de Dados do Azure para o servidor flexível PostgreSQL. Para isso, você pode usar as ferramentas PostgreSQL pg_dump e pg_restore/psql.

Frequência de cópia de segurança

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 instantâneos é 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 nenhum dos bancos de dados no servidor receber modificações adicionais após o último backup de instantâneo ser feito, os backups de instantâneo serão suspensos até que novas modificações sejam feitas em qualquer um dos bancos de dados, ponto em que um novo instantâneo é imediatamente tirado. 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 atraso (objetivo de ponto de recuperação, ou RPO) pode ser de até 15 minutos.

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

O servidor flexível do 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 servidor flexível do Banco de Dados do Azure para PostgreSQL oferece três opções:

• Armazenamento de backup com redundância de zona: essa opção é escolhida automaticamente para regiões que oferecem suporte a zonas de disponibilidade. Quando os backups são armazenados em armazenamento de backup com redundância de zona, várias cópias não são apenas armazenadas na mesma zona de disponibilidade, mas também replicadas para outras zonas de disponibilidade dentro da mesma região.

  Essa opção fornece disponibilidade de dados de backup em 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 oferece pelo menos 99,99999999999 por cento (12 noves) de durabilidade dos objetos de backup ao longo de um ano.

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

  Essa opção ajuda a proteger seus dados contra falhas de rack e unidade do servidor. Ele fornece pelo menos 99,9999999999 por cento (11 noves) de durabilidade de objetos de backup ao longo de um ano.

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

• 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 em armazenamento de backup com redundância geográfica, além de três cópias de dados armazenados na região onde o servidor está hospedado, os dados são replicados 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,999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

  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 da cópia de segurança

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

O período de retenção de backup rege o período de tempo a partir 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 de uma perspetiva de restauração.

Todos os backups necessários para executar um PITR dentro do período de retenção de backup são mantidos no armazenamento de backup. Por exemplo, se o período de retenção de backup estiver definido como 7 dias, a janela de recuperação será os últimos 7 dias. Nesse cenário, todos os dados e logs necessários para restaurar e recuperar o servidor nos últimos 7 dias são retidos.

Custo de armazenamento de cópias de segurança

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

Por exemplo, se você provisionou um servidor com 250 gibibytes (GiB) de armazenamento, então você tem 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. O consumo de armazenamento de backup que exceda 250 GiB é cobrado conforme definido no modelo de preços.

Se você configurou seu servidor com backup com redundância geográfica, os dados de backup também serão copiados para a região emparelhada do Azure. Assim, o tamanho do backup será o dobro do tamanho da cópia de backup local. O faturamento é calculado como ( (2 x tamanho de backup local) - tamanho de armazenamento provisionado ) x preço @ 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 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.

Nota

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

Recuperação point-in-time

No Banco de Dados do Azure para servidor flexível 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. Além disso, tags e configurações, como redes virtuais e configurações de firewall, são herdadas do servidor de origem.

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 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. O banco de dados será recuperado até as 10h00 de 15 de agosto usando o backup do log de transações de 14 de agosto, 23h00, a 15 de agosto, 10h00.

Para restaurar o servidor de banco de dados, consulte estas etapas.

Importante

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

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.

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

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

• Ponto de restauração personalizado: essa opção permite que você escolha qualquer point-in-time 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 restauração rápido: essa opção permite que os usuários restaurem o servidor no menor tempo possível dentro do período de retenção definido para sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. A restauração mais rápida é possível escolhendo diretamente o carimbo de data/hora na lista de backups. Essa operação de restauração provisiona um servidor e simplesmente restaura o backup completo do snapshot e não requer nenhuma recuperação de logs, o que o torna rápido. Recomendamos que você selecione um carimbo de data/hora de backup, que é maior do que o primeiro ponto no tempo de restauração para uma operação de restauração bem-sucedida.

O tempo necessário para recuperar usando as opções de ponto de restauração mais recentes e personalizadas varia com base em 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 geral de recuperação 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 acesso público. Da mesma forma, se você configurou seu servidor com acesso público, não poderá restaurar para acesso à rede virtual privada.

Importante

Os servidores excluídos podem ser restaurados. Se você excluir o servidor, poderá seguir nossa orientação Restaurar um Banco de Dados do Azure descartado para o Banco de Dados do Azure para PostgreSQL - Servidor flexível para recuperar. Utilize o bloqueio de recursos do Azure para ajudar a prevenir a eliminação acidental do seu servidor.

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 o guia de início rápido.

Importante

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

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 o servidor é configurado 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. Isso permite que o primeiro conjunto de dados de backup seja replicado 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 de backups com redundância geográfica não está disponível.

O tempo estimado para recuperar o servidor (objetivo de tempo de recuperação, ou RTO) 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, as configurações do servidor que podem ser alteradas incluem 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 a alteração de outras configurações de 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 sobre como executar uma restauração geográfica, consulte o guia de instruções.

Importante

Quando a região primária está inativa, não é possível criar servidores com redundância geográfica na respetiva região emparelhada geograficamente, porque 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, você deve aguardar até que a região primária esteja ativa.

Com a região primária inativa, você ainda pode 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.

Restauração e rede

Recuperação point-in-time

Se o servidor de origem estiver configurado com uma rede de acesso público, você só poderá restaurar para 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 o PITR em acesso público e privado.

Restauro geográfico

Se o servidor de origem estiver configurado com uma rede de acesso público, você só poderá restaurar para acesso público. As regras de firewall existentes no servidor de origem são copiadas para o servidor restaurado. Os pontos finais privados não são assumidos. Após a conclusão da operação de restauração, reveja se precisa de ajustar alguma das regras de firewall transferidas e crie quaisquer pontos de extremidade privados de que possa necessitar.

Se o servidor de origem estiver configurado com uma rede virtual de acesso privado, você só poderá restaurar para uma rede virtual diferente, porque 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.

Post-restore tasks

Depois de restaurar o servidor, você pode executar as seguintes tarefas para que seus usuários e aplicativos voltem a funcionar:

• Se o novo servidor quiser substituir o servidor original, redirecione os clientes e as aplicações cliente para o novo servidor. Altere o nome do servidor da cadeia de conexão para apontar para o novo servidor.

• Certifique-se de que o firewall no nível do servidor, os pontos de extremidade privados e as regras de rede virtual apropriadas estejam em vigor para as conexões de usuário. Na rede de acesso público, as regras são copiadas do servidor original, mas essas podem não ser as necessárias no ambiente restaurado. Então, ajustá-los de acordo com suas necessidades. Os pontos finais privados não são transferidos. Crie quaisquer pontos de extremidade privados que você possa precisar 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 de servidor restauradas. Qualquer coisa relacionada à configuração de VNET, sub-redes ou grupos de segurança de rede deve ser tratada como uma tarefa pós-restauração.

• 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 foi configurado com alta disponibilidade e pretende configurar o servidor restaurado com alta disponibilidade, pode seguir estes passos.

• Se o servidor de origem a partir do qual restaurou foi configurado com réplicas de leitura e pretende configurar réplicas de leitura no servidor restaurado, pode seguir estes passos.

Retenção a longo prazo (pré-visualização)

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

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

Limitações e considerações

• Na visualização, a restauração LTR está atualmente disponível como RestoreasFiles para contas de armazenamento. A capacidade RestoreasServer será adicionada no futuro.
• Na visualização, você pode executar backups LTR para todos os bancos de dados, suporte de backup de banco de dados único será adicionado no futuro.
• Atualmente, o backup LTR não é suportado em réplicas geográficas. Você ainda pode executar backups LTR a partir dos servidores primários.

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

Perguntas mais frequentes

Perguntas relacionadas ao backup

• 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 um período de retenção padrão de 7 dias. Os backups automatizados incluem um instantâneo incremental diário do banco 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.º Atualmente, o servidor flexível do Banco de Dados do Azure para PostgreSQL oferece suporte a um máximo de 35 dias de retenção. Você pode usar backups manuais para um requisito de retenção de longo prazo.

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

  Você pode fazer um backup manualmente usando a ferramenta PostgreSQL pg_dump. Para obter exemplos, consulte Migrar seu Banco de Dados do Azure para banco de dados de servidor flexível PostgreSQL usando despejo e restauração.

  Se você quiser fazer backup do Banco de Dados do Azure para servidor flexível PostgreSQL para Armazenamento de Blob, consulte Fazer backup do Banco de Dados do Azure para PostgreSQL para Armazenamento de Blob em nosso blog da comunidade de tecnologia.

• 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 de instantâneos completa é 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 são encriptadas?

  Sim. Todos os dados flexíveis do servidor 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 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?

  Não há suporte direto para a restauração de um único banco de dados ou de alguns bancos de dados ou tabelas. No entanto, você pode restaurar todo o servidor para um novo servidor e, em seguida, extrair tabelas ou bancos de dados e importá-los para o novo servidor.

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

  Sim. Os backups são operações online que usam instantâneos. A operação de snapshot leva apenas alguns segundos e não interfere nas cargas de trabalho de produção, para ajudar 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.º 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?

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

  Estes ficheiros de cópia de segurança não podem ser exportados.

  Você pode usar backups para restaurar o servidor apenas para um point-in-time. O período de retenção predefinido das cópias de segurança é de 7 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 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 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.º 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?

  Os volumes de dados no servidor flexível do Banco de Dados do Azure para PostgreSQL são copiados por meio de instantâneos incrementais de disco gerenciado 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 ou ficheiros de cópia de segurança 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 com as minhas cópias de segurança se eliminar o 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. Todos os backups mais antigos (dentro da janela de retenção) no momento da interrupção do servidor são retidos 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 serei cobrado e cobrado pelos meus backups?

  O servidor flexível do Banco de Dados do Azure para PostgreSQL fornece até 100% do seu armazenamento de servidor provisionado como armazenamento de backup sem custo extra. Qualquer outro armazenamento de backup usado é 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 serei cobrado por um servidor parado?

  Enquanto a instância do servidor é interrompida, nenhum novo backup é executado. Você é cobrado pelo armazenamento provisionado e pelo armazenamento de backup (backups armazenados dentro da janela de retenção especificada).

  O armazenamento de backup gratuito é limitado ao tamanho do banco de dados provisionado. Qualquer excesso de dados de backup será cobrado de acordo com o preço do backup.

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

  N.º Independentemente dos servidores HA ou não, apenas um conjunto de cópias de backup é mantido. Você será cobrado apenas uma vez.

Perguntas relacionadas à restauração

• Como restauro o meu servidor?

  O Azure suporta PITR 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 a partir de backups manuais usando ferramentas como pg_dump, você pode primeiro criar um Banco de Dados do Azure para PostgreSQL instância de servidor 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 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 logs (atividades de transação a serem reproduzidas) pode variar, dependendo do backup anterior da data/hora solicitada e do número de logs a serem processados. Isso se aplica à 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 servidor é restaurado como uma instância flexível do Banco de Dados do Azure para PostgreSQL de instância única. 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?

  Sim. 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 servidor flexível do Banco de Dados do Azure para PostgreSQL atualmente 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.

Próximos passos

• Saiba mais sobre a continuidade de negócios.
• Saiba mais sobre a alta disponibilidade com redundância de zona.
• Saiba como restaurar.