Backup de PostgreSQL só vale se a restauração for testada
Como montar uma rotina de backup do PostgreSQL com retenção, cópia externa e teste de restauração, e por que o teste é a parte mais importante.
Ter um arquivo de backup não é ter backup. Backup é aquele que você já restaurou com sucesso. Muita gente descobre que a cópia estava incompleta justamente no dia em que precisa dela.
O básico: dump agendado
O caminho mais simples para bancos pequenos e médios é o pg_dump em formato custom, agendado por cron ou por um container dedicado:
pg_dump -Fc -h postgres -U app dbname > backup-2026-01-01.dump
O formato custom (-Fc) é compactado e permite restaurar tabelas específicas com pg_restore.
Quatro regras da rotina
- Retenção definida. Mantenha, por exemplo, os últimos 7 backups diários e 4 semanais. Sem rotação, o disco enche e o próprio backup passa a falhar.
- Cópia fora do servidor. Backup guardado no mesmo disco do banco não protege contra falha do disco nem contra o servidor perdido. Envie para outro destino.
- Proteção do arquivo. O dump contém dados sensíveis. Criptografe antes de enviar para fora e restrinja a permissão do diretório local.
- Alerta de falha. Um backup que parou de rodar há duas semanas é o cenário mais comum. Registre cada execução e avise quando falhar.
O teste de restauração
Periodicamente, restaure o backup mais recente em um banco de teste e confira o básico: o restore terminou sem erro e as contagens de linhas das tabelas principais fazem sentido. Se possível, automatize essa verificação.
Segredos
A senha do banco não deve aparecer em linha de comando nem em log. Use variáveis de ambiente ou o arquivo .pgpass, e mantenha esses arquivos fora do repositório.
Em resumo
Dump agendado, retenção, cópia externa, criptografia e restauração testada. Sem o último item, o resto é só esperança.
Precisa de backup e deploy confiáveis para uma aplicação? Converse com a gente.