Visão geral da continuidade dos negócios com o Banco 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 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.
- Interrupção rara de datacenter, 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 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%.
Alta 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 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 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 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 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 |
| Dá suporte à escala de leitura | Sim | Sim |
| Várias réplicas | Sim | Não |
| Pode estar na mesma região que o primário | Sim | No |
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 locais de hardware ou software que afetam o nó do banco de dados. | Para atenuar falhas de hardware e software locais, o Banco de Dados SQL inclui uma arquitetura de disponibilidade, que garante a recuperação automática dessas falhas com um SLA de disponibilidade de até 99,99%. |
| 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 uma alteração de configuração, bug de software ou falha de componente 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%. |
| Rara interrupção regional que afeta todas as zonas de disponibilidade e os datacenters que a compõem, possivelmente causada por um evento catastrófico de desastre natural. | 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. - Configuração da redundância de armazenamento de backup para o armazenamento de backup com redundância geográfica para usar a restauração geográfica. |
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. O tempo necessário para um aplicativo se recuperar totalmente é conhecido como RTO (Objetivo de Tempo de Recuperação). Também é necessário entender 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 com interrupção não planejado. A perda de dados potencial é conhecida como RPO (Objetivo de Tempo de Recuperação).
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 a 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 a restauração geográfica) |
Normalmente minutos ou horas | Normalmente minutos ou horas |
Listas de verificação de continuidade dos negócios
Para obter recomendações prescritivas para maximizar a disponibilidade e alcançar maior continuidade dos negócios, consulte:
- Lista de verificação de disponibilidade
- Lista de verificação de alta disponibilidade
- Lista de verificação de recuperação de desastre
Preparação 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 uma recuperação exigirá um tempo adicional e, provavelmente, a solução de problemas também será exigida, 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 restauração pontual (PITR) permite que você crie um banco de dados no mesmo servidor que representa o estado dos dados antes do evento causador da corrupção. 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 saber mais, confira tempo de recuperação de banco de dados.
Se o período de retenção de backup máximo com suporte para a restauração pontual não for suficiente para o aplicativo, você poderá estendê-lo configurando uma política de LTR (retenção de longo prazo) para os bancos de dados. Para obter mais informações, confira Retenção de backup 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. Gerenciar atualizações de aplicativos descreve como usar a replicação geográfica ativa para habilitar as atualizações sem interrupção do seu aplicativo em nuvem para minimizar o tempo de inatividade durante as atualizações e fornecer um caminho de recuperação caso algo saia errado.
Economize nos 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 de espera sem licença para saber mais.
Próximas etapas
Para as considerações de design de aplicativo, confira Criar um aplicativo para recuperação de desastre na nuvem e Estratégias de recuperação de desastre para pool elástico.
Examine as Diretrizes de recuperação de desastre do Banco de Dados SQL do Azure e a Lista de verificação de alta disponibilidade e recuperação de desastre do Banco de Dados SQL do Azure.