Seu backup nunca foi testado. Você só vai descobrir no pior dia

O telefone tocou às sete e quarenta de um sábado. Do outro lado, um diretor de operações que eu tinha conhecido três semanas antes, falando rápido, com aquela calma que a pessoa impõe em si mesma quando está perto de perder o controle. O servidor do ERP tinha parado na madrugada e o time já tinha tentado subir o serviço duas vezes, sem sucesso. Aí veio a pergunta que aparece sempre, em qualquer empresa: "mas a gente tem backup, né?"

Tinha. Rodava todos os dias às 22h, sem falhar, e o e-mail de confirmação chegava na caixa de três pessoas. O que ninguém tinha feito, em quatro anos de operação, era tentar voltar. Naquela manhã descobrimos que o arquivo estava lá, com o tamanho certo, na pasta certa, e que ele não abria.

a ilusão do backup verde

Existe uma diferença grande entre ter backup configurado e ter backup que volta. Quase toda empresa que eu visito tem o primeiro. Muito poucas conseguem provar que têm o segundo.

O que confunde é o sinal verde. O job roda, o relatório chega dizendo sucesso, o gestor vê a linha verde e risca aquilo da cabeça. Só que o job confirma bem menos do que parece: ele avisa que o processo terminou de escrever um arquivo, e para por aí. Nada foi lido de volta, nenhum conteúdo foi validado, ninguém abriu aquele arquivo para ver se ele reconstrói o sistema que a empresa usa para faturar.

as formas silenciosas de falhar

Backup raramente falha com barulho. Quando falha com barulho, alguém percebe e conserta na segunda-feira. O que dói é o outro tipo, o que fica invisível por meses.

O caso mais comum que eu encontro é o banco novo que ninguém incluiu na rotina. A empresa sobe um sistema em março, o fornecedor instala o banco, e a rotina continua fazendo exatamente o que fazia em fevereiro. Ela roda, informa sucesso e ignora o sistema novo por completo, algo que aparece justamente no dia em que ele quebra.

Tem também o destino que encheu. O backup passa a gravar parcialmente, ou a sobrescrever o que já existia, e o alerta de disco cheio some no meio de duzentos alertas que ninguém lê mais. Tem o banco configurado num modo que só permite voltar até a foto da madrugada, sem chance de recuperar o que foi digitado durante o dia, algo que o gestor descobre ao pedir para voltar até as 15h e ouvir que não dá. Tem a mídia que corrompeu em silêncio, porque leitura de verificação custa tempo de janela e alguém desligou isso há anos. E tem a situação mais constrangedora: o backup está íntegro, criptografado como manda a boa prática, e a chave estava com o analista que saiu da empresa em 2023.

as duas perguntas que quase nenhum gestor sabe responder

Antes de discutir tecnologia, existem dois números que definem tudo. Eles têm nomes técnicos, RPO e RTO, e você pode esquecer as siglas assim que terminar este parágrafo. O que importa é o que elas perguntam.

A primeira: quanto trabalho a sua empresa aceita perder? Se o banco parar agora e a última cópia boa for da meia-noite, some tudo que foi digitado desde então. Pedidos, notas emitidas, lançamentos financeiros, atendimentos registrados. Alguém vai ter que redigitar aquilo a partir de papel, print ou memória, ou aquilo deixa de existir.

A segunda: quanto tempo a empresa aguenta ficar parada? Aqui vale medir o tempo total até a operação voltar a faturar, incluindo diagnóstico, decisão, restauração, validação e liberação para os usuários. O tempo que o técnico leva para copiar o arquivo é só um pedaço disso.

Você sabe esses dois números da sua empresa? Na maioria das conversas que eu tenho com diretores, a resposta honesta é que ninguém nunca definiu isso. E quando ninguém define, quem define é o acaso, no dia do incidente.

seis meses que viraram uma semana

Já entrei numa empresa que descobriu isso do pior jeito possível. Operação de médio porte, direção convicta de que tinha seis meses de retenção de backup, algo que estava no contrato com o fornecedor e na apresentação de compliance. Em julho, o time fiscal identificou que uma integração vinha gravando valores errados numa tabela de contratos desde fevereiro. Nada catastrófico no dia a dia, mas o suficiente para comprometer cinco meses de apuração.

A solução parecia óbvia: voltar uma cópia de janeiro num ambiente à parte, comparar e corrigir. Aí veio a descoberta de que a política efetivamente aplicada guardava sete dias. Os seis meses existiam no contrato e no PowerPoint, nunca na configuração, e todas as cópias disponíveis já continham o erro.

O que veio depois foi um trabalho manual de dois meses e meio, com a controladoria reconstruindo lançamento por lançamento a partir de documentos externos, a um custo muito maior do que qualquer projeto de backup teria custado. Junto disso ficou o desconforto de perceber que a empresa operou cinco meses acreditando numa proteção que não existia.

o teste que resolve

O único jeito de saber se um backup volta é fazer ele voltar, e isso significa pegar a cópia de um dia qualquer, restaurar num ambiente separado da produção, subir o sistema em cima dela e conferir se o dado voltou íntegro, com alguém olhando a tela e confirmando que o pedido número tal existe, que o saldo bate e que o relatório fecha. Verificação automática de integridade ajuda, mas ela nunca vai te contar quanto tempo a recuperação leva nem se o sistema sobe em cima daquele dado.

Para os bancos que sustentam faturamento, um teste por trimestre resolve bem, com uma simulação mais completa por ano. Sempre que entrar um sistema novo, mudar o servidor ou mexer na rotina, testa de novo. O resultado precisa ficar registrado com data, com quem executou e com o tempo que levou. Esse tempo é a única medida real do seu prazo de recuperação, e todo o resto é estimativa de corredor.

Quase ninguém faz, porque parece caro (exige um ambiente para restaurar), parece trabalhoso (ocupa gente boa por um ou dois dias) e o risco é invisível. Enquanto o incidente não acontece, a empresa que testa e a que não testa parecem exatamente iguais.

o que levar para a próxima reunião

Você não precisa entender de banco de dados para descobrir se a sua empresa está exposta. Basta fazer estas perguntas e prestar atenção na qualidade da resposta, principalmente no tempo que a pessoa leva para responder.

Quando foi o último teste de restauração, em que sistema, e quem assinou o resultado?

Quantas horas de trabalho perderíamos se o banco principal caísse agora, neste minuto?

Quanto tempo levaria até o sistema voltar a operar, de ponta a ponta, e como sabemos disso?

Todos os bancos em produção estão na rotina, incluindo os que entraram nos últimos doze meses?

Onde ficam as senhas e chaves necessárias para restaurar, e quem tem acesso a elas?

Se a pessoa que configurou tudo isso sair amanhã, alguém consegue recuperar sem ela?

Respostas firmes, com data e nome, colocam você acima da média do mercado brasileiro. Respostas em forma de "acho que sim" ou "o backup roda todo dia" indicam um problema que ainda está barato de resolver.

Eu montei um Health Check gratuito para responder esse tipo de pergunta com evidência, olhando o ambiente real em vez de confiar na memória de quem configurou. Ele cobre backup, retenção, integridade e outros pontos que costumam aparecer junto. Se quiser saber onde a sua operação está: mrdba.com.br/health-check

E se você não quiser falar comigo, tudo bem. Marque a reunião com o seu time mesmo assim, com essas perguntas na mão. A conversa é desconfortável hoje e é bem pior às sete e quarenta de um sábado.