Noções Básicas de DR
Recuperação de desastres (DR) prepara para falha em nível de região ou falha total do site. Defina RPO (quanta perda de dados você pode ter) e RTO (quanto tempo até o serviço retornar) por nível de aplicação, depois projete backups e réplicas para corresponder.
Receita
Exemplo de matriz de níveis para cargas de trabalho PostgreSQL 18.4.
| Nível | RPO | RTO | Padrão |
|---|---|---|---|
| Nível 0 (pagamentos) | < 1 min | < 1 hr | Réplica síncrona ou assíncrona + WAL fora do local |
| Nível 1 (aplicativo principal) | < 15 min | < 4 hr | Réplica assíncrona entre regiões + PITR |
| Nível 2 (análise) | < 24 hr | < 24 hr | Dump lógico diário para região de DR |
-- Documenta a janela de perda aceita (tabela de metadados interna)
INSERT INTO dr_tier_registry (service, tier, rpo_minutes, rto_minutes, approved_by)
VALUES ('checkout-db', 0, 1, 60, 'cto@example.com');Quando usar isso: Antes de assinar SLAs de clientes ou controles SOC2 que mencionam continuidade de negócios.
Exemplo de Trabalho
Traduza requisitos de negócios em controles técnicos:
# Região de DR: verifique se o último arquivo de arquivamento WAL chegou
aws s3 ls s3://prod-pg-wal-dr/ --recursive | tail -5
# Latência da réplica entre regiões (física assíncrona)
psql -h dr-replica.eu-west.db.internal -c "
SELECT now() - pg_last_xact_replay_timestamp() AS replay_age;"-- Consulta de resumo para stakeholders (anexo do runbook)
SELECT tier, rpo_minutes, rto_minutes,
rpo_minutes || ' min de perda de dados máx' AS rpo_plain,
rto_minutes || ' min de inatividade máx' AS rto_plain
FROM dr_tier_registry
ORDER BY tier;O que isso demonstra:
- RPO/RTO são números de negócios apoiados por latência de replicação e frescor do arquivo.
- Recursos da região de DR devem existir antes do desastre, não provisionados durante o incidente.
- A tabela de registro força a aprovação explícita das janelas de perda de dados.
Mergulho Profundo
RPO vs RTO
| Termo | Pergunta respondida | Alavancas do PostgreSQL |
|---|---|---|
| RPO | Quanta perda de dados podemos ter? | Rep síncrona, frequência de arquivamento, idade do backup |
| RTO | Quanto tempo até os usuários serem atendidos? | Automação de restauração, cutover de DNS, escala de aplicativos |
| MRT | Tempo médio de recuperação (histórico) | Medições de simulação |
HA vs DR
| Escopo | HA | DR |
|---|---|---|
| Falha | Nó, AZ, primário | Região, provedor, ransomware |
| Ferramentas | Patroni 3.x, PgBouncer | Réplica entre regiões, backup fora do local |
| RTO | Segundos a minutos | Horas |
| Frequência de teste | Failover trimestral | Jogo anual ou semestral |
Perda de Dados Aceita
Documente em linguagem clara: "O Nível 1 aceita que até 15 minutos de transações confirmadas podem não ser recuperáveis se o primário e os backups locais forem perdidos simultaneamente."
Armadilhas
- Réplica na mesma região como DR - A perda da região mata ambos. Correção: WAL entre regiões e réplica.
- RPO no papel apenas - Nenhuma medição de latência de arquivo ou atraso de replicação. Correção: Dashboards com alertas alinhados a SLOs.
- RTO ignora DNS e aplicativo - DB restaurado em 30 min; aplicativos inativos por 6 horas. Correção: Jogo de ponta a ponta.
- Um nível para todos os bancos de dados - Pagar a mais ou proteger a menos. Correção: Nível por serviço no registro.
- DR nunca testado - Backups frios corrompidos. Correção: Jogos de DR no calendário.
Alternativas
| Alternativa | Usar Quando | Não Usar Quando |
|---|---|---|
| Multi-região Ativo-Ativo | RTO extremo | SaaS B2B padrão |
| DR apenas com backup (sem réplica quente) | Análise de Nível 2 | Pagamentos de Nível 0 |
| Banco de dados global gerenciado | Aurora Global, etc. | Residência de dados estrita |
FAQs
Quem aprova o RPO?
Liderança de produto + jurídica + engenharia. DBAs implementam; eles não aceitam unilateralmente perda de dados.
É possível RPO zero?
Replicação síncrona dentro da região se aproxima de perda confirmada zero; RPO zero entre regiões requer arquiteturas especializadas e custo de latência.
DR para cluster Patroni?
Escopo Patroni separado na região de DR ou restauração de pgBackRest para um novo cluster; documentar o cutover.
Ransomware e DR?
Backups imutáveis fora do local e ambiente de restauração isolado; a replicação sozinha replica cargas criptografadas.
Como se relacionar com o SLO de uptime?
HA protege o orçamento de erro mensal; DR protege falhas existenciais de região. Veja SLOs de Uptime para Datastores.
Relacionados
- Réplicas entre Regiões - sites de DR assíncronos
- Runbook e Comunicações de DR - declaração de incidente
- Noções Básicas de HA - limite HA vs DR
- Noções Básicas de PITR - precisão de rebobinamento
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.