Recuperação de Desastres

Duas noites ruins, dois desastres muito diferentes.

Na primeira, a região de nuvem onde o BoxOffice roda sofre uma grande indisponibilidade: a rede dentro da região fica degradada por horas. Todas as réplicas de todos os serviços estão nessa região — três zonas de disponibilidade, todas afetadas. A redundância dentro da região não ajuda.

Na segunda, tudo está no ar. Às 22:00, um engenheiro roda um script de limpeza contra o que ele acha que é o banco de homologação. É o de produção: DELETE FROM orders WHERE created_at < now() — todos os pedidos somem. O standby do PostgreSQL em outra zona replica fielmente o delete em milissegundos. A redundância também não ajuda aqui; ela espalhou o estrago.

Recuperação de desastres (DR, disaster recovery) é o conjunto de estratégias, ferramentas e procedimentos para restaurar serviço e dados depois de eventos como esses — eventos maiores do que os padrões de resiliência da página anterior absorvem. Ela começa com dois números.

RPO e RTO

RPO — Recovery Point Objective : A quantidade máxima de dados, medida em tempo, que você aceita perder. RPO = 5 minutos significa que, depois da recuperação, no máximo os últimos 5 minutos de escritas podem faltar.

RTO — Recovery Time Objective : O tempo máximo desde o desastre até o serviço ser restaurado. RTO = 1 hora significa que os fãs podem voltar a comprar ingressos no máximo uma hora depois da falha.

flowchart LR
    lb["último ponto de<br/>recuperação bom"] -->|"RPO: dados perdidos"| d(("desastre<br/>22:00"))
    d -->|"RTO: serviço fora"| r["serviço<br/>restaurado"]

São decisões de negócio expressas em minutos, e se traduzem em dinheiro: cada minuto de RTO durante uma abertura de vendas é venda perdida; cada minuto de RPO são pedidos (e pagamentos!) que precisam ser reconstruídos à mão ou estornados. Números menores custam mais, de forma aproximadamente exponencial.

Backups

Um backup é uma cópia dos dados, mantida de forma independente do original, a partir da qual você pode restaurar. Os tipos:

A recuperação para um ponto no tempo (PITR, point-in-time recovery) é o que salva a segunda noite. O PostgreSQL arquiva continuamente seu WAL³ em object storage (com ferramentas como pgBackRest ou WAL-G, ou automaticamente em bancos gerenciados como o Amazon RDS e o Cloud SQL). Para desfazer o delete das 22:00, restaure o backup base mais recente e reaplique o WAL até logo antes dele:

# restore the order database to 21:59:30, just before the accidental DELETE at 22:00
pgbackrest --stanza=order --type=time "--target=2027-03-14 21:59:30-03" \
  --target-action=promote restore

O RPO passa a ser o atraso do arquivamento do WAL (segundos a um minuto), e o RTO é o tempo de restauração, que você precisa estimar — e medir:

Regras para backups que funcionam de verdade

• 3-2-1: pelo menos 3 cópias dos dados, em 2 tipos diferentes de armazenamento, 1 delas fora do local (outra região ou conta). A prática moderna acrescenta uma cópia imutável (object lock / WORM — escreva uma vez, leia muitas) que nem um atacante com credenciais de administrador consegue apagar, contra ransomware.
• Separe o raio de impacto. Backups na mesma conta, com as mesmas credenciais da produção, podem ser apagados pelo mesmo erro ou pelo mesmo atacante.
• Cifre os backups e gerencie as chaves separadamente; um backup é uma cópia completa dos dados dos seus clientes (a LGPD/GDPR se aplica).
• Teste restaurações regularmente. Um backup que nunca foi restaurado é uma esperança. Automatize uma restauração periódica num ambiente descartável e verifique os dados (contagem de linhas, checksums, um smoke test da aplicação).
• Monitore os jobs de backup e o atraso do arquivamento do WAL; alerte quando falharem ou atrasarem.

Multi-AZ e multi-região

