Backup que nunca foi restaurado não é backup

Quase toda empresa tem backup. Poucas sabem se ele funciona.

A diferença entre as duas coisas só aparece no pior dia possível: o servidor não sobe, alguém abre o painel de backup, vê a rotina marcada em verde há meses e descobre, na hora de restaurar, que o arquivo está truncado, que a base saiu inconsistente porque foi copiada com o banco no ar, ou que ninguém tem a senha da chave de criptografia.

O painel verde não prova que o dado volta. Ele prova que um processo terminou sem erro — o que é bem menos do que parece.

Um teste de restauração de verdade responde a perguntas que a rotina não responde:

• O arquivo abre? Um backup corrompido termina em verde do mesmo jeito.
• O sistema sobe com aquele dado, ou faltam pedaços que ninguém sabia que precisavam entrar na cópia?
• Quanto tempo leva? Backup que restaura em dezoito horas não serve para um sistema que não pode ficar fora por duas.
• Quem consegue fazer? Se só uma pessoa sabe, o plano falha quando ela estiver de férias.
• As credenciais e chaves necessárias estão acessíveis fora do ambiente que caiu?

Esse último ponto derruba mais plano do que falha técnica. É comum a chave de criptografia do backup viver no mesmo servidor que o backup protege, ou a senha estar num gerenciador que só autentica pela rede interna que acabou de sair do ar.

Não existe frequência universal para o teste. O que existe é uma pergunta que a define: quanto a empresa aguenta perder? Um sistema que registra venda o dia inteiro precisa de verificação mais frequente do que um catálogo que muda uma vez por mês. A resposta vem do impacto, não do calendário.

Também vale separar dois números que costumam ser confundidos. Um é quanto tempo o sistema pode ficar fora; o outro é quanto de dado a empresa aceita perder. Eles pedem soluções diferentes: o primeiro se resolve com velocidade de restauração e ambiente pronto para receber; o segundo, com frequência de cópia. Comprar mais espaço de armazenamento não melhora o primeiro.

Um roteiro mínimo que já muda o cenário:

• Restaurar em um ambiente separado, nunca por cima do que está em produção.
• Subir a aplicação apontando para o dado restaurado e usá-la de verdade.
• Cronometrar o processo inteiro, do pedido ao sistema utilizável.
• Anotar o que faltou, corrigir a rotina e repetir.
• Registrar quem fez, quando e o que deu errado — inclusive quando deu certo.

O teste que ninguém documenta acaba sendo refeito do zero pela próxima pessoa, sob pressão, no dia em que menos se pode errar.

Backup é uma promessa que a empresa faz para si mesma. Testar é a única forma de saber se ela pode cumpri-la.