Backup que ninguém testou não é backup

O job roda às 2h. O arquivo aparece no bucket com o tamanho esperado. O painel mostra verde. Todo mundo dorme tranquilo.

E então chega o dia em que é preciso restaurar, e aparecem as perguntas que nunca foram feitas: o dump abre? Ele tem todos os bancos ou só o principal? Quanto tempo leva para voltar? Quem sabe fazer isso? A senha do banco novo está onde?

Backup não testado não é backup — é uma suposição sobre backup. A diferença entre os dois só aparece no pior dia possível, e é exatamente aí que ela custa mais caro.

Duas perguntas antes de qualquer ferramenta

Toda decisão sobre backup decorre de dois números, e vale defini-los com quem responde pelo negócio, não sozinho na equipe técnica.

RPO — quanto dado você aceita perder. Se o backup é diário às 2h e o desastre acontece às 23h, você perde 21 horas de transação. Isso é aceitável? Para um blog, provavelmente. Para um sistema de pedidos, quase nunca.

RTO — quanto tempo você aceita ficar fora. Não é o tempo de copiar o arquivo: é o tempo total até o serviço estar de pé, incluindo provisionar máquina, instalar dependência, restaurar, conferir e apontar o DNS.

O erro comum é escolher a ferramenta antes de definir os números, e descobrir depois que a estratégia adotada nunca poderia atender ao que o negócio esperava.

Snapshot e backup não são a mesma coisa

Confundir os dois é a falha conceitual mais frequente, e leva a descobrir o problema tarde demais.

Snapshot é uma foto do disco inteiro num instante. Ótimo para voltar de uma mudança que deu errado: em minutos a máquina está exatamente como antes. Ruim como proteção de longo prazo, porque vive no mesmo ambiente da máquina e captura o sistema no estado em que estava — inclusive um banco no meio de uma escrita.

Backup é uma cópia lógica, extraída de forma consistente e guardada em outro lugar. Mais lento para restaurar, e é o que sobrevive quando o problema não é a máquina.

Os dois resolvem cenários diferentes, e o comparativo de backup ou snapshot detalha quando usar cada um. A regra curta: snapshot antes de mexer, backup para o resto.

Vale acrescentar que snapshot de banco em atividade só é confiável se o sistema de arquivos garantir consistência ou se o banco for congelado durante a captura. Sem isso, você tem uma cópia que parece boa e falha ao subir — o pior tipo de falso positivo.

O que valida um dump de verdade

Verificar que o arquivo existe e tem tamanho razoável não é validação. São três níveis, e só o terceiro conta:

Nível 1 — o arquivo é íntegro. Barato, e pega o dump truncado por disco cheio:

gzip -t backup.sql.gz && echo "compressão OK"
pg_restore --list backup.dump > /dev/null && echo "estrutura OK"

Nível 2 — o dump restaura. Confirma que o conteúdo é utilizável:

createdb teste_restore
pg_restore -d teste_restore --no-owner backup.dump
psql -d teste_restore -c '\dt' | head
dropdb teste_restore

Nível 3 — a aplicação sobe em cima dele. É o único que responde à pergunta real. Restaure em uma VM temporária, suba a aplicação apontando para lá, e faça login. Muita falha só aparece aqui: extensão faltando, sequência fora de sincronia, tabela que ficou de fora do filtro do dump.

Automatize o nível 2 e faça o nível 3 uma vez por trimestre, com o cronômetro ligado.

O ensaio que revela o que falta

Marque uma data e execute a restauração completa como se fosse real, com uma regra: usar apenas o que está documentado, sem consultar quem construiu o sistema.

O que esse exercício costuma revelar:

• O tempo é muito maior que o imaginado. Restauração que "leva vinte minutos" vira três horas quando se conta provisionar, instalar dependência e conferir.
• Falta alguma coisa no backup. Arquivo enviado por usuário, certificado, .env, configuração do nginx, regra de cron. O banco quase sempre está lá; o resto, nem sempre.
• A documentação está desatualizada. Referencia caminho que mudou, versão que não existe mais.
• Só uma pessoa sabe fazer. E ela pode estar de férias no dia.
• A credencial do backup está no servidor que caiu. Este é o mais irônico e mais comum.

