Recuperação de desastre

Recuperação de desastre é o plano para quando a alta disponibilidade não basta: a região inteira ficou fora, a conta foi comprometida, ou uma exclusão em cascata apagou o ambiente. São eventos raros — e é justamente por isso que o plano precisa estar escrito e ensaiado. Ninguém improvisa bem no dia em que a região de São Paulo não responde.

Cenários reais, em ordem de probabilidade

1. Erro humano: terraform destroy no diretório errado, DROP TABLE, exclusão de bucket. O mais frequente, de longe.
2. Comprometimento de credencial: alguém com acesso apaga ou criptografa recursos.
3. Falha de serviço gerenciado numa região: raro, acontece, e costuma durar horas.
4. Corrupção silenciosa de dados: descoberta dias depois, quando os backups recentes já contêm o problema.
5. Perda da conta ou do provedor: bloqueio administrativo, disputa contratual.

Repare que só o terceiro é “desastre” no sentido clássico. Um plano de DR que só cobre queda de região deixa de fora os quatro cenários mais prováveis — e por isso a resposta a erro humano (backup imutável, em conta separada, com PITR) é o investimento com melhor retorno.

Do restore ao ativo-ativo

Estratégia	RTO típico	Custo	Como funciona
Backup e restore	horas a dias	mínimo	Backups em outra região; infraestrutura recriada por IaC no dia
Pilot light	1 a 4 horas	baixo	Dado replicado e infraestrutura mínima ligada; o resto sobe no evento
Warm standby	15 a 60 min	médio	Ambiente reduzido, rodando, pronto para escalar
Ativo-ativo	segundos a minutos	alto	Duas regiões atendendo tráfego real

Ativo-ativo parece o ideal e cobra caro em complexidade: dado replicado em duas direções, conflito de escrita, roteamento e testes constantes. Só vale quando o negócio realmente não tolera minutos fora — e quando existe time para manter.

Para a maioria dos serviços, pilot light é o ponto de equilíbrio: o dado está seguro e atualizado na outra região, e o que falta é capacidade computacional, que a IaC provisiona em minutos.

Escolha pelo RTO, e valide o custo

Faça a conta explícita antes de decidir:

Custo do minuto fora × RTO da estratégia   versus   custo mensal da estratégia

Um serviço interno que para por 4 horas uma vez a cada três anos raramente justifica warm standby. Um checkout que perde receita por minuto justifica.

Classifique os sistemas em três níveis (crítico, importante, tolerável), atribua uma estratégia por nível e documente. Sem classificação, ou tudo vira crítico (e o orçamento some) ou nada é (e o desastre vira surpresa).

O plano precisa ser executável sob pressão

Um documento de trinta páginas não é lido às 3h. O que funciona é um runbook curto, específico e verificado:

# DR — Serviço de pedidos (RTO 2h, RPO 15min)

**Quando executar.** Região sa-east-1 indisponível por mais de 30 min, confirmado por
@plantao com o comando abaixo. Quem declara: o comando do incidente.

## 1. Verificar (5 min)
    aws health describe-events --region us-east-1
    dig +short api.exemplo.com

## 2. Promover o banco (20 min)
    aws rds promote-read-replica --db-instance-identifier loja-replica-us

## 3. Subir a aplicação (30 min)
    cd infra/dr/us-east-1 && terraform apply -var ativo=true

## 4. Redirecionar o tráfego (10 min)
    # Route 53: registro loja.exemplo.com → ALB do DR (TTL já é 60s)

## 5. Verificar
    curl -sf https://loja.exemplo.com/health && echo ok
    Painel: <link>. Confirme pedidos entrando nos últimos 5 minutos.

**Contatos.** Comunicação: @ana. Provedor: caso de suporte severidade 1.
**Voltar para a região principal:** procedimento separado, sem pressa, fora do pico.

Detalhes que fazem diferença: TTL de DNS baixo já configurado (não adianta reduzir durante o desastre), credenciais e acesso ao runbook fora da região afetada, e uma cópia do plano acessível quando o wiki também estiver fora.

Exercício de DR

Sem ensaio, o plano é uma hipótese. Amadureça em três níveis:

1. Leitura em mesa (trimestral, 1 hora): o time percorre o runbook e aponta o que não faz sentido. Barato, e sempre encontra coisa.
2. Exercício parcial (semestral): promova a réplica em ambiente de teste, suba a infraestrutura de DR, meça o tempo real.
3. Exercício completo (anual): desvie tráfego de verdade para a região secundária, em janela combinada.

Registre sempre o tempo real de cada etapa — ele quase nunca é o estimado — e trate as descobertas como postmortem, com ações, dono e prazo. Os achados mais comuns não são técnicos: acesso que falta, dependência esquecida (DNS, e-mail transacional, gateway de pagamento), quota insuficiente na região secundária e a pessoa-chave inalcançável.

Próximo passo: você fechou a trilha de Dados. Ligue o plano à prática de incidentes em Resposta a incidentes e exercite o restore em Testar restore.