Rodar um drill de restauração PITR do PostgreSQL toda semana (este é o nosso runbook)

Um backup que nunca foi restaurado é uma esperança, não um backup. Toda base Postgres gerenciada que operamos passa por um drill semanal de point-in-time recovery (PITR), automatizado de ponta a ponta, com o resultado publicado no seu relatório de saúde mensal.

O que o drill faz de fato

1. Escolher um timestamp aleatório dentro dos últimos 7 dias de retenção WAL.
2. Provisionar uma instância sandbox em uma classe de instância mais barata que a produção.
3. Restaurar o último base backup no sandbox.
4. Reproduzir WAL até o timestamp escolhido.
5. Rodar uma sonda de integridade — diff de schema contra produção, delta de row-count dentro da tolerância, um punhado de checks SQL de integridade.
6. Derrubar o sandbox. ~5 minutos de compute cobrados. Reportar sucesso ou falha.

O que ele pega

As quatro coisas que esse drill pega e que alertas «o backup rodou» não pegam:

• Backups que silenciosamente migraram de WAL+base para «só snapshots» porque alguém mudou a política de retenção
• Gaps de WAL causados por falhas de archive_command que ninguém notou porque o banco seguia rodando
• Drift de permissões que deixa os backups acontecerem mas bloqueia a role de restore de lê-los
• Rotação de chaves de criptografia que tornou snapshots mais antigos inutilizáveis

O que não automatizamos

Não automatizamos a declaração de desastre. O runbook exige explicitamente que um humano decida vamos fazer uma restauração real, não o drill. Esse guardrail já nos salvou mais de uma vez de «automação enlouquece e restaura produção para ontem».

O runbook completo no Medium contém o Terraform que usamos para subir o sandbox, o Bash que compara schemas, e as regras de alerta que escalam quando o drill falha duas vezes seguidas.