Anote tudo, corrija, e repita no trimestre seguinte. O ensaio vale exatamente pelo que ele encontra de errado.

A regra 3-2-1 e o que ela protege

A recomendação clássica: 3 cópias, em 2 mídias diferentes, com 1 fora do ambiente principal.

O que ela protege não é a falha de disco — é o cenário em que o problema alcança o ambiente inteiro: conta comprometida, exclusão acidental em massa, ou o ataque que criptografa tudo o que estiver ao alcance da credencial.

Por isso a cópia externa precisa de duas propriedades:

• Credencial separada. Se a mesma chave que a aplicação usa também apaga o backup, a separação é ilusória.
• Retenção que impeça exclusão. Backup que pode ser apagado por quem comprometeu o servidor não é cópia externa, é cópia adicional.

Na prática, isso significa uma chave de acesso ao bucket com permissão de escrita e sem permissão de exclusão, e a limpeza de arquivos antigos por política do bucket em vez de por comando do servidor.

Retenção: guardar tudo é caro e pouco útil

A tentação é guardar tudo para sempre. O custo cresce em linha reta e a utilidade cai rápido — um backup de catorze meses atrás quase nunca é o que se quer restaurar.

O esquema escalonado resolve os dois lados, mantendo granularidade fina onde ela importa:

São 23 cópias em vez de 365, cobrindo desde "desfazer o que estragou hoje" até "recuperar como estava em março".

O ponto que justifica manter cópias antigas não é falha de hardware — é o problema que ninguém percebeu na hora. Um erro em migração de dados, uma exclusão feita por integração mal configurada, uma corrupção silenciosa: tudo isso costuma ser descoberto semanas depois, quando o backup de ontem já contém o defeito.

Duas consequências práticas. A primeira é que a retenção precisa ser maior que o seu tempo típico de descoberta de problema. A segunda é que backup do banco não substitui histórico dentro da aplicação: registro de auditoria e exclusão lógica resolvem o caso comum sem exigir restauração nenhuma.

Se o volume começar a pesar, o caminho é mover as cópias antigas para armazenamento de objeto e deixar no disco só as recentes — e não encurtar a retenção, que é a economia que mais dói quando faz falta.

Como isso fica na rotina

O arranjo que atende à maioria das operações, sem virar projeto:

• Snapshot antes de toda mudança arriscada — atualização, alteração de configuração, migração. É o que salva o dia comum.
• Backup automático diário do servidor, com retenção configurada.
• Dump lógico do banco, com frequência definida pelo seu RPO, enviado ao bucket com o script pronto — que já sai com set -euo pipefail, retenção e a validação que evita subir um arquivo truncado.
• Verificação automática de integridade após cada dump, com alerta em caso de falha.
• Ensaio de restauração trimestral, com o tempo cronometrado e anotado.

E um detalhe operacional que passa despercebido: o alerta precisa disparar quando o backup não rodar. Job que falha em silêncio produz uma pasta que para de crescer sem que ninguém note — e a descoberta acontece semanas depois, na hora da restauração. Se o agendamento for por cron, vale conferir por que tarefas de cron não rodam: backup silencioso é o exemplo perfeito de tarefa que ninguém percebe ter parado.

A pergunta que fecha o assunto não é "temos backup?". É "quando foi a última vez que restauramos, e quanto tempo levou?". Se a resposta for "nunca", você tem arquivos — não tem backup, tem a expectativa de ter um.

Marque o primeiro ensaio para as próximas duas semanas, com hora reservada na agenda de quem vai executar. Não é o tipo de tarefa que encontra espaço sozinha entre demandas urgentes, e o dia em que ela vira urgente é justamente o dia em que não dá mais para ensaiar.