Segundo o relatório O Estado do Ransomware no Brasil 2026, da Sophos, divulgado em julho de 2026 com 71 empresas brasileiras atingidas por sequestro de dados, 58% delas voltaram a operar em até uma semana. Outras 18% levaram entre um mês e seis meses. A cópia de segurança existia nos dois grupos — 85% usaram backup para recuperar os arquivos embaralhados. O que separou quem voltou rápido de quem ficou meses parado não foi ter backup. Foi quanto tempo levou para trazer esse backup de volta.
Isso não é só sobre ataque. Um disco que morre, um servidor que não liga mais, um erro de alguém apagando a pasta errada — qualquer um desses motivos põe a empresa na mesma fila: buscar a cópia, trazer o volume de dados de volta, reinstalar o que for preciso, conferir se está tudo certo antes de liberar o uso. O incidente muda; a conta de tempo é a mesma.
Para quem decide, essa conta geralmente só aparece na hora errada. A empresa sabe que tem backup e assume que "voltar" é questão de minutos — como abrir um arquivo. Ninguém mediu quanto tempo leva de verdade até alguém precisar medir sob pressão, com a operação parada e um prejuízo crescendo a cada hora.
Quanto tempo leva de verdade
No relatório global da Sophos, o tempo médio para uma empresa se recuperar totalmente de um ataque de sequestro de dados ficou em três semanas — o mesmo patamar do ano anterior, mas abaixo das cinco semanas registradas em 2024. Olhando a distribuição: 55% das empresas voltaram a operar em até uma semana (16% em menos de um dia), 83% em até um mês, e só 3% levaram mais de três meses.
A média de três semanas esconde uma variação grande, e ela não é sorte: depende do volume de dados que precisa voltar e da velocidade com que ele consegue trafegar. Trazer alguns gigabytes de volta por uma conexão comum é questão de minutos. Trazer alguns terabytes pela mesma conexão — a que a empresa usa todo dia para e-mail e navegação, não uma linha dedicada a mover volume grande — pode levar horas só no download, antes de qualquer sistema voltar a funcionar.
Onde a cópia está guardada também entra nessa conta. Uma cópia dentro do prédio costuma voltar mais rápido, porque não depende do link com a internet. Uma cópia na nuvem é mais segura contra um incêndio ou um roubo no local, mas trazer um volume grande dela de volta depende inteiramente da velocidade de descida daquela conexão — e a maioria dos links empresariais foi contratada pensando em uso do dia a dia, não em puxar terabytes de uma vez.
Depois que o dado chega, o relógio não para. Ainda falta reinstalar o sistema quando o equipamento também precisou ser trocado, reconfigurar a integração com cada software que a empresa usa, reativar licença, e conferir se cada informação voltou íntegra antes de liberar para o time trabalhar. Em quais sistemas isso acontece primeiro é outra decisão — importante, mas é assunto para outro dia; aqui o que conta é que cada uma dessas etapas consome tempo real, medido em horas, não em minutos.
O custo médio para uma empresa brasileira se recuperar de um ataque de sequestro de dados, sem contar eventual resgate pago, foi de US$ 1,05 milhão em 2026, segundo a mesma pesquisa da Sophos — período de equipe parada, equipamento, rede e oportunidade perdida somados. Quanto mais longo o prazo de restauração, maior essa conta fica.
Por que o jeito comum não resolve
O jeito comum é configurar o backup, ver que ele roda todas as noites sem erro, e parar por aí. A cópia existe, está íntegra, o relatório da noite anterior mostra sucesso — e a empresa conclui, sem nunca ter testado, que "restaurar" é questão de apertar um botão.
Só que ninguém cronometrou quanto tempo leva trazer um volume real de dados de volta pela conexão real que a empresa tem. O número que a diretoria imagina — "algumas horas", "no máximo um dia" — nunca foi medido; foi estimado por otimismo. Descobrir que o prazo real é de dias, não de horas, no meio de uma operação parada, é a pior hora possível para essa surpresa.
Outra versão do mesmo problema é guardar a cópia só onde é mais barato armazenar, sem perguntar quanto tempo levaria para trazê-la de volta dali. Armazenamento e velocidade de restauração são coisas diferentes: um lugar pode ser ótimo para guardar e péssimo para devolver rápido um volume grande.
O que precisa existir na prática
Um ambiente preparado para essa hora trata o tempo de restauração como um número medido, não como uma suposição.
Uma simulação de restauração cronometrada, não só uma cópia que "roda sem erro". É a única forma de saber quantas horas — ou dias — o volume real de dados da empresa leva para voltar pela conexão real que ela tem.
Um plano que diz, por escrito, em quanto tempo a empresa volta a operar. Não uma esperança verbal repetida em reunião, um número que sobreviveu a um teste.
Conexão e capacidade dimensionadas para o volume de hoje, não para o volume de quando o backup foi configurado — a empresa cresce, o volume de dados cresce junto, e o link muitas vezes fica para trás.
Mais de um lugar guardando a cópia, com pelo menos uma fora do local físico da empresa, equilibrando segurança contra incêndio ou roubo com velocidade de trazer o dado de volta quando precisar.
Um responsável e um roteiro escritos para a restauração, em vez de depender de uma pessoa que "sabe fazer" de memória e pode estar de férias no dia da pane.
É assim que a Skills IT trabalha: com simulação periódica de recuperação e um plano que registra, por escrito, quanto tempo a restauração leva de verdade.
O ganho para a empresa
O ganho de medir esse prazo antes não é o desastre nunca acontecer — é a empresa parar de improvisar durante ele. Quando o tempo de restauração já é um número conhecido, quem decide sabe se aquele prazo é aceitável para o negócio ou se vale investir num link melhor, numa cópia local além da que fica na nuvem, ou num plano de contingência para operar de outro jeito enquanto os dados voltam.
Organizações que mantiveram sistemas de backup robustos recuperaram dados criptografados em taxas quase recordes no último ano.
Sem esse número medido, cada decisão durante a pane é tomada no escuro: prometer ao cliente um prazo que ninguém verificou, decidir na hora se compensa esperar ou migrar para outra estrutura, calcular de cabeça quanto a hora parada está custando. Com o número em mãos, a mesma decisão é tomada em minutos, com a equipe de operação livre para trabalhar em vez de tentar adivinhar quanto falta.
Também é dinheiro: quanto mais cedo a empresa souber o prazo real, mais cedo consegue comparar esse custo com o de investir num link mais rápido ou numa segunda cópia mais acessível — uma conta que fica mais barata fora da pressão do incidente do que no meio dele.
Perguntas para levar à próxima reunião
- Alguém já cronometrou uma restauração completa, com o volume de dados que a empresa tem hoje? Se a resposta é "nunca testamos", o prazo que todo mundo imagina é um chute.
- A conexão usada para restaurar aguenta esse volume, ou é a mesma que atende e-mail e navegação do dia a dia? Uma coisa é mandar um anexo; outra é trazer terabytes de volta.
- Existe mais de uma cópia, em lugares diferentes, ou tudo depende de um único ponto? Um incêndio ou um roubo no local não pode ser o fim da única cópia que existia.
- O prazo de restauração está escrito em algum lugar, ou só na cabeça de quem cuida da TI hoje? Se essa pessoa sair de férias ou trocar de emprego, o número não pode sair junto.
- Se a pior pane acontecesse amanhã, a empresa sabe em quantos dias — não em quantas horas de otimismo — estaria de volta? Essa é a pergunta que vale responder antes, não durante.
