O ensaio mostra duas coisas que o backup sozinho não mostra: se ele funciona e quanto tempo leva para voltar.
- Restaure numa máquina separada, nunca na de produção.
- Meça do início ao fim, até a aplicação responder.
- Repita todo mês e depois de qualquer mudança grande.
O backup roda toda noite e ninguém nunca restaurou um. No dia em que precisar, você vai descobrir se ele funciona e quanto tempo leva. O ensaio antecipa esse dia.
Defina o que é aceitável
Duas perguntas guiam o ensaio: quanto dado você aceita perder, o RPO, e em quanto tempo o sistema precisa voltar, o RTO. Backup diário com pg_dump atende quem aceita perder um dia. Para voltar a um minuto específico, é preciso backup físico com arquivamento de WAL, como fazem o pgBackRest e o Barman.
Faça o ensaio
Use uma máquina separada. Com o pgBackRest, a restauração até um horário escolhido fica assim:
pgbackrest --stanza=principal --type=time \
--target="2026-12-07 10:00:00" --target-action=promote restoreDepois de subir o banco, confira a contagem de linhas das tabelas principais e aponte uma cópia da aplicação para ele.
Anote o tempo
Cronometre cada etapa: baixar o backup, restaurar, reaplicar o WAL e validar. A soma é o seu RTO real. Se ficou acima do aceitável, os caminhos são guardar o backup mais perto, restaurar em paralelo ou manter uma réplica pronta.
Guarde onde não some
O backup precisa ficar fora da máquina do banco, de preferência em outro provedor, como explica a regra 3-2-1. Se você está montando o banco agora, o guia do primeiro dia do PostgreSQL já deixa o arquivamento ligado desde o início.
