Em agosto de 2016, o Delta Airlines sofreu uma falha de energia em sua infraestrutura de data center primário em Atlanta. A falha durou algumas horas, mas o impacto foi catastrófico: mais de 2.000 voos cancelados, 3 dias para normalização completa das operações, e estimativa de perdas de US$150 milhões. O plano de disaster recovery do Delta existia — mas não havia sido testado com a frequência necessária para garantir que funcionava sob as condições reais da falha. Sistemas que o plano assumia como disponíveis não estavam. Procedimentos que pareciam claros no papel criaram ambiguidade na execução.
O episódio do Delta ilustra o princípio central deste conceito: disaster recovery sem teste periódico é ilusão de segurança. Um plano de DR não testado é essencialmente uma hipótese não verificada sobre como o sistema se comportaria sob condições catastróficas — e hipóteses não verificadas sobre sistemas críticos são, por definição, confiança não justificada.
Disaster recovery (DR) formal é o conjunto de processos, ferramentas e acordos que garantem que um sistema pode ser recuperado após uma falha catastrófica — falha de data center, corrupção massiva de dados, ataque de ransomware, desastre natural. A distinção de DR para incident response (conceito 11) é a escala: incident response lida com falhas parciais e degradações; DR lida com perda total ou quase total da capacidade operacional.
RTO e RPO — os dois SLOs de recuperação
Dois indicadores definem as expectativas de um plano de DR. Assim como SLOs de disponibilidade definem o que significa "sistema saudável", RTO e RPO definem o que significa "recuperação aceitável".
RTO — Recovery Time Objective: o tempo máximo aceitável entre o início da falha catastrófica e a restauração do serviço a um estado operacional. "Operacional" precisa ser definido — não necessariamente 100% da capacidade, mas uma capacidade mínima aceitável para o negócio continuar funcionando.
Exemplos: RTO de 4 horas significa que o negócio aceita até 4 horas de downtime antes que a incapacidade de operar comece a causar dano irreparável (contratos com SLA violados, usuários migrando para concorrentes, dano à reputação irreversível). RTO de 15 minutos significa que o sistema deve ser capaz de retornar a operação em menos de 15 minutos — o que exige automação significativa.
RPO — Recovery Point Objective: a janela máxima de dados que é aceitável perder na recuperação. Em outras palavras: qual é a data do backup mais antigo que você poderia restaurar e ainda consideraria a perda de dados aceitável?
Exemplos: RPO de 24 horas significa que o sistema pode, em último caso, ser recuperado com dados de até 24 horas atrás sem causar dano inaceitável ao negócio. RPO de 0 (zero) — chamado de "zero data loss" — significa que nenhuma transação pode ser perdida, o que exige replicação síncrona para standby.
RTO e RPO são definidos pelo negócio, não pela engenharia. Engenharia pode dizer "RTO de 1 hora é tecnicamente viável com esse orçamento" — mas quem define se 1 hora é aceitável é o negócio. A conversa entre engenharia e negócio sobre RTO/RPO é onde as implicações de custo se tornam claras: RPO de 1 hora exige backups a cada hora; RPO de 0 exige replicação síncrona. O custo aumenta exponencialmente conforme RTO e RPO diminuem.
A relação entre RTO, RPO e custo
O trade-off fundamental de DR é o custo da redundância vs o custo do downtime. Planos com RTO/RPO muito agressivos exigem infraestrutura redundante que opera em standby — paga mesmo quando não está sendo usada. Planos com RTO/RPO mais tolerantes permitem infraestrutura mais simples, mas com maior custo quando o desastre acontece.
| Tier de DR | RTO | RPO | Modelo | Custo relativo |
|---|---|---|---|---|
| Hot standby | < 5 min | ~0 | Ambiente completo em execução ativa, replicação síncrona | 2× (dois ambientes completos) |
| Warm standby | 15–60 min | 15 min | Ambiente mínimo em execução, replicação assíncrona | 1.3–1.5× |
| Pilot light | 1–4h | 1h | Apenas dados replicados; infra provisionada on-demand | 1.1× |
| Backup & restore | 4–24h | 24h | Backups periódicos; ambiente recriado do zero em DR | ~1× (custo de backup apenas) |
A escolha do tier não é estática para o sistema inteiro. Em sistemas com múltiplos componentes, componentes críticos (banco de dados transacional, serviços de autenticação) podem ser hot standby enquanto componentes menos críticos (analytics, relatórios, histórico) podem ser warm standby ou mesmo backup & restore.
O runbook de DR
O plano de DR que existe apenas na cabeça do arquiteto ou em um documento de 100 páginas que ninguém lê não é um plano operacional — é arqueologia. Um runbook de DR eficaz é executável: uma sequência de passos específicos que um engenheiro sem contexto histórico pode seguir para restaurar o serviço dentro do RTO.
A estrutura de um runbook de DR:
RUNBOOK DE DISASTER RECOVERY — Serviço de Checkout
1. TRIGGER — Quando executar este runbook
- Falha completa da região primária (us-east-1)
- Perda de acesso ao banco de dados por > 30 minutos
- Corrupção detectada nos dados de pedidos
2. CONTEXTO
- Região DR: us-west-2
- Ambiente DR: checkout-dr (warm standby, 2 instâncias)
- Banco DR: checkout-replica-west (replicação assíncrona, RPO ~15min)
- DNS: checkout.example.com → gerenciado por Route 53
3. PASSOS DE ATIVAÇÃO
3.1. Verificar estado do ambiente DR
→ AWS Console → EC2 → Região us-west-2 →
Instâncias do grupo checkout-dr
→ Esperado: 2 instâncias running
→ Se stopped: iniciar via: aws ec2 start-instances
--instance-ids [ids do runbook]
3.2. Promover réplica de banco para primária
→ AWS Console → RDS → checkout-replica-west →
Actions → Promote Read Replica
→ Aguardar status: Available (~5 minutos)
3.3. Atualizar configuração da aplicação
→ SSM Parameter Store → /checkout/db/endpoint
→ atualizar para: checkout-dr.xxxxxx.us-west-2.rds.amazonaws.com
→ Reiniciar instâncias do grupo checkout-dr
3.4. Validar serviço DR
→ Curl: https://checkout-dr.internal/health
→ Esperado: {"status": "healthy", "db": "connected"}
3.5. Failover de DNS
→ Route 53 → checkout.example.com →
Alterar destino para load balancer us-west-2
→ TTL: 60s → aguardar propagação
3.6. Confirmar operação
→ Executar smoke test: scripts/dr-smoke-test.sh
→ Notificar #incidentes: "Failover DR concluído"
4. CONTATOS DE ESCALAÇÃO
- Database: db-on-call@example.com
- Network: network@example.com
- Business: cto@example.com
5. RTO ALVO: 45 minutos | RPO ALVO: 15 minutosTestando o plano de DR
Esta é a parte mais importante e mais negligenciada. Um plano de DR não testado tem probabilidade desconhecida de funcionar quando necessário — e a experiência da indústria (Delta, GitLab em 2017, Fastly em 2021) mostra que planos não testados frequentemente falham em pontos inesperados.
Existem três níveis de teste de DR, em ordem crescente de confiança:
Teste de documentação (tabletop): revisão do runbook com a equipe, sem execução real. Cada passo é lido em voz alta e a equipe responde: "isso funcionaria?" e "quais seriam os problemas?". Detecta inconsistências óbvias, passos ausentes, e suposições incorretas. Baixo custo, pode ser feito mensalmente.
Teste de componente: testar passos específicos do runbook isoladamente. Verificar que a réplica de banco pode ser promovida. Verificar que o failover de DNS funciona. Verificar que as instâncias de warm standby iniciam corretamente. Cada componente testado separadamente, sem acionar o failover completo. Pode ser feito trimestralmente.
Teste completo (failover real): executar o runbook completo — inclusive o failover de DNS — em horário de baixo tráfego, com usuários reais ou com tráfego sintético. É o único teste que realmente valida o RTO e o RPO. Deve ser feito anualmente no mínimo, idealmente semestralmente.
DR testado somente em staging é DR parcialmente testado. O ambiente de staging raramente tem os mesmos dados, as mesmas dependências de terceiros, e o mesmo volume de tráfego que produção. O failover de DNS em staging pode ser instantâneo; em produção com caches espalhados por CDNs globais, pode demorar horas. Planejar para as diferenças e testar em produção pelo menos uma vez ao ano é o padrão de maturidade.
DR e cloud — o modelo AWS
A AWS divide seus recursos em Availability Zones (AZs) dentro de regiões e em regiões geográficas. O modelo de DR mais comum em AWS usa Multiple AZs para alta disponibilidade normal (dois AZs na mesma região, failover automático) e uma segunda região para DR verdadeiro (falha de região inteira).
O AWS Well-Architected Framework define quatro estratégias de DR com nomes específicos que correspondem aos tiers acima: Multi-site active/active (hot standby), Warm standby, Pilot light, e Backup and restore. Cada uma tem trade-offs de custo e capacidade de recuperação documentados com números reais da AWS.
AWS Route 53 com health checks permite failover automático de DNS quando a região primária falha — o que pode reduzir RTO de horas para minutos para casos onde a infra de DR já está running (warm standby ou hot).
DR e dados — o problema mais difícil
Recovery de aplicação (instâncias, load balancers, configuração) é relativamente simples — tudo pode ser código, replicado automaticamente. Recovery de dados é o problema difícil: dados transacionais perdidos são frequentemente irrecuperáveis, e dados corrompidos podem ser mais problemáticos que dados ausentes.
As práticas essenciais para DR de dados:
Backups regulares e verificados: backups que não são verificados regularmente são backups de confiabilidade desconhecida. Um script simples que restaura o backup em um ambiente de teste e verifica a integridade dos dados deve rodar automaticamente e regularmente.
Replicação e lag de replicação: réplicas assíncronas têm lag — o quanto a réplica está atrás do primário. O lag de replicação é o RPO efetivo para failover não planejado. Monitorar o lag de replicação como SLI é essencial: se o lag aumenta para horas, o RPO efetivo está sendo violado mesmo sem nenhum incidente.
Imutabilidade de backups: backups que podem ser sobrescritos (por acidente ou por ransomware) não são backups confiáveis. Usar S3 com Object Lock (WORM — Write Once Read Many) ou equivalente garante que backups não podem ser deletados ou modificados por um período definido.
Como praticar
- Definir RTO e RPO para um serviço. Para um serviço crítico que você opera, calcule: qual o custo por hora de downtime para o negócio? Qual a quantidade máxima de dados que pode ser perdida sem dano irreparável? Essas respostas definem RTO e RPO. Compare com a capacidade de recuperação atual: quanto tempo levaria para restaurar o serviço de um backup hoje? Esse gap é a dívida de DR.
- Escrever um runbook de DR mínimo. Para o mesmo serviço, escreva um runbook de DR com a estrutura acima: trigger, contexto, passos, contatos, RTO/RPO alvo. Não precisa ser perfeito — precisa ser executável. Peça para um colega que não conhece o serviço ler o runbook e dizer onde ficou confuso. Cada ponto de confusão é um gap a corrigir.
- Verificar integridade de backups. Verifique os backups do banco de dados de um serviço: quando foi o último backup? Qual o tamanho? Foi verificado (restaurado e consultado)? Se não há verificação automática de backups, implemente um job que restaura o backup mais recente em um ambiente de teste a cada semana e verifica que os dados são consultáveis. Esse job deve alertar se falhar.
Referências para aprofundar
- livro Site Reliability Engineering — Beyer et al. (O'Reilly, 2016).
- docs AWS Disaster Recovery Whitepaper — aws.amazon.com.
- artigo Disaster Recovery Testing — Why You Need to Test Your DR Plan — Gremlin Blog, 2021.
- artigo GitLab's Database Incident (2017) — GitLab.com.
- docs AWS Well-Architected Framework — Reliability Pillar DR Strategies.
- artigo RTO and RPO Explained — Druva Blog, 2022.
- vídeo Database DR Testing at Stripe — SREcon Americas, 2019.
- artigo The Fallacy of the Tested Backup — Paul Venezia (InfoWorld, 2015).
- docs Amazon S3 Object Lock — WORM Storage — AWS Docs.
- artigo Chaos Engineering for Disaster Recovery — Netflix Tech Blog, 2020.
- paper Weathering the Unexpected — Kripa Krishnan (ACM Queue, 2012).
- artigo Delta Air Lines IT Outage — Post-Incident Analysis — Aviation Today.