A replicação síncrona entre regiões coloca uma ida e volta entre regiões em cada escrita: \(\approx 30\)–\(100\) ms por commit costuma ser inaceitável no caminho de reserva de lugares. Por isso, DR multi-região em geral significa replicação assíncrona, e um RPO igual ao atraso da replicação no momento do desastre. É por isso que "RPO = 0 entre regiões" ou é muito caro (replicação síncrona, ou um banco globalmente consistente como Spanner ou CockroachDB pagando a latência) ou é um mal-entendido.

Multi-região também é uma questão jurídica: dados pessoais podem estar sujeitos a regras de residência (LGPD no Brasil, GDPR na União Europeia), que restringem quais regiões podem guardar a cópia.

As quatro estratégias de DR

O whitepaper de recuperação de desastres da AWS descreve um espectro de quatro estratégias, da barata e lenta à cara e instantânea¹. As mesmas ideias valem em qualquer nuvem².

flowchart LR
    subgraph A ["Região A (primária)"]
        appA["serviços"] --> dbA[("bancos")]
    end
    subgraph B ["Região B (recuperação)"]
        bk[("backups + WAL<br/>(object storage)")]
        iac["infraestrutura como código<br/>(nada rodando)"]
    end
    dbA -->|"backups, arquivo do WAL"| bk

flowchart LR
    subgraph A ["Região A (primária)"]
        appA["serviços"] --> dbA[("bancos")]
    end
    subgraph B ["Região B (recuperação)"]
        dbB[("réplicas dos bancos<br/>(rodando)")]
        appB["serviços<br/>(desligados: 0 réplicas)"]
    end
    dbA -->|"replicação assíncrona"| dbB

flowchart LR
    subgraph A ["Região A (primária, 100%)"]
        appA["serviços × 12"] --> dbA[("bancos")]
    end
    subgraph B ["Região B (standby, ~10%)"]
        appB["serviços × 2<br/>(rodando, ociosos)"] --> dbB[("réplicas")]
    end
    dbA -->|"replicação assíncrona"| dbB

flowchart LR
    dns["GeoDNS / LB global"] --> A
    dns --> B
    subgraph A ["Região A (atendendo)"]
        appA["serviços"] --> dbA[("dados")]
    end
    subgraph B ["Região B (atendendo)"]
        appB["serviços"] --> dbB[("dados")]
    end
    dbA <-->|"replicação nos dois sentidos"| dbB

Ativo-ativo e o inventário de lugares

Ativo-ativo é fácil para dados de leitura predominante: o catálogo pode ser lido em qualquer região a partir de réplicas locais e da CDN. É difícil para dados com invariantes fortes: se São Paulo e Virgínia aceitam reservas do lugar B-12 e replicam de forma assíncrona, dois fãs podem comprar o mesmo lugar — exatamente o que o BoxOffice nunca pode fazer (veja Consistência). As opções:

• Região de origem por entidade: cada evento (show) pertence a uma região; todas as reservas e vendas dele vão para lá; a outra região é o warm standby dele. Fãs em outras regiões pagam um pouco de latência por aquele show. A posse só muda durante um failover.
• Um banco globalmente consistente (Spanner, CockroachDB, YugabyteDB): consenso entre regiões em toda escrita, ao custo da latência entre regiões no caminho de reserva.
• Multi-líder com resolução de conflitos (last-writer-wins, CRDTs): ótimo para um carrinho de compras ou uma lista de "favoritos", inaceitável para lugares.

Failover entre regiões

Um failover regional é uma sequência de passos, cada um com uma duração que se soma ao RTO:

sequenceDiagram
    participant M as monitores externos
    participant OC as plantão
    participant DNS as DNS (com health check)
    participant A as região A
    participant B as região B (warm standby)
    Note over A: região degradada às 22:00
    M->>OC: probes de compra falhando em 3 locais (2 min)
    OC->>OC: confirma que é regional, declara desastre (5 min)
    OC->>A: fencing: bloqueia escritas em A (se alcançável)
    OC->>B: promove as réplicas dos bancos (1 min)
    OC->>B: escala os serviços de 2 para 12 réplicas (5 min)
    OC->>DNS: aponta boxoffice.example para a região B
    Note over DNS: os clientes seguem depois do TTL (60 s)
    DNS-->>B: o tráfego chega, RTO ≈ 14 min

