Backup verde não garante restauração: o teste que a maioria dos times de PostgreSQL nunca fez

Um job de backup que termina sem erro prova muito menos do que parece. A única coisa que realmente comprova recuperação é restaurar, subir o cluster e validar os dados num ponto no passado.

Um job de backup que termina sem erro prova muito menos do que parece. A única coisa que realmente comprova recuperação é restaurar, subir o cluster e validar os dados num ponto no passado.

Já perdi a conta de quantos times eu encontrei com um dashboard de backup impecável e nenhuma ideia de quanto tempo levaria para voltar ao ar depois de um incidente real. Essa distância entre "o job rodou" e "eu consigo restaurar" é, na minha experiência como DBA, o ponto cego mais caro da operação de banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →. E é raro alguém medir isso antes do dia em que precisa.

A Stormatics, consultoria especializada em PostgreSQL, publicou um relato recente de Semab Tariq que descreve exatamente esse padrão com uma precisão incômoda. Concordo com praticamente todo o argumento, e por isso quero levá-lo adiante: não basta dizer que backup verde não é restauração, é preciso explicar por que até times maduros, com ferramentas de verificação automatizada, ainda caem nessa armadilha.

Um incidente que serve de retrato, não de exceção

O texto de Tariq monta uma linha do tempo que ele mesmo descreve como um padrão recorrente em clientes, não o caso de uma empresa específica. Vale reproduzir porque ela é didática.

• 09h38: uma feature nova derruba uma coluna que ainda guardava dados vivos.
• 09h44: tickets de suporte começam a chegar reportando registros incompletos.
• 10h05: depois de tentar correções pontuais, o time decide restaurar para o instante anterior ao incidente.
• 10h20: descobrem que não existe host de restore pronto. Ninguém nunca precisou de um.
• 13h50: o restore termina, mas a recuperação para antes do ponto esperado porque falta um segmento de WAL no arquivo.
• 16h30: desistem do ponto exato, recuperam uma cópia de seis dias atrás e passam dois dias reconstruindo a diferença na mão.

O negócio esperava uma hora de indisponibilidade e zero perda de dado. Levou mais de dois dias, com perda garantida. O backup, durante os catorze meses anteriores, esteve sempre verde.

O que um backup bem-sucedido realmente prova

Aqui está o núcleo do argumento, e é onde concordo sem reservas com Tariq: um job de backup verde é uma afirmação muito menor do que parece. Ele prova que um processo começou e terminou sem erro, que bytes foram lidos de um lugar e escritos em outro, que o catálogo de backup ganhou uma entrada nova.

Nenhuma dessas coisas prova que a restauração funciona. O job verde não diz se todos os arquivos fora do diretório de dados (roles, certificados, extensões, arquivos de configuração) estão de fato preservados, se o WAL necessário para levar aquele backup a um estado consistente ainda existe, se as páginas dentro do backup estão saudáveis, ou se você consegue parar num instante específico do passado. E não diz nada sobre se isso tudo cabe no tempo que você prometeu ao negócio.

A backup is only useful if you know you can actually restore it when you need it.

A backup is only useful if you know you can actually restore it when you need it.Semab Tariq, Stormatics

Essa frase deveria estar colada na tela de qualquer DBA. Não porque seja uma novidade teórica, mas porque é exatamente o tipo de coisa que todo mundo sabe e quase ninguém pratica.

A corrupção que o backup copia com perfeição

O exemplo que mais me marcou no texto é o da corrupção silenciosa. Um cluster criado anos atrás com data_checksums desligado migra entre gerações de storage. Um relatório que roda poucas vezes por ano começa a falhar, porque uma página de dados está danificada há meses, numa parte da tabela que o uso normal nunca toca.

Ao checar os backups, o problema fica claro: todos copiaram a página danificada com perfeição. O backup mais antigo ainda dentro da janela de retenção já contém a corrupção. Não sobra cópia limpa para onde voltar.

Isso muda completamente como eu leio uma política de retenção. Trinta dias de retenção soam como trinta dias de proteção, mas contra corrupção silenciosa é o oposto: são trinta dias para perceber o problema, depois dos quais a última cópia limpa já expirou e o dano está em todas as cópias que você guarda. É um argumento forte para ativar data_checksums desde a criação do cluster e para auditorias de integridade periódicas, não só backups periódicos.

O gap de arquivamento que ninguém monitora

O segundo cenário é ainda mais insidioso porque falha sem disparar nenhum alarme óbvio. O arquivamento de WAL para object storage está configurado e funcionando, até que uma credencial é rotacionada e o arquivamento começa a falhar.

Ele falha em silêncio: um WAL de arquivamento quebrado não derruba o banco nem o job de backup. O PostgreSQL simplesmente retém os segmentos e tenta de novo, e o primeiro sintoma visível costuma ser pressão de disco em pg_wal, cuja reação natural é liberar espaço, o que transforma um problema temporário em permanente. O alerta estava observando o job de backup; o arquivamento é outro mecanismo, com outro modo de falha, e ninguém estava de olho nele.

A recomendação prática de Tariq é monitorar três coisas separadamente: a contagem de falhas de arquivamento, a idade do segmento mais recente arquivado com sucesso e o tamanho de pg_wal. Eu assino embaixo: tratar arquivamento e backup como o mesmo item de checklist é o erro de configuração de observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → mais comum que vejo.

"Mas minhas ferramentas já verificam tudo": o contra-argumento que merece resposta

Aqui entra a objeção mais razoável, e é justo encará-la. Ferramentas modernas de backup para PostgreSQL costumam trazer camadas de verificação além do simples "o job terminou sem erro", e um time que opera com disciplina usando essas camadas pode argumentar que o restore test manual é redundante.

O contra-argumento é válido até certo ponto, mas não até o fim. Verificação de integridade dos arquivos de backup prova que os bytes gravados não corromperam em trânsito ou em repouso; não prova que o PITR para no segundo certo, que o cluster sobe com as roles e extensões certas, que a aplicação lê dados consistentes depois do replay, ou que a equipe tem onde restaurar dentro do RTO prometido. São camadas diferentes de garantia, e a automação resolve a primeira sem tocar nas outras três.

Em resumo: ferramenta de backup madura reduz o risco de corrupção no arquivo, mas não substitui a prova operacional de que alguém, com uma máquina limpa e um timestamp de referência, consegue trazer o banco de volta dentro do prazo acordado com o negócio.

O que eu cobraria de qualquer time antes de dormir tranquilo

Se eu estivesse auditando um ambiente PostgreSQL amanhã, a lista seria curta e eu insistiria nela antes de aceitar qualquer outro item de melhoria:

1. Confirmar que o monitoramento do arquivo de WAL é separado do monitoramento do job de backup.
2. Verificar se a janela de retenção cobre backup e WAL juntos, não apenas um dos dois.
3. Documentar tudo que não mora no diretório de dados (roles, certificados, chaves de criptografia do repositório) e onde isso está guardado.
4. Escolher um banco e restaurá-lo para um timestamp da semana passada, numa máquina limpa, com outra pessoa no teclado além de quem criou a rotina.

O objetivo não é se sentir confiante sobre o backup. É conseguir mostrar a alguém por que essa confiança existe, e saber a data em que ela foi comprovada pela última vez. Backup verde sem restore testado não é segurança: é uma suposição que ainda não foi cobrada.

Fonte: Planet PostgreSQL