Visão geral da continuidade de negócios com o Banco de Dados SQL do Azure
Aplica-se a:
Banco de Dados SQL do AzureBanco de Dados SQL no Fabric
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.
Visão geral
Continuidade de Negócios no Banco de Dados SQL Azure refere-se aos mecanismos, políticas e procedimentos que permitem que a sua empresa continue operando mesmo 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%.
Alta Disponibilidade
Para obter alta disponibilidade no ambiente de nuvem do Azure, habilite de 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 de desastres
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, em qualquer região, um banco de dados secundário legível, continuamente sincronizado com um banco de dados primário.
- 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 endpoints de escuta de leitura-gravação e somente leitura que permanecem inalterados, assim, não é necessário atualizar as strings de conexão da aplicação após o failover.
- Geo-restauro permite-lhe recuperar de uma interrupção regional ao restaurar a partir de cópias de segurança replicadas geograficamente, quando não conseguir aceder ao seu banco de dados na região primária. Pode criar 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 tolerância a falhas | |
|---|---|---|
| Sincronização contínua de dados entre o sistema primário e o secundário | Sim | Sim |
| Realizar 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 escalonamento de leitura | Sim | Sim |
| Várias réplicas | Sim | Não |
| Pode estar na mesma região que o primário | Sim | Não |
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 | Funcionalidade 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. Essas falhas são específicas do aplicativo e normalmente não podem ser detetadas pelo serviço de banco 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 de armazenamento com redundância geográfica por sete dias para todos os níveis de serviço. Todas as camadas de serviço, exceto a Basic, suportam um período de retenção de backup configurável para restauração no ponto no tempo (PITR) de até 35 dias. Você pode restaurar um banco de dados excluído ao ponto em que ele foi excluído se o servidor não tiver sido excluído ou se você tiver configurado 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 mitigar uma interrupção ao nível do datacenter ou da zona de disponibilidade, ative a redundância de zona para o banco de dados ou pool elástico, de forma a utilizar as Zonas de Disponibilidade do Azure e fornecer redundância através de várias zonas físicas dentro de uma região do Azure. Ao habilitar a redundância zonal, garante-se que o banco de dados ou grupo elástico seja resiliente a falhas de zona com um SLA de alta disponibilidade de até 99,995%%. |
| Rara interrupção regional afetando todas as zonas de disponibilidade e os datacenters que a compõem, possivelmente causada por um evento catastrófico de desastre natural. | Para atenuar uma interrupção em toda a região, ative a recuperação de desastres usando uma das seguintes opções: - opções de sincronização contínua de dados, como os grupos de failover (recomendado) ou a replicação geográfica ativa, que permitem criar réplicas em uma região secundária para failover. - Configuração do armazenamento de backup com redundância geográfica para utilizar a 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 (usando redundância de zona) |
Normalmente menos de 30 segundos | 0 |
| Recuperação de Desastres (Utilizando grupos de failover com política de failover gerida pelo cliente 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, dependendo da replicação de armazenamento do Azure | Normalmente, minutos ou horas, dependendo do tamanho do backup do banco de dados |
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 alta 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 não se preparar adequadamente, trazer as suas aplicações online após um failover ou recuperação leva mais tempo e requer provavelmente também resolução de problemas, o que pode atrasar o tempo de recuperaçã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 obter os tempos de recuperação, consulte RTO e RPO.
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.
Atualize um aplicativo com o mínimo de tempo de inatividade
Às vezes, um aplicativo deve ser colocado offline devido a manutenção, como uma atualização de aplicativo. Manage application upgrades descreve como usar a replicação geográfica ativa para habilitar atualizações contínuas de seu aplicativo em nuvem para minimizar o tempo de inatividade durante as atualizações e fornecer um caminho de recuperação se algo der errado.
Poupe nos custos com uma réplica de prontidão
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 livre de licenças 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.
Revise as diretrizes de recuperação de desastres do Banco de Dados SQL do Azure e a lista de verificação de alta disponibilidade e recuperação de desastres do Banco de Dados SQL do Azure.