Pontos que decidem se funciona:

• Detecção de fora. Probes que rodam dentro da região com falha podem falhar com ela. Use verificações sintéticas externas da jornada de compra.
• Decisão automática ou humana? Failover automático é rápido mas arriscado: uma oscilação de rede que dispara um failover regional (e depois um failback) pode causar mais estrago do que evita (flapping). Muitos times automatizam dentro de uma região e mantêm uma decisão humana, com runbook ensaiado, entre regiões.
• Fencing. Antes de o standby aceitar escritas, garanta que o primário antigo não consegue (revogue as credenciais, pare-o, ou use um lease). Dois primários aceitando reservas é split brain: lugares vendidos em dobro.
• TTL do DNS. Clientes e resolvedores guardam as respostas de DNS pelo TTL; um TTL de 1 hora significa uma cauda de 1 hora de tráfego indo para a região morta. Use registros de DNS com health check (por exemplo, registros de failover do Amazon Route 53) e TTLs curtos no ponto de entrada (veja DNS e CDN).
• Estabilidade estática. A região de recuperação não pode depender da que falhou: imagens de container, segredos, configuração e cotas de capacidade já precisam estar na região B.
• Failback. Voltar é outra migração: ressincronize os dados de B para A e então troque num horário tranquilo. Planeje e ensaie isso também.

O plano de DR do BoxOffice

Por que um warm standby para a camada 0, e não algo mais barato ou mais forte: o RTO de 15 minutos descarta backup e restore (só restaurar os 2 TB do banco do order leva cerca de 2,8 horas) e torna o pilot light arriscado (promover e escalar do zero leva dezenas de minutos); o ativo-ativo deixaria duas regiões venderem o assento B-12 ao mesmo tempo. O preço é uma segunda região rodando a cerca de um décimo da escala o ano todo, mais os exercícios que provam que ela consegue assumir.

E as práticas que mantêm o plano honesto:

• Um runbook por cenário (perda de região, corrupção de banco, conta comprometida) com os comandos exatos, os responsáveis e os critérios de decisão.
• Exercícios de DR duas vezes por ano: fazer de fato o failover para a região B por uma hora num período tranquilo, e restaurar um backup de produção num ambiente descartável todo mês. A página de engenharia do caos mostra como conduzi-los como game days.
• Revisar RPO/RTO com o negócio todo ano: o contrato do estádio pode exigir mais, ou a camada de analytics pode aceitar menos.

Como se conecta

flowchart LR
    BIZ["RPO e RTO<br/>por classe de dado"] --> STRAT["backup e restauração · pilot light ·<br/>warm standby · ativo-ativo"]
    INFRA["perda de infraestrutura<br/>(zona, região)"] --> REPL["replicação, multi-AZ<br/>→ Bancos de dados — replicação"]
    LOGIC["corrupção lógica<br/>(o DELETE errado)"] --> PITR["backups PITR, 3-2-1,<br/>cópia imutável"]
    REPL --> STRAT
    PITR --> STRAT
    STRAT --> AA["ativo-ativo vs a invariante dos assentos<br/>→ Distribuídos — consistência"]
    STRAT --> FO["failover regional:<br/>detectar, cercar, promover, escalar"]
    FO --> FENCE["fencing, sem split brain<br/>→ Distribuídos — consenso"]
    FO --> DNS["DNS com health check, TTL curto<br/>→ Borda — DNS"]
    FO --> DRILL["simulações de DR, testes de restauração<br/>→ Engenharia do caos"]

Componentes da paleta: sql (standby, réplicas, PITR) · objstore (backups base e o arquivo de WAL) · dns (registros de failover e TTL) · cdn (serve o catálogo desatualizado enquanto a origem se recupera) · kafka (reprocessa notificações não enviadas) · app (escalado de 2 para 12 réplicas na região standby). Cenários: db-failover, multi-region, db-replicas. Continua em: Bancos de dados — replicação, Distribuídos — consistência, Distribuídos — consenso, Borda — DNS e CDN, Cloud-native — entrega (infraestrutura como código), Projeto — game day.