Melhores Práticas de PITR

Alinhe a retenção de WAL com as janelas legais/de conformidade. Estas regras mantêm a recuperação point-in-time confiável quando alguém exclui a tabela errada.

Como Usar Esta Lista

• Aplique ao habilitar archive_mode ou ao escolher a retenção de backup na nuvem.
• Revise antes de migrações importantes (crie um checklist de ponto de restauração).
• Combine com o Manual de Execução de Teste de PITR trimestral.
• Compartilhe a seção de retenção com os stakeholders legais/de conformidade.

A - Arquivamento

• Habilite archive_mode no primário desde o primeiro dia. Não após o primeiro incidente.
• Monitore pg_stat_archiver.failed_count com um limite de alerta de 1. Qualquer falha amplia o RPO.
• archive_command idempotente (test ! -f ou pgBackRest). Retentativas devem ter sucesso.
• Replique o arquivo WAL para uma segunda região/conta. A perda de região não deve quebrar a cadeia.
• Defina archive_timeout apropriado para bancos de dados de baixo tráfego. Evite RPO obsoleto em sistemas ociosos.

B - Retenção e Conformidade

• Retenção de WAL >= mínimo de retenção legal + buffer operacional. 90 dias legais significam arquivar pelo menos 90 dias mais uma margem.
• Documente o RPO como o último arquivo bem-sucedido, não como um rótulo da janela de backup. Comunicação honesta com os stakeholders.
• Estenda a retenção para retenção de litígio sem excluir chaves. Armazenamento imutável ou bloqueio de objeto.
• Cruze a retenção do console da nuvem com a planilha de conformidade. O padrão de 7 dias do RDS não é suficiente para muitos regimes.
• Nivele a retenção por classificação do banco de dados. Cluster PII por mais tempo que análises internas.

C - Pontos e Alvos de Restauração

• pg_create_restore_point antes de DDL de alto risco. Obrigatório em tickets de alteração.
• Use fuso horário explícito em recovery_target_time. UTC com offset nos manuais.
• Prefira recovery_target_action = pause para a primeira tentativa. Valide antes de promover.
• Nunca faça PITR in-place sobre o data_dir de produção. Restaure em um ambiente separado; troque após a prova.
• Registre qual tipo de alvo foi usado no ticket de incidente. Auxilia na análise postmortem e auditoria.

D - Testes e Verificação

• Teste de PITR trimestral em um host PostgreSQL 18.4 separado. Registre PITR_RTO_SECONDS.
• Valide contagens de linhas e checksums de negócios após o teste. Não apenas pg_is_in_recovery() = false.
• Teste falho = trate os backups como não confiáveis até que sejam corrigidos. Risco de dados Sev-2.
• Inclua o caminho de restauração do pgBackRest ou da nuvem nos testes. Não teste apenas arquivos cp do shell.
• Teste de fumaça da aplicação na instância restaurada antes de declarar sucesso. DB em funcionamento != aplicação completa.

E - Integração de Ferramentas

• Patroni: documente o bootstrap a partir do backup para PITR de cluster novo. Não failover in-place.
• pgBackRest: verifique stanza e archive-push no mesmo monitoramento de job. Cadeia unificada.
• Criptografe arquivos em repouso (S3 SSE-KMS, gpg). WAL contém todos os dados.
• Restrinja o IAM de restauração a funções de "break-glass". Evite sobrescrita acidental de produção.
• Mapeie as etapas da UI de PITR da nuvem para equivalentes de manuais DIY. Equipes híbridas permanecem alinhadas.

FAQs

Relacionados

• Noções Básicas de PITR - arquitetura
• archive_mode & archive_command - envio
• Opções de Alvo de Recuperação - condições de parada
• Melhores Práticas de Backup - backups complementares

Versões de 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+.