Perguntada se tem backup, quase toda empresa responde que sim. É a resposta mais fácil de dar e a menos verificada de todas — o relatório automático chega verde toda manhã, e ninguém tenta abrir o arquivo que ele diz ter guardado.
O relatório de Tendências de Ransomware 2025, da Veeam, ouviu 1.300 empresas ao redor do mundo, das quais 900 haviam sido atacadas por ransomware — o sequestro de dados em que um programa embaralha os arquivos e cobram resgate para devolver — no ano anterior. Entre essas 900, apenas 10% conseguiram recuperar mais de 90% dos dados atingidos, e 57% recuperaram menos da metade. O backup existia. A recuperação, não.
Para quem aprova orçamento, esse número muda a pergunta. Não é mais "a empresa faz backup?" — isso quase toda empresa já responde que sim. É "alguém já tentou trazer os dados de volta, de verdade, antes do dia em que for obrigatório?". Enquanto a resposta for não, o que existe é uma suposição bem guardada, não uma garantia.
O relatório verde não prova nada
O CERT.br, o grupo brasileiro de resposta a incidentes de segurança, recomenda como base a regra 3-2-1: três cópias dos dados, guardadas em dois tipos de mídia diferentes, com pelo menos uma fora do local ou desconectada. É um bom ponto de partida — mas essa regra descreve onde guardar a cópia, não se alguém já tentou trazê-la de volta. As duas perguntas não são a mesma coisa.
Uma cópia de segurança pode terminar sem erro e, mesmo assim, não servir para nada na hora da restauração: arquivo corrompido, versão errada, parte do sistema que ficou de fora. O processo que roda à noite prova que os dados foram copiados. Não prova que alguém consegue trazê-los de volta.
Uma pesquisa global da Unitrends em 2025, com mais de 3 mil profissionais de TI ao redor do mundo, mediu exatamente essa distância entre achar e saber. Mais de 60% acreditavam que a empresa conseguiria voltar a operar em poucas horas depois de uma parada. Na prática, apenas 35% conseguiram fazer isso dentro desse prazo.
A mesma pesquisa encontrou o motivo mais óbvio para essa distância: 25% das empresas ouvidas testam a recuperação de desastre uma vez por ano ou menos. No resto do tempo, a confiança sobre o backup vem só do relatório automático — nunca de uma tentativa real de trazer os dados de volta.
O levantamento da Veeam mostrou o mesmo problema visto de outro ângulo. Das empresas atacadas, 98% tinham um plano escrito de resposta a ransomware, mas menos da metade desse plano trazia os elementos considerados essenciais: apenas 44% incluía um passo de verificação do backup antes de declarar a recuperação concluída. Ter o plano no papel e testar o que ele descreve são coisas diferentes.
A própria norma norte-americana de segurança de sistemas (NIST) trata esse teste como obrigação, não como boa prática opcional: pede que uma amostra dos dados de backup seja usada para restaurar partes do sistema dentro do plano de contingência, com o resultado conferido antes de qualquer emergência real. Não precisa ser tudo de uma vez. Precisa ser de verdade.
O que a maioria das empresas faz hoje
O jeito comum, na prática, é este: o backup roda à noite, o relatório chega de manhã, e ninguém mexe nisso de novo até o dia em que os arquivos somem. Quem cuida da TI — às vezes um funcionário de outra área, às vezes um prestador que só aparece quando chamado, às vezes a pessoa da equipe que "entende mais de computador" — trata "o backup está rodando" como se fosse sinônimo de "a empresa está protegida". Ninguém pergunta se essa mesma pessoa já tentou restaurar alguma vez, nem o que aconteceria se ela estivesse de férias no dia da parada.
O guia de resposta a ataques de ransomware do governo dos Estados Unidos é direto sobre por que essa confiança é arriscada: boa parte das variantes de ransomware procura e apaga ou embaralha qualquer cópia de segurança que esteja acessível pela rede. Se o backup fica ligado e visível o tempo todo, ele está na mira do mesmo ataque que devastou os arquivos originais.
O resultado é uma armadilha silenciosa. A empresa se sente coberta porque o e-mail chega verde, e só descobre que não está no único momento em que isso importa de verdade: no meio de uma parada, com gente esperando, cliente ligando e ninguém sabendo quanto tempo falta para o sistema voltar.
O que precisa existir na prática
Um backup à prova de dia ruim se define por mecanismos verificáveis, não pela cor do relatório.
Restauração completa simulada, feita à parte. Não é copiar um arquivo isolado para conferir se ele abre; é montar o sistema inteiro numa cópia separada da produção e ver se ele sobe e funciona como o original.
Verificação de que o que voltou funciona, não só que o processo terminou. Alguém confere se a planilha abre, se o banco de dados sobe, se o sistema reconhece os dados. "Terminou sem erro" e "funciona de verdade" são coisas diferentes, e só a segunda conta.
Tempo de restauração cronometrado, não estimado. Medir quanto tempo o processo levou de verdade nesse teste, e comparar com quanto tempo até a empresa voltar a operar que o plano promete. Sem essa medição, o plano é uma opinião sobre o futuro, não um número testado.
Um cenário em que a cópia mais recente está comprometida. O teste também precisa prever que o ataque chegou até o backup mais novo, e que a restauração parte de uma cópia anterior, guardada fora do alcance de quem invadiu.
Registro de cada teste, com data e o que não funcionou. Sem isso, cada tentativa começa do zero, e a lembrança de "já testamos uma vez" vale cada vez menos conforme os meses passam.
É assim que a Skills IT trabalha: com simulações de recuperação periódicas, feitas à parte do ambiente de produção, e com o registro de cada teste e do que precisou ajustar depois dele.
O que a empresa ganha com isso
O ganho mais direto aparece no pior momento possível de sentir falta dele: quando o sistema cai de verdade, a equipe já sabe os passos e já tem uma ideia real de quanto tempo o retorno costuma levar, em vez de descobrir tudo isso sob pressão, com o cliente no telefone.
Há um ganho financeiro que anda junto. Uma empresa que já testou sua restauração consegue estimar, com alguma precisão, quanto custa cada hora parada — e decidir, com essa informação, se vale investir em recuperação mais rápida para um sistema específico ou se o prazo atual já é aceitável. Quem nunca testou decide no escuro, geralmente comprando mais um produto depois do susto. Multiplique isso por hora parada, pedido não faturado e funcionário parado esperando o sistema voltar, e o cálculo fica claro: o custo de testar é previsível e pequeno; o custo de não testar só aparece na pior hora, e vem sem aviso.
E há o efeito sobre quem decide. O dono ou diretor que recebe um teste de restauração documentado — o que funcionou, o que não funcionou, quanto tempo levou — tem algo concreto para conversar com o setor financeiro e com clientes que perguntam sobre continuidade. Quem só tem o relatório verde do backup tem uma frase de efeito, não uma resposta.
Um roteiro para começar
Antes da próxima reunião sobre continuidade, estas quatro perguntas colocam o assunto no lugar certo:
- Peça para ver uma restauração acontecer, não só o relatório. Marque uma demonstração real: trazer de volta um arquivo ou sistema não crítico, do zero, na frente de quem aprova orçamento.
- Pergunte quando foi a última vez que alguém testou. Se a resposta for "nunca" ou "não lembro", essa já é a resposta que a empresa precisa ouvir.
- Descubra se o teste prevê um cenário de ataque, não só uma pane. Um equipamento que queima é diferente de um invasor que apagou a cópia mais recente antes de sair.
- Coloque a próxima simulação no calendário, com data marcada. Um teste sem data vira promessa; uma data marcada vira rotina.
