Visão geral da continuidade dos negócios com o Banco de Dados SQL do Azure

Artigo
2025-04-21

Aplica-se a:Banco de Dados SQL do Azure Banco de dados SQL no Fabric

Este artigo fornece uma visão geral dos recursos de continuidade dos negócios e recuperação de desastres do Banco de Dados SQL do Azure, descrevendo as opções e recomendações para se recuperar de eventos disruptivos que podem levar à perda de dados ou fazer com que seu banco de dados e aplicativo fiquem indisponíveis. Aprenda o que fazer quando um erro de usuário ou de aplicativo afeta a integridade dos dados, quando uma região ou zona de disponibilidade do Azure tem uma interrupção ou quando seu aplicativo necessita de manutenção.

Visão geral

A continuidade dos negócios no Banco de Dados SQL do Azure refere-se aos mecanismos, políticas e procedimentos que permitem que sua empresa continue operando diante da interrupção, fornecendo disponibilidade, alta disponibilidade e recuperação de desastres.

Na maioria dos casos, o Banco de Dados SQL lidará com os eventos de interrupção que podem acontecer no ambiente de nuvem e manterá seus aplicativos e processos de negócios em execução. No entanto, existem alguns eventos disruptivos em que a mitigação pode levar algum tempo, como:

O usuário exclui ou atualiza acidentalmente uma linha em uma tabela.
Um invasor mal-intencionado conseguiu excluir dados ou remover um banco de dados.
Um evento catastrófico de desastre natural derruba um datacenter ou uma zona de disponibilidade ou região.
Datacenter raro, zona de disponibilidade ou interrupção em toda a região causada por uma alteração de configuração, bug de software ou falha de hardware.

Para recomendações prescritivas para maximizar a disponibilidade e obter maior continuidade dos negócios, consulte:

Alta disponibilidade

O Banco de Dados SQL do Azure vem com uma promessa de resiliência e confiabilidade que o protege contra falhas de software ou hardware. Os backups de banco de dados são automatizados para proteger seus bancos de dados contra danos ou exclusão acidental. Como uma plataforma como serviço (PaaS), o serviço Banco de Dados SQL do Azure fornece disponibilidade como um recurso pronto para uso com um SLA de disponibilidade líder do setor de 99,99%.

Para obter alta disponibilidade no ambiente de nuvem do Azure, habilite a redundância de zona. Com a redundância de zona, o banco de dados ou pool elástico usa zonas de disponibilidade do Azure para garantir a resiliência a falhas zonais.

Muitas regiões do Azure fornecem zonas de disponibilidade, que são grupos separados de data centers dentro de uma região que têm infraestrutura independente de energia, resfriamento e rede.
As zonas de disponibilidade são projetadas para fornecer serviços regionais, capacidade e alta disponibilidade nas zonas restantes se uma zona sofrer uma interrupção.

Ao habilitar a redundância de zona, o banco de dados ou o pool elástico é resiliente a falhas zonais de hardware e software e a recuperação é transparente para os aplicativos. Quando a alta disponibilidade está habilitada, o serviço de Banco de Dados SQL do Azure é capaz de fornecer um SLA de disponibilidade mais alto de 99,995%.

Recuperação de desastre

Para obter maior disponibilidade e redundância entre regiões, você pode habilitar os recursos de recuperação de desastres para recuperar rapidamente o banco de dados de uma falha regional catastrófica. As opções de recuperação de desastre para o Banco de Dados SQL do Azure são:

A replicação geográfica ativa permite criar um banco de dados secundário legível continuamente sincronizado em qualquer região para um banco de dados primário.
Os grupos de failover, além de fornecer sincronização contínua entre um banco de dados primário e secundário, também permitem gerenciar a duplicação e o failover de alguns ou todos os bancos de dados em um servidor lógico para um servidor lógico secundário em outra região. Os grupos de failover fornecem pontos de extremidade de ouvinte de leitura-gravação e somente leitura e leitura que permanecem inalterados, portanto, a atualização das cadeias de conexão do aplicativo após o failover não é necessária.
A restauração geográfica permite que você se recupere de uma interrupção regional restaurando backups duplicados geograficamente quando você não pode acessar seu banco de dados na região primária criando um novo banco de dados em qualquer servidor existente em qualquer região do Azure.

A tabela a seguir compara grupos de replicação geográfica ativa e failover, duas opções de recuperação de desastres para o Banco de Dados SQL do Azure:

	Replicação geográfica ativa	Grupos de failover
Sincronização contínua de dados entre primário e secundário	Sim	Sim
Fazer fail-over em vários bancos de dados ao mesmo tempo	Não	Sim
A cadeia de conexão permanece inalterada após o failover	Não	Sim
Dá suporte para a escala de leitura	Sim	Sim
Várias réplicas	Sim	Não
Pode estar na mesma região que o primário	Sim	Não

RTO e RPO

Na medida em que você desenvolve o plano de continuidade dos negócios, compreenda qual é o tempo máximo aceitável antes que o aplicativo recupere-se completamente após o evento de interrupção. Duas maneiras comuns de quantificar os requisitos de negócios em torno da recuperação de desastre são:

RTO (Objetivo de Tempo de Recuperação): o tempo necessário para que um aplicativo se recupere totalmente após um evento de interrupção não planejado.
RPO (Objetivo de Ponto de Recuperação): a quantidade de tempo de perda de dados que pode ser tolerada de um evento de interrupção não planejado.

