O que é recuperação de desastre?
Um desastre é um evento individual e significativo, com um impacto e uma duração maiores do que um aplicativo pode atenuar por meio da parte de alta disponibilidade do design. A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR.
Objetivos de recuperação
Um plano de DR completo precisa especificar os seguintes requisitos comerciais críticos para cada processo implementado pelo aplicativo:
O RPO (objetivo de ponto de recuperação) é a duração máxima de perda de dados aceitável. O RPO é medido em unidades de tempo, não em volume, como "30 minutos de dados" ou "quatro horas de dados". O RPO se refere à limitação e à recuperação da perda de dados, não do roubo de dados.
O RTO (objetivo de tempo de recuperação) é a duração máxima de tempo de inatividade aceitável, em que "tempo de inatividade" é definido de acordo com a sua especificação. Por exemplo, se a duração do tempo de inatividade aceitável em um desastre for de oito horas, o RTO será de oito horas.
Cada processo ou carga de trabalho principal que um aplicativo implementa deve ter valores de RPO e RTO separados, examinando os riscos do cenário de desastre e as estratégias de recuperação potenciais. O processo de especificação de um RPO e RTO cria efetivamente requisitos de DR para seu aplicativo como resultado de suas preocupações comerciais exclusivas (custos, impacto, perda de dados, etc.).
Design para a recuperação de desastres
A recuperação de desastres não é um recurso automático, mas deve ser projetada, criada e testada. Para dar suporte a uma estratégia sólida de DR, você precisa criar um aplicativo com a DR em mente desde o início. O Azure oferece serviços, recursos e orientação para ajudá-lo a dar suporte à recuperação de desastres ao criar aplicativos.
Recuperação de dados
Durante um desastre, há dois métodos principais de restauração de dados: backups e replicação.
O backup restaura os dados para um point-in-time específico. Usando o backup, você pode fornecer soluções simples, seguras e econômicas para fazer backup e recuperar seus dados na nuvem do Microsoft Azure. Use o Backup do Azure para criar instantâneos de dados somente leitura de longa duração para uso na recuperação.
A Replicação de Dados cria cópias em tempo real ou quase em tempo real de dados em tempo real em várias réplicas de armazenamento de dados com o mínimo de perda de dados em mente. A meta da replicação é manter as réplicas sincronizadas com o mínimo de latência possível, mantendo a capacidade de resposta do aplicativo. A maioria dos sistemas de banco de dados completos, além de outros produtos e serviços de armazenamento de dados, inclui algum tipo de replicação como um recurso totalmente integrado devido aos requisitos funcionais e de desempenho. Um exemplo disso é o armazenamento com redundância geográfica (GRS).
Diferentes designs de replicação colocam prioridades distintas na consistência, no desempenho e nos custos de dados.
A replicação ativa requer atualizações para entrar em vigor em várias réplicas ao mesmo tempo, garantindo a consistência às custas da produtividade.
A replicação passiva realiza a sincronização em segundo plano, eliminando a replicação como uma restrição ao desempenho do aplicativo, mas aumentando o RPO.
A replicação ativa-ativa ou multimestre permite o uso de várias réplicas simultaneamente, permitindo o balanceamento de carga em detrimento da complicação da consistência dos dados.
A replicação ativa-passiva reserva réplicas para uso dinâmico somente durante o failover.
Observação
A maioria dos sistemas de banco de dados completos e outros produtos e serviços de armazenamento de dados incluem algum tipo de replicação, como o armazenamento com redundância geográfica (GRS), devido aos seus requisitos funcionais e de desempenho.
Como criar aplicativos resilientes
Os cenários de desastre também costumam resultar em tempo de inatividade, seja devido a problemas de conectividade de rede, interrupções do datacenter, danos em VMs (máquinas virtuais) ou implantações de software corrompidas. Na maioria dos casos, a recuperação de aplicativos envolve failover para uma implantação separada e funcional. Como resultado, pode ser necessário recuperar processos em outra região do Azure no caso de um desastre de grande escala. Considerações adicionais podem incluir: locais de recuperação, número de ambientes replicados e como manter esses ambientes.
Dependendo do design do aplicativo, você pode usar várias estratégias e recursos diferentes do Azure, como o Azure Site Recovery, para melhorar o suporte do aplicativo para recuperação de processos após um desastre.
Recursos de recuperação de desastres específicos do serviço
A maioria dos serviços executados na plataforma Azure como serviço (PaaS), como o Serviço de Aplicativo do Azure, fornece recursos e orientação para dar suporte à DR. Para alguns cenários, você pode usar recursos específicos do serviço para dar suporte à rápida recuperação. Por exemplo, o SQL Server do Azure dá suporte à replicação geográfica para restaurar rapidamente o serviço em outra região. O Serviço de Aplicativo do Azure tem um recurso de backup e restauração e a documentação inclui diretrizes para usar o Gerenciador de Tráfego do Azure para dar suporte ao roteamento de tráfego a uma região secundária.