Temos backup — Falsas Certezas da TI

De todas as falsas certezas, essa é a que eu mais vi custar caro. Não porque as empresas não façam backup, mas porque fazem e acreditam que está resolvido. O backup roda toda noite, o relatório chega com um “sucesso” verde, e ninguém mais pensa no assunto até o dia em que precisa.

Nesse dia, descobre-se o que o backup realmente era.

O que o relatório de “sucesso” não diz

O relatório diz que o processo de cópia terminou sem erro. Não diz se o banco de dados do ERP estava incluído. Não diz se a cópia está num lugar que o ransomware não alcança. Não diz quanto tempo leva para trazer tudo de volta, nem se alguém sabe fazer isso sob pressão. E não diz se a última cópia íntegra é de ontem ou de três meses atrás, porque o job que falha em silêncio também reporta sucesso em outro lugar.

Backup é a parte fácil. Restauração é a parte que importa, e é a que ninguém testa.

O teste do gerador

O gerador é testado com carga: alguém desliga a energia de propósito e observa se o prédio continua funcionando. É desconfortável, dá trabalho, e por isso mesmo é obrigatório. Com backup, o equivalente é restaurar de propósito: pegar um servidor, trazer de volta num ambiente separado e cronometrar. Quem faz isso descobre problemas num dia tranquilo. Quem não faz, descobre numa segunda-feira com a empresa parada.

O que costuma aparecer no primeiro teste

Em quase todo primeiro teste de restauração que eu acompanhei, algo apareceu. Um volume que não estava incluído. Uma senha de criptografia que só uma pessoa sabia, e essa pessoa saiu da empresa. Um tempo de restauração de 18 horas para um sistema que o negócio não aguenta parado por 4. Nenhum desses problemas aparece no relatório verde. Todos aparecem no teste.

A evidência que você deveria exigir

Uma única pergunta resolve: quando foi a última restauração de propósito, e quanto tempo levou? Se vier com data, sistema e tempo, você tem backup. Se vier com “o sistema reporta sucesso toda noite”, você tem um processo de cópia e uma esperança. São coisas diferentes, e a diferença só aparece no pior dia.

O que pedir na próxima reunião

Quatro evidências. Não é desconfiança: é o mesmo critério que você já aplica ao gerador de energia.

Registro da última restauração de teste: o que foi restaurado, em quanto tempo e por quem

O que está e o que não está no backup, por sistema (servidor de arquivos, e-mail, ERP, banco de dados, máquinas dos diretores)

Onde a cópia fica e se ela sobrevive ao mesmo incidente que o original (ransomware, incêndio, roubo)

Alerta de falha de backup: quem recebe, em quanto tempo, e quantas falhas houve no último mês

Perguntas frequentes

Qual a diferença entre ter backup e ter restauração?

Backup é o processo de copiar. Restauração é o processo de trazer de volta e colocar para funcionar. Só o segundo protege a empresa, e só ele revela se a cópia estava íntegra, completa e num lugar acessível. Empresas que nunca restauraram não sabem se têm backup; sabem que têm um processo de cópia rodando.

Com que frequência o backup deve ser testado?

Restauração parcial (um arquivo, uma pasta) mensalmente; restauração completa de um sistema crítico ao menos uma vez por semestre, com o tempo medido. O número exato importa menos do que a existência do registro com data.

O backup na nuvem resolve o problema?

Resolve o problema de onde a cópia fica, não o de saber se ela volta. Backup em nuvem também falha silenciosamente, também pode excluir o que importa e também precisa de teste de restauração. A vantagem real é a separação física do original, o que protege contra ransomware e desastre local, desde que a cópia não esteja acessível pela mesma credencial.

Temos backup: o que essa certeza esconde e a evidência que você deveria exigir