Melhores Práticas de Backup

Automatize restaurações, não apenas dumps - backups não testados são ficção. Estas regras mantêm os backups do PostgreSQL recuperáveis sob pressão real de incidentes.

Como Usar Esta Lista

• Aplique ao projetar trabalhos e retenção de backups.
• Use a execução mensal de verificação como um checklist de aprovação/reprovação.
• Combine com os requisitos de retenção de conformidade.
• Revise após qualquer simulação de restauração falha ou lenta.

A - Estratégia

• Use backups lógicos e físicos juntos. Lógicos para objetos; físicos para PITR e cluster completo.
• Siga a regra 3-2-1: três cópias, dois tipos de mídia, uma off-site. Independente da replicação.
• Nunca trate réplicas em standby como backup. A replicação reexecuta exclusões e corrupções.
• Faça dump dos globais (pg_dumpall -g) em agendamento. Roles e tablespaces não estão apenas no dump por banco de dados.
• Criptografe backups em repouso e em trânsito. S3 SSE-KMS, TLS ou gpg para arquivos.

B - Operações de Dump

• Prefira -Fc ou -Fd em vez de SQL puro para tamanho de produção. Permite restauração paralela.
• Execute pg_dump grande fora do horário de pico ou a partir de um standby. Reduz a carga no primário.
• Tabelas Tier-0 recebem dumps dedicados por objeto. Mais rápido que cluster completo para recuperação de "ops".
• Monitore a duração do trabalho de dump e o tamanho da saída. Redução súbita significa falha ou esquema vazio.
• O usuário de backup usa privilégio mínimo com acesso de leitura a todos os dados necessários. Documente a política de bypass de RLS.

C - Físico e WAL

• Habilite archive_mode ou pgBackRest para backups capazes de PITR. A replicação sozinha é insuficiente.
• Monitore pg_stat_archiver.failed_count. Falhas de arquivamento ampliam silenciosamente o RPO.
• Retenha WAL de acordo com a janela de conformidade mais uma margem de segurança. Alinhe com retenções legais.
• Teste a restauração física trimestralmente. A verificação apenas lógica perde lacunas no WAL.
• Coordene a pausa do Patroni apenas quando a ferramenta de backup exigir. Documente no runbook.

D - Verificação

• Automatize a restauração mensal para uma instância PostgreSQL 18.4 limpa. Não apenas ls -l nos arquivos.
• Registre RESTORE_RTO_SECONDS a cada execução de verificação. Prove as alegações de RTO da liderança.
• Compare contagens de linhas ou checksums após a restauração. Capture dumps truncados.
• Alerta sobre falha de verificação como risco de dados de severidade 1. Trate como incidente de produção.
• Puxe a cópia de verificação da réplica off-site. Backup em disco local pode mentir.

E - Operações e Acesso

• Restrinja o IAM do bucket de backup apenas para roles de backup e verificação. Sem servidores de aplicação.
• Retenção de versão: diária 7, semanal 4, mensal 12 no mínimo para tier-0. Ajuste para o tier de RPO.
• Documente quem pode acionar a restauração e para quais ambientes. Evite sobrescrever produção.
• Runbook vincula o ID do backup aos passos de restauração. O plantonista não faz grep na wiki durante incidentes de severidade.
• Pós-incidente: se o backup foi usado, redefina a base e verifique a próxima cópia. Confirme se a cadeia está intacta.

FAQs

Relacionados

• Noções Básicas de Backup - lógico vs físico
• Verificação de Backup - prova automatizada
• Noções Básicas de PITR - cadeia WAL
• Melhores Práticas de DR - postura off-site

Versões de Stack: Esta página foi escrita para PostgreSQL 18.4 (stable 18, maintenance 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, e PostGIS 3.5+.