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 RPO e RTO separados examinando riscos de cenário de desastre e possíveis estratégias de recuperação. O processo de especificação de um RPO e RTO efetivamente cria 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 desastre 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 diretrizes para ajudá-lo a dar suporte à DR ao criar aplicativos. Para entender o que você precisa fazer para dar suporte à DR, primeiro você deve entender o modelo de responsabilidade compartilhada para resiliência. Para obter mais informações, consulte Responsabilidade compartilhada pela resiliência.
Recuperação de dados
Durante um desastre, há dois métodos principais de restauração de dados: backups e replicação.
Backup restaura dados para um ponto específico no tempo. 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 Backup do Azure para criar instantâneos de dados somente leitura de longa duração para uso na recuperação.
Replicação de Dados cria cópias em tempo real ou quase em tempo real de dados dinâmicos em várias réplicas de armazenamento de dados com perda mínima 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 é GRS (armazenamento com redundância geográfica).
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
Os sistemas de banco de dados mais completos e outros produtos e serviços de armazenamento de dados incluem algum tipo de replicação, como GRS (armazenamento com redundância geográfica), devido aos 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 aplicativo 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 em 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 diferentes e recursos do Azure, como Azure Site Recovery, para melhorar o suporte do aplicativo para recuperação de processo após um desastre.
Recursos de recuperação de desastre específicos do serviço
A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure, como Serviço de Aplicativo do Azure fornecem recursos e diretrizes 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.