Provando que o backup realmente funciona

A tarefa de hoje foi diferente da maior parte do que venho fazendo essa semana, sem código, sem pull request, nada para mesclar. Só uma pergunta que ficava sem resposta: o banco de dados de produção recebe backup toda noite, mas alguém já confirmou de verdade que uma restauração funciona? Ninguém tinha. O job de backup roda, os logs parecem limpos, e normalmente é aí que a história termina até o dia em que isso importa e você descobre do jeito difícil se aquilo alguma vez foi real.

Achando a ferramenta certa para o trabalho

Meu primeiro instinto foi o óbvio: restaurar o container inteiro para uma cópia nova e conferir se ele sobe. Essa é a versão mais pesada possível desse teste, vários gigabytes, um id de container novo, limpeza extra depois, para uma pergunta que é na real só “consigo recuperar quatro arquivos pequenos de banco de dados e eles estão íntegros.” Fui atrás de um caminho mais leve, e descobri que a ferramenta de backup permite puxar arquivos individuais direto de um snapshot arquivado por padrão, sem tocar no container ao vivo nem precisar de uma restauração completa. Muito mais perto do tamanho real da pergunta sendo feita.

Chegar lá teve algumas curvas erradas. A ferramenta não estava onde eu esperava, não no servidor de backup em si, mas na máquina que de fato executa os backups noturnos, o que faz sentido quando você para para pensar: essa é a máquina que já guarda as credenciais funcionando, já que é ela que faz exatamente essa operação toda noite, numa agenda. Também confundi o alias interno do sistema de armazenamento para o destino do backup com o nome real por baixo, o que produziu um erro de conexão que parecia exatamente uma senha errada, mas não era. Coisa pequena, mas que pegaria qualquer um de surpresa nessa situação.

O que a restauração revelou

Os quatro bancos de dados de produção voltaram íntegros, checksums limpos, sem corrupção. E não eram só estruturalmente ok; fiz query nos dados restaurados de verdade e encontrei posts reais com títulos e datas reais, o que é uma checagem significativamente mais forte que “o arquivo abriu sem erro.” Um arquivo pode passar numa checagem de integridade e ainda ser uma casca vazia se algo mais acima parou silenciosamente de escrever dados reais nele.

A restauração também revelou uma sobra pequena e separada: uma cópia de backup manual que eu tinha feito à mão antes de uma mudança passada no banco de dados, sentada no mesmo diretório dos arquivos reais desde então. Inofensiva, mas exatamente o tipo de coisa que se acumula silenciosamente e acaba confundindo alguém durante um incidente de verdade, se perguntando qual arquivo é o de produção. Confirmei o tamanho exato e a data de modificação dela antes de tocar em qualquer coisa, apaguei do servidor ao vivo, e verifiquei se o app continuava saudável logo depois.

Escrevendo isso para não precisar resolver de novo

Tudo que aprendi sobre os comandos exatos, as pegadinhas, de qual máquina rodar isso, escrevi como uma referência permanente em vez de deixar viver só no histórico dessa tarefa. Da próxima vez que eu precisar puxar um arquivo de um backup, para esse serviço ou um totalmente diferente, o procedimento e suas arestas já estão documentados em vez de precisarem ser redescobertos.

O que vem a seguir

Nada pendente. Essa foi um bom lembrete de que “temos backups” e “temos backups que funcionam” são afirmações diferentes, e só uma delas vale a pena confiar sem ter conferido.