Descrição geral da continuidade empresarial com a Base de Dados SQL do Azure
Aplica-se a:
Banco de Dados SQL do Azure
Este artigo fornece uma visão geral dos recursos de continuidade de negócios e recuperação de desastres do Banco de Dados SQL do Azure, descrevendo as opções e recomendações para recuperar de eventos com interrupções que podem levar à perda de dados ou fazer com que seu banco de dados e aplicativo fiquem indisponíveis. Saiba o que fazer quando um erro de usuário ou aplicativo afeta a integridade dos dados, uma zona ou região de disponibilidade do Azure tem uma interrupção ou seu aplicativo requer manutenção.
Descrição geral
A continuidade de negócios no Banco de Dados SQL do Azure refere-se aos mecanismos, políticas e procedimentos que permitem que sua empresa continue operando em face de interrupções, fornecendo disponibilidade, alta disponibilidade e recuperação de desastres.
Na maioria dos casos, o Banco de dados SQL lida com eventos disruptivos que podem acontecer em um ambiente de nuvem e mantém 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, tais como:
- O usuário exclui ou atualiza acidentalmente uma linha em uma tabela.
- Invasor mal-intencionado exclui dados com êxito ou descarta um banco de dados.
- Um evento de desastre natural catastrófico derruba um datacenter ou uma zona ou região de disponibilidade.
- 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 componente de hardware.
Disponibilidade
O Banco de Dados SQL do Azure vem com uma promessa básica 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 dados contra corrupção 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%.
Elevada Disponibilidade
Para obter alta disponibilidade no ambiente de nuvem do Azure, habilite a redundância de zona para que o banco de dados, ou pool elástico, use zonas de disponibilidade para garantir que o banco de dados, ou pool elástico, seja resiliente 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 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 Banco de Dados SQL do Azure é capaz de fornecer um SLA de maior disponibilidade de 99,995%.
Recuperação após 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 para recuperação de desastres com 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 replicaçã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 escuta de leitura-gravação e somente leitura que permanecem inalterados, portanto, não é necessário atualizar as cadeias de conexão do aplicativo após o failover.
- A restauração geográfica permite que você se recupere de uma interrupção regional restaurando a partir de backups replicados geograficamente quando não for possível 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 ativos de replicação geográfica 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 ativação pós-falha | |
|---|---|---|
| Sincronização contínua de dados entre primário e secundário | Sim | Sim |
| Failover de vários bancos de dados simultaneamente | Não | Sim |
| A cadeia de conexão permanece inalterada após o failover | Não | Sim |
| Suporta escala de leitura | Sim | Sim |
| Várias réplicas | Sim | No |
| Pode estar na mesma região que o primário | Sim | No |
Recursos que fornecem continuidade de negócios
Do ponto de vista do banco de dados, há quatro grandes cenários potenciais de interrupção. A tabela a seguir lista os recursos de continuidade de 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 de negócios | Recurso de continuidade de negócios |
|---|---|
| Falhas locais de hardware ou software que afetam o nó do banco de dados. | Para mitigar falhas locais de hardware e software, o Banco de dados SQL inclui uma arquitetura de disponibilidade, que garante a recuperação automática dessas falhas com SLA de disponibilidade de até 99,99%. |
| Corrupção ou exclusão de dados normalmente causada por um bug do aplicativo ou erro humano. Tais falhas são específicas da aplicação e, normalmente, não podem ser detetadas pelo serviço de base de dados. | Para proteger sua empresa contra perda de dados, o Banco de dados SQL cria automaticamente backups completos de banco de dados semanalmente, backups diferenciais de banco de dados a cada 12 ou 24 horas e backups de log de transações a cada 5 a 10 minutos. Por padrão, os backups são armazenados em armazenamento com redundância geográfica por sete dias para todas as camadas de serviço. Todas as camadas de serviço, exceto Basic, suportam um período de retenção de backup configurável para restauração point-in-time (PITR) de até 35 dias. Você pode restaurar um banco de dados excluído até o ponto em que ele foi excluído se o servidor não tiver sido excluído ou se você tiver configurado a retenção de longo prazo (LTR). |
| Rara interrupção do datacenter ou da zona de disponibilidade, possivelmente causada por um evento de desastre natural, alteração de configuração, bug de software ou falha de componente de hardware. | Para atenuar 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 fornecer redundância em várias zonas físicas dentro de uma região do Azure. A habilitação da redundância de zona garante que o banco de dados ou pool elástico seja resiliente a falhas zonais com SLA de alta disponibilidade de até 99,995%. |
| Rara interrupção regional que afeta todas as zonas de disponibilidade e os datacenters que as compõem, possivelmente causada por um evento catastrófico de desastre natural. | Para atenuar 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. - Configuração de redundância de armazenamento de backup para armazenamento de backup com redundância geográfica para usar restauração geográfica. |
RTO e RPO
Ao desenvolver seu plano de continuidade de negócios, entenda o tempo máximo aceitável antes que o aplicativo se recupere totalmente após o evento de interrupção. O tempo necessário para que um aplicativo se recupere totalmente é conhecido como RTO (Recovery Time Objetive, objetivo de tempo de recuperação). Entenda também o período máximo de atualizações de dados recentes (intervalo de tempo) que o aplicativo pode tolerar perder ao se recuperar de um evento disruptivo não planejado. A perda potencial de dados é conhecida como RPO (Recovery Point Objetive, objetivo de ponto de recuperação).
A tabela a seguir compara RPO e RTO de cada opção de continuidade de negócios:
| Opção de continuidade de negócios | RTO (tempo de inatividade) | RPO (perda de dados) |
|---|---|---|
| Alta disponibilidade (habilitando redundância de zona) |
Normalmente menos de 30 segundos | 0 |
| Recuperação de desastres (habilitando grupos de failover ou replicação geográfica ativa) |
Normalmente menos de 60 segundos | Igual ou superior a 0 (Depende de alterações de dados anteriores ao evento de interrupção que não foram replicadas) |
| Recuperação de desastres (usando restauração geográfica) |
Normalmente, minutos ou horas | Normalmente, minutos ou horas |
Listas de verificação de continuidade de negócios
Para obter recomendações prescritivas para maximizar a disponibilidade e alcançar maior continuidade de negócios, consulte:
- Lista de verificação de disponibilidade
- Lista de verificação de elevada disponibilidade
- Lista de verificação de recuperação de desastres
Prepare-se para uma interrupção na região
Independentemente dos recursos de continuidade de negócios usados, 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 leva mais tempo e provavelmente também requer 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 dentro da mesma região do Azure
Você pode usar backups automáticos de banco de dados para restaurar um banco de dados para um ponto no tempo no passado. Desta forma, você pode se recuperar de corrupções de dados causadas por erros humanos. A restauração point-in-time (PITR) permite criar um novo banco de dados no mesmo servidor que representa o estado dos dados antes do evento corrompido. Para a maioria dos bancos de dados, as operações de restauração levam menos de 12 horas. Pode levar mais tempo para recuperar um banco de dados muito grande ou muito ativo. Para obter mais informações, consulte Tempo de recuperação do banco de dados.
Se o período máximo de retenção de backup suportado para restauração point-in-time não for suficiente para seu aplicativo, você poderá estendê-lo configurando uma política de retenção de longo prazo (LTR) para o(s) banco(s) de dados. Para obter mais informações, consulte Retenção de backup de longo prazo.
Atualizar uma aplicação com um período de indisponibilidade mínimo
Às vezes, um aplicativo deve ser colocado offline devido a manutenção, como uma atualização de aplicativo. Gerenciar atualizações de aplicativos descreve como usar a replicação geográfica ativa para habilitar atualizações contínuas de seu aplicativo na nuvem para minimizar o tempo de inatividade durante as atualizações e fornecer um caminho de recuperação se algo der errado.
Poupe custos com uma réplica em espera
Se sua réplica secundária for usada apenas para recuperação de desastres (DR) 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.
Reveja a réplica em espera sem licença para saber mais.
Próximos passos
Para obter considerações sobre o design do aplicativo, consulte Projetar um aplicativo para recuperação de desastres na nuvem e estratégias de recuperação de desastres do Elastic pool.
Reveja as orientações de recuperação de desastres da Base de Dados SQL do Azure e a lista de verificação de alta disponibilidade e recuperação de desastres da Base de Dados SQL do Azure.