A seguinte tabela compara o RPO e o RTO de cada opção de continuidade dos negócios:

Opções de continuidade dos negócios	RTO (tempo de inatividade)	RPO (perda de dados)
Alta disponibilidade (usando a redundância de zona)	Normalmente menos de 30 segundos	0
Recuperação de desastre (Usando grupos de failover com política de failover gerenciada pelo cliente ou replicação geográfica ativa)	Normalmente menos de 60 segundos	Igual ou maior que 0 (Depende das alterações de dados anteriores ao evento de interrupção que não foram replicados)
Recuperação de desastre (Usando restauração geográfica)	Normalmente, minutos ou horas, dependendo da replicação de armazenamento do Azure	Normalmente, minutos ou horas, dependendo do tamanho do backup do banco de dados

Recursos que fornecem continuidade dos negócios

De uma perspectiva de banco de dados, há quatro cenários principais de interrupção em potencial. A tabela a seguir lista os recursos de continuidade dos negócios do Banco de dados SQL que você pode usar para mitigar um possível cenário de interrupção de negócios:

Cenário de interrupção dos negócios	Recursos da continuidade dos negócios
Falhas de hardware ou software locais que afetam o nó do banco de dados.	Para atenuar falhas locais de hardware e software, o Banco de Dados SQL do Azure inclui uma arquitetura de disponibilidade, que garante a recuperação automática dessas falhas com até 99,99% SLA de disponibilidade.
Corrupção ou exclusão de dados geralmente causada por um erro de aplicativo ou erro humano. Essas falhas são específicas do aplicativo e normalmente não podem ser detectadas pelo serviço de banco de dados.	Para proteger sua empresa contra a perda de dados, o Banco de Dados SQL cria de forma automática, backups completos do banco de dados semanalmente, backups diferenciais do banco de dados a cada 12 ou 24 horas e backups do log de transações a cada 24 a 5 minutos. Por padrão, os backups são armazenados no armazenamento com redundância geográfica por sete dias em todas as camadas de serviço. Todas as camadas de serviço, exceto Básico, dão suporte a um período de retenção de backup configurável para restauração pontual (PITR) de até 35 dias. Você poderá restaurar um banco de dados excluído para o ponto em que ele foi excluído se o servidor não tiver sido excluído ou se você configurou a retenção de longo prazo (LTR).
Interrupção rara de datacenter ou zona de disponibilidade, possivelmente causada por um desastre natural, mudança de configuração, bug de software ou falha de hardware.	Para reduzir a interrupção no nível do datacenter ou da zona de disponibilidade, habilite a redundância de zona para o banco de dados ou pool elástico para usar as Zonas de Disponibilidade do Azure e forneça redundância em várias zonas físicas em uma região do Azure. A habilitação da redundância de zona garante que o banco de dados ou o pool elástico seja resiliente a falhas zonais com SLA de alta disponibilidade de até 99,995%.
Interrupção regional rara que afeta todas as zonas de disponibilidade e os datacenters que a compõem, possivelmente causada por um evento de desastre natural catastrófico.	Para mitigar uma interrupção em toda a região, habilite a recuperação de desastres usando uma das opções: - Opções de sincronização contínua de dados, como grupos de failover (recomendado) ou replicação geográfica ativa, que permitem criar réplicas em uma região secundária para failover. – Configurando a redundância de armazenamento de backup para o armazenamento de backup com redundância geográfica para usar a restauração geográfica.

Prepare-se para uma interrupção de região

Independentemente de quais recursos de continuidade dos negócios você usa, você deve preparar o banco de dados secundário em outra região. Se você não se preparar corretamente, colocar seus aplicativos online após um failover ou recuperação levará mais tempo e provavelmente também exigirá solução de problemas, o que pode atrasar o RTO. Siga a lista de verificação para preparar o secundário para uma interrupção de região.

Restaurar um banco de dados na mesma região do Azure

Você pode usar backups de banco de dados automáticos para restaurar um banco de dados para um ponto no passado. Assim, você pode se recuperar de corrupções de dados causados por erros humanos. A PITR (restauração pontual) permite que você crie um novo banco de dados no mesmo servidor que representa o estado dos dados antes do evento corrompidor. Para ver os tempos de recuperação, confira RTO e RPO.

Se o período máximo de retenção de backup com suporte para restauração pontual não for suficiente para seu aplicativo, você poderá estendê-lo configurando uma política de LTR (retenção de longo prazo). Para obter mais informações, consulte Retenção de longo prazo.

Atualize um aplicativo com tempo de inatividade mínimo

Às vezes, um aplicativo deve ser colocado offline devido à manutenção, como uma atualização do aplicativo. Você pode gerenciar atualizações sem interrupção de aplicativos de nuvem usando a replicação geográfica ativa do Banco de Dados SQL. A replicação geográfica também pode fornecer um caminho de recuperação se algo der errado.

Economizar custos com uma réplica em espera

Se sua réplica secundária for usada apenas para DR (recuperação de desastre) e não tiver cargas de trabalho de leitura ou gravação, você poderá economizar nos custos de licenciamento designando o banco de dados para espera ao configurar uma nova relação de replicação geográfica ativa.

Examine Réplica em espera sem licença para saber mais.

Próxima etapa

Lista de verificação de alta disponibilidade e recuperação de desastre

Compartilhar via