Backup e disaster recovery para um banco de dados de dezenas de TB

Question

IT Interview Practice · Accepted Answer

**Combine snapshots periódicos com arquivamento contínuo de WAL para point-in-time recovery, replique offsite/cross-region, e comprove com restore drills regulares contra metas explícitas de RPO/RTO.** Um backup que você nunca restaurou é uma esperança, não um plano.

## Arquitetura

```text
Primary DB ──snapshot (daily)──▶ Object store (S3) ──cross-region replicate──▶ DR region
     │                               ▲
     └── WAL/binlog stream ──────────┘   (continuous, PITR to any second)
                                          │
                          restore drill ──┴──▶ verified restore ─▶ measure RTO, checksum RPO
```

## Como funciona

- **Snapshots** são uma cópia completa do volume/cluster (ex. snapshot EBS diário ou `pg_basebackup`). São a base *de onde* você restaura — mas restaurar apenas até ontem à noite perde um dia de escritas.
- **Arquivamento de WAL / binlog** faz streaming de toda mudança desde o último snapshot para o object store continuamente. Restore = snapshot + replay do WAL até qualquer segundo escolhido. Isso é **PITR (point-in-time recovery)** — recuperar para 10:32:04, o momento antes de um `DELETE` ruim.
- **Offsite / cross-region.** Um backup na mesma região que o DB morre com a região. Replique para uma segunda região (replicação cross-region do S3) para que uma indisponibilidade regional ou ransomware não leve ambos.
- **Restore drills.** Periodicamente restaure em um ambiente descartável, meça quanto tempo levou (**RTO**) e quanto de dados você teria perdido (**RPO**), e faça checksum contra a prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = quanto de dados você pode se dar ao luxo de perder. Arquivamento de WAL a cada 5 min → RPO ≈ 5 min. Réplica síncrona → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = quão rápido você precisa estar de volta. Restaurar 20TB do S3 pode levar horas; uma réplica warm standby corta o RTO para minutos.

## Perspectiva de entrevista

O entrevistador sonda se você sabe que **snapshots sozinhos não bastam** (perda de dados entre eles), se você consegue **definir RPO/RTO em números** e se você **testa restores**. Respostas excelentes enfatizam que backups não testados falham exatamente quando necessários, e escolhem uma estratégia a partir do RPO/RTO de *negócio*, não da conveniência. Uma armadilha: assumir que uma read replica é um backup — a replicação copia fielmente um `DROP TABLE` também.

## Trade-offs e falhas

- **Custo vs RTO.** Um warm standby cross-region dá minutos de RTO mas dobra o custo de infra; restore frio do S3 é barato mas lento. Compre a camada que o negócio realmente precisa.
- **Carga de backup.** Fazer snapshot de um DB quente de 20TB adiciona I/O; tire snapshots de uma réplica.
- **Corrupção silenciosa.** O WAL pode arquivar uma página corrompida; restore completo periódico + checksum pega isso.
- **Retenção e compliance.** Mantenha histórico suficiente (ex. 35 dias de PITR + arquivos mensais) para necessidades legais; Glacier para longo prazo barato.
- **Quando não usar:** um DB minúsculo está bem com `pg_dump` noturno para o S3 — WAL completo + standby cross-region é exagero até a perda de dados ser medida em dinheiro real.

Arquitetura

Como funciona

RPO vs RTO

Perspectiva de entrevista

Trade-offs e falhas

Perguntas relacionadas