Em um mundo cada vez mais digital, as organizações dependem como nunca dos seus serviços online. Quando há uma interrupção, as consequências para o negócio podem ser sérias. É aí que entra o disaster recovery na AWS: preparar-se para desastres que afetam sua infraestrutura de TI e seus dados — e se recuperar deles. A AWS (Amazon Web Services) oferece um framework robusto e flexível para o planejamento de disaster recovery, ajudando empresas a reduzir o tempo de inatividade e a se recuperarem mais rápido quando o inesperado acontece.
O que é um "desastre" no contexto de disaster recovery
Um "desastre", no contexto de disaster recovery, é qualquer evento que afete severamente as operações do seu negócio. Isso vai de desastres naturais como enchentes ou terremotos a ataques cibernéticos, quedas de energia e até erros humanos que causam perda de dados ou indisponibilidade de sistemas. O objetivo do planejamento de disaster recovery é antecipar esses cenários, por mais inesperados que sejam, e ter planos prontos para minimizar o impacto nas operações.
Modelo de Responsabilidade Compartilhada da AWS
Entender o Modelo de Responsabilidade Compartilhada da AWS é fundamental ao planejar o disaster recovery. A AWS opera nesse modelo, o que basicamente significa que AWS e cliente dividem as responsabilidades por um ambiente seguro e em conformidade.
A AWS é responsável pela segurança "da" nuvem, o que inclui a segurança física dos data centers, a infraestrutura global, o hardware e a rede. Já o cliente é responsável pela segurança "na" nuvem, ou seja, pela segurança dos dados, das aplicações, dos sistemas operacionais e do gerenciamento de identidades e acessos. Em resumo, a AWS garante uma base segura sobre a qual o cliente constrói e executa seus workloads com uma camada extra de segurança.
Alta disponibilidade vs. disaster recovery
Alta disponibilidade e disaster recovery são pilares de qualquer estratégia de TI consistente. Podem parecer a mesma coisa, mas têm propósitos diferentes.
Alta disponibilidade tem a ver com manter um nível aceitável de serviço durante a operação normal. Trata-se de projetar os sistemas para que continuem acessíveis mesmo quando componentes individuais falham. Pense em um site de varejo: se ele tiver uma configuração de alta disponibilidade, mesmo que uma instância caia, o site continua funcionando normalmente, porque a carga é distribuída entre as outras instâncias disponíveis.
Já o disaster recovery trata de restaurar os serviços depois de um evento disruptivo de grande porte. Envolve ter um plano para recuperar dados, aplicações e infraestrutura críticos depois de um desastre. Voltando ao exemplo: se esse mesmo site sofresse um ataque cibernético severo, com ampla perda de dados e indisponibilidade, o plano de disaster recovery orientaria a recuperação dos dados e o restabelecimento das funcionalidades do site.
Disaster recovery vs. continuidade de negócios
Disaster recovery e continuidade de negócios estão muito conectados, mas focam aspectos diferentes da gestão de crises.
Disaster recovery é um subconjunto da continuidade de negócios. Concentra-se nos processos técnicos necessários para recuperar sistemas, aplicações e dados depois de um desastre. Como no exemplo anterior, depois do ataque cibernético, o disaster recovery envolveria os passos para restaurar o site de varejo, corrigir as vulnerabilidades de segurança e colocar tudo no ar de novo.
Já a continuidade de negócios é uma abordagem ampla para garantir que as funções essenciais do negócio continuem operando durante e depois de um desastre. Enquanto o disaster recovery foca nos sistemas de TI e na recuperação de dados, a continuidade de negócios vai muito além. No exemplo do site de varejo, garantir a continuidade poderia significar reforçar a central de atendimento para dar conta do volume extra de chamados, criar procedimentos de venda temporários e manter os clientes informados, de forma proativa, sobre a situação e os prazos de resolução. Abrange todos os aspectos do negócio que podem ser afetados por um desastre — não só a TI.
Estratégias de disaster recovery
No planejamento de disaster recovery na AWS, há várias opções, dependendo das necessidades específicas dos seus workloads. Estas são quatro estratégias principais:
- Backup and Restore: uma das abordagens tradicionais de disaster recovery. Aqui, são feitos backups regulares para a nuvem e, em caso de desastre, eles são usados para restaurar dados e aplicações perdidos. É uma estratégia simples e econômica, já que você paga apenas pelos recursos de armazenamento consumidos pelos backups. O contraponto está no tempo de recuperação, que pode ser longo dependendo do volume de dados e aplicações a restaurar. É a opção mais indicada para aplicações não críticas, em que tempos de recuperação maiores são aceitáveis.
- Pilot Light: nessa abordagem, uma versão mínima do ambiente fica sempre ativa na nuvem. Esse "Pilot Light" reúne os elementos essenciais para manter o sistema funcionando, como o banco de dados e o servidor de aplicação. Em caso de desastre, novos recursos são provisionados rapidamente em torno desse núcleo para restaurar o sistema por completo. O tempo de recuperação é menor que no Backup and Restore, já que basta escalar serviços que já estão no ar. Em compensação, é mais cara, porque exige manter essa versão mínima do ambiente sempre rodando. A estratégia Pilot Light cai bem em aplicações críticas, em que tempos curtos de recuperação são importantes.
- Warm Standby: aqui, uma versão reduzida de um ambiente totalmente funcional fica sempre rodando na nuvem. Esse ambiente, chamado de standby, espelha o de produção e está pronto para assumir em caso de desastre. Nesse estado, ele consegue escalar rapidamente para suportar a carga de produção quando necessário. O Warm Standby oferece tempo de recuperação menor que o Backup and Restore e o Pilot Light, porque só é preciso escalar o sistema para lidar com o workload completo. Por outro lado, tem custo mais alto, já que o ambiente standby precisa ser mantido continuamente.
- Multi-Site: consiste em executar suas aplicações e serviços simultaneamente em mais de um site, normalmente em regiões geográficas diferentes. Todos os sites ficam ativos e dividem a carga durante a operação normal. Se um site cair, os demais continuam operando, garantindo serviço ininterrupto. A grande vantagem do Multi-Site é oferecer o menor tempo de recuperação entre todas as estratégias de DR, graças à sua natureza ativo-ativo. Em contrapartida, é a mais cara, pois envolve manter vários ambientes totalmente funcionais. Costuma ser usada em aplicações de missão crítica, em que alta disponibilidade e zero downtime são inegociáveis.
Cada estratégia tem suas vantagens, e a escolha depende dos requisitos específicos do seu workload. Dois fatores críticos nessa decisão são o seu Recovery Point Objective (RPO) e o Recovery Time Objective (RTO).
O RPO se refere à quantidade máxima aceitável de perda de dados, medida em tempo. Por exemplo, se um sistema tem RPO de 60 minutos, significa que as configurações e os dados precisam ser copiados de tal forma que, em caso de falha, você não perca mais do que 60 minutos de dados.
Já o RTO é o tempo-alvo dentro do qual um processo de negócio deve ser restaurado depois de um desastre, para evitar consequências inaceitáveis associadas a uma quebra na continuidade. Por exemplo, se o seu RTO é de 120 minutos, seus sistemas e aplicações precisam estar de volta ao ar em até 120 minutos após uma indisponibilidade.
A diferença entre RPO e RTO é essencial. Enquanto o RPO trata dos dados e da quantidade aceitável de perda, o RTO foca no tempo necessário para colocar o sistema de volta no ar.
Veja como RPO e RTO se relacionam com cada uma das quatro estratégias descritas:
- Backup and Restore:
- RTO: em caso de desastre, o RTO da estratégia Backup and Restore depende do tempo necessário para restaurar os backups. Esse prazo varia conforme fatores como o tamanho do backup, a velocidade do armazenamento e a complexidade do processo de restauração. Normalmente, o RTO dessa estratégia varia de horas a dias.
- RPO: o RPO do Backup and Restore é definido pelo intervalo entre os backups. Quando os backups acontecem em intervalos regulares, o RPO é o tempo entre o último backup bem-sucedido e o momento do desastre.
2. Pilot Light:
- RTO: a estratégia Pilot Light reduz o tempo de inatividade ao manter uma versão mínima do ambiente sempre rodando na nuvem. O RTO costuma ser relativamente curto, de minutos a algumas horas, dependendo do tempo necessário para escalar o ambiente.
- RPO: o RPO da Pilot Light depende da frequência de replicação de dados do ambiente principal para a versão mínima na nuvem. Pode variar, mas geralmente fica na faixa de minutos ou horas.
3. Warm Standby:
- RTO: com uma solução Warm Standby, o RTO é menor do que no Pilot Light, já que os sistemas já estão rodando. Costuma variar de minutos a algumas horas, dependendo dos processos de escalonamento e sincronização necessários.
- RPO: o RPO do Warm Standby depende da frequência de replicação ou sincronização de dados entre o ambiente principal e o ambiente standby na nuvem. Como no Pilot Light, geralmente fica na faixa de minutos ou horas.
4. Multi-Site:
- RTO: a estratégia Multi-Site busca alta disponibilidade e failover rápido executando workloads simultaneamente em vários sites ou regiões da AWS. O RTO pode ser bem curto, muitas vezes medido em segundos ou minutos, já que o tráfego é redirecionado rapidamente para o site alternativo em caso de desastre.
- RPO: o RPO do Multi-Site é definido pelo mecanismo de replicação de dados entre os sites ou regiões. Com replicação síncrona, o RPO pode ser próximo de zero, ou seja, perda mínima de dados. A replicação assíncrona pode introduzir um pequeno atraso, resultando em um RPO que vai de segundos a minutos.
O ideal é que a escolha da estratégia de disaster recovery esteja alinhada às suas necessidades de RPO e RTO. A estratégia precisa equilibrar custo, complexidade e os requisitos de disaster recovery. Uma estratégia que minimiza a perda de dados (RPO baixo) e o tempo de recuperação (RTO baixo) tende a ser mais complexa e cara, mas pode ser indispensável para workloads em que perda de dados e downtime geram impacto significativo no negócio. Para workloads não críticos, uma estratégia mais simples e econômica, com RPO e RTO mais altos, pode ser perfeitamente aceitável.
Principais serviços AWS para disaster recovery
A AWS oferece um conjunto de serviços que dão suporte a um disaster recovery eficiente e eficaz. Veja alguns dos principais:
AWS Elastic Disaster Recovery: uma solução para garantir a resiliência da sua infraestrutura. Oferece recuperação automatizada para diversos tipos de incidente, como falhas de infraestrutura ou de aplicação. Com replicação contínua de dados em nível de bloco, alcança RPOs em questão de segundos. Além disso, replica os dados continuamente para uma área de staging econômica dentro do ambiente AWS, reduzindo o consumo de recursos. Por meio de conversão e orquestração automatizadas das máquinas, consegue reduzir o RTO para apenas alguns minutos.
AWS Backup: o AWS Backup é um serviço centralizado que simplifica e automatiza o processo de backup em vários serviços AWS, incluindo EBS, RDS, DynamoDB, EFS e AWS Storage Gateway. Essa integração reduz a complexidade operacional e garante backups consistentes, contribuindo bastante para uma estratégia robusta de disaster recovery. O serviço também permite criar planos de backup com políticas que definem a frequência e o período de retenção, automatizando ainda mais o processo e reduzindo o risco de perda de dados. Tem papel central no atingimento das metas de RPO e RTO: ao agendar backups regulares, dá para minimizar a quantidade máxima aceitável de perda de dados (RPO) e, com a funcionalidade de restauração, reduzir o tempo de recuperação após um evento de perda de dados (RTO).
Amazon S3 Cross-Region Replication: esse recurso copia objetos de forma automática e assíncrona entre buckets em diferentes regiões da AWS. Em um cenário de disaster recovery, a função principal do Cross-Region Replication (CRR) é garantir que seus dados estejam disponíveis e duráveis mesmo diante de falhas regionais. Para isso, mantém um backup totalmente replicado dos seus dados em uma localização geográfica distinta, que não é afetada por desastres ocorridos no local original.
Amazon RDS: facilita configurar, operar e escalar um banco de dados relacional na nuvem. O RDS oferece backups automáticos, snapshots de banco de dados, réplicas de leitura entre regiões e, para alguns tipos de banco, até recursos de DR — tudo isso aproveitável em uma estratégia de disaster recovery, garantindo que seu banco possa ser restaurado rapidamente após um desastre.
Amazon Route 53: em um contexto de disaster recovery, um recurso fundamental do Route 53 é o SLA de disponibilidade de 100%. Essa garantia assegura que o serviço estará sempre operacional, oferecendo roteamento confiável para a infraestrutura da sua aplicação. Os health checks e o failover de DNS do Route 53 contribuem muito para sua utilidade em DR. O serviço monitora continuamente a saúde da sua aplicação e dos seus componentes por meio dos health checks. Quando uma falha ou anomalia é detectada em uma região AWS, o Route 53 redireciona o tráfego automaticamente para recursos saudáveis em outra região. Esse failover em nível de DNS faz com que, mesmo se uma região inteira cair, sua aplicação continue disponível para os usuários. Ao permitir a detecção e a resposta rápidas a falhas, os health checks e o failover de DNS do Route 53 reforçam a estratégia de disaster recovery, ajudando a reduzir o tempo de inatividade e a manter a alta disponibilidade da sua aplicação.
AWS Glacier: serviço de armazenamento de baixo custo para arquivar dados. Para disaster recovery, o Glacier é uma alternativa econômica para guardar backups de dados acessados com pouca frequência. Em caso de desastre, é possível recuperar esses dados, embora com tempos de recuperação maiores em relação ao Amazon S3.
AWS CloudFormation: permite o provisionamento e o gerenciamento automatizados de recursos no ambiente AWS. Com ele, dá para definir e implantar infraestrutura como código (IaC) usando templates do CloudFormation. Em uma situação de disaster recovery, esses templates podem ser usados para recriar rapidamente sua infraestrutura em outra região, acelerando os tempos de recuperação e mantendo a consistência entre ambientes. Vale lembrar que esses templates também precisam estar disponíveis na região de disaster recovery via S3 Cross-Region Replication, garantindo o acesso a eles na hora em que forem necessários.
Combinando esses serviços-chave em uma estratégia de disaster recovery, as empresas asseguram mecanismos robustos, escaláveis e otimizados para recuperar dados e aplicações críticos em caso de desastre.
Testes proativos de disaster recovery
A Netflix lançou o Chaos Monkey, ferramenta de teste de resiliência, no início dos anos 2010, como parte dos seus esforços de migração para a nuvem. Ao encerrar instâncias e serviços de forma aleatória, o Chaos Monkey simula falhas potenciais do sistema e gera insights valiosos sobre como ele reage durante interrupções críticas. Essa abordagem deu origem ao Chaos Engineering, uma disciplina focada em identificar e corrigir falhas de sistema de forma proativa, evitando interrupções de serviço. O Chaos Monkey, junto com o Chaos Engineering, tem papel crucial no disaster recovery, permitindo que as organizações avaliem a reação dos sistemas e os processos de recuperação. Por meio de testes controlados de cenários de falha, dá para identificar pontos fracos e lacunas nos planos de disaster recovery e fazer os ajustes necessários. Apesar de adicionar uma complexidade inicial, essa abordagem aumenta o preparo, ajudando as organizações a entenderem suas vulnerabilidades e a construírem sistemas mais robustos.
Outra ferramenta, o AWS Fault Injection Simulator (FIS), reforça a resiliência das aplicações ao permitir experimentos controlados de injeção de falhas em recursos AWS. Ao criar disrupções como interrupções de servidor ou throttling de API e observar a resposta do sistema, o FIS revela vulnerabilidades potenciais. No contexto do disaster recovery, ele ajuda a identificar pontos fracos na resiliência do sistema e dá às equipes de desenvolvimento condições de tratá-los de forma proativa, antes que provoquem interrupções de serviço. Com experimentos de injeção de falhas que simulam desastres potenciais, as equipes podem avaliar e aprimorar os procedimentos de recuperação em condições controladas. O resultado são planos de disaster recovery mais sólidos e maior resiliência do sistema, reduzindo o risco de interrupções em cenários reais.
Otimizando o disaster recovery com a expertise da DoiT
Quando o assunto é disaster recovery, a DoiT oferece serviços de planejamento e consultoria. Nosso time de arquitetos de nuvem experientes ajuda a montar um plano robusto, sob medida para as necessidades do seu negócio. Com nosso conhecimento aprofundado dos serviços e da infraestrutura AWS, podemos orientar sobre boas práticas, procedimentos de recuperação e configurações ideais para aumentar a resiliência dos seus workloads.
Planejar o disaster recovery vai muito além de configurar um sistema de backup. Envolve uma análise profunda das suas operações, a compreensão dos serviços críticos e a definição de pontos e tempos de recuperação aceitáveis. Nosso time conduz você por esse processo, garantindo uma estratégia abrangente, alinhada aos seus objetivos de continuidade de negócios.
Testes regulares são cruciais para garantir que o plano funcione como esperado e que o time esteja preparado para o evento real. Ajudamos no desenho desses testes e na identificação de possíveis lacunas e oportunidades de melhoria. E se você precisar acionar o disaster recovery e algo der errado, a DoiT está pronta para ajudar. Em situações assim, cada minuto conta. Nosso time é preparado para responder com rapidez e eficiência, ajudando a restaurar serviços e a reduzir o tempo de inatividade. Seja para resolver um problema pontual, seja para dar orientação técnica, estamos com você na crise. E nosso trabalho não acaba na recuperação: depois que tudo volta ao normal, ajudamos a analisar o evento, avaliar a eficácia do processo de recuperação e compartilhar orientação técnica e boas práticas.
Na DoiT, nos enxergamos como seu parceiro na continuidade e na resiliência do negócio. Do planejamento e dos testes à recuperação e ao aprendizado, estamos com você em cada etapa da jornada de disaster recovery.
Conclusão
Disaster recovery não é parte opcional da estratégia de negócios — é um componente crítico que garante a continuidade diante de eventos inesperados. Aproveitando o poder e a flexibilidade da AWS, as empresas conseguem montar planos robustos de disaster recovery que reduzem o tempo de inatividade e a perda de dados, garantindo retomada rápida das operações quando o desastre acontece. Uma consultoria profissional ajuda a identificar potenciais vulnerabilidades nos seus sistemas e a indicar os serviços AWS adequados para tratá-las. Essa expertise economiza tempo e esforço e ainda evita armadilhas comuns, resultando em um plano de disaster recovery mais robusto e eficaz. Em resumo: com a AWS como sua plataforma de disaster recovery e a DoiT como parceira de confiança, você ganha a segurança de que o negócio resiste a interrupções e mantém a continuidade. Estamos comprometidos em oferecer um ambiente de nuvem resiliente e seguro, ajudando você a transformar uma adversidade potencial em uma prova da resiliência do seu negócio.