Uma empresa de contabilidade em Belo Horizonte perdeu três dias de trabalho depois de um ataque de ransomware. Não porque não tinha backup. Tinha. O problema foi descoberto na hora H: o backup estava configurado, mas ninguém tinha testado a restauração. O arquivo existia. Os dados, não.
Isso não é caso extremo. É o padrão. Uma pesquisa da seguradora At-Bay com sinistros reais de ransomware mostrou que 31% das empresas que tinham backup ativo falharam em restaurar os dados quando precisaram. Não 31% sem backup. 31% das que achavam que estavam protegidas.
A pergunta que este post responde não é "qual solução de backup contratar". É outra: o que você tem hoje vai funcionar quando você precisar?
Ter backup e ter recuperação garantida são coisas diferentes
Backup é o processo de copiar dados. Recuperação é o processo de usar essa cópia para voltar a operar. São etapas distintas, com pontos de falha distintos.
Você pode ter backups funcionando há meses e ainda assim não conseguir recuperar nada em uma emergência. Isso acontece por motivos que raramente aparecem nos relatórios de TI: o backup foi configurado para uma versão antiga do sistema operacional, o destino ficou sem espaço e o processo silenciou sem alertar ninguém, o arquivo está lá mas o banco de dados precisa de etapas extras para restaurar consistência.
O relatório Veeam Data Protection Trends 2024 entrevistou 1.200 organizações e encontrou que apenas 58% conseguiram executar recuperação de dados conforme o plano quando testaram. No mesmo estudo, 85% das empresas identificaram discrepâncias entre o que conseguiam restaurar e o que precisavam restaurar para manter os processos de negócio.
Isso significa que 4 em cada 5 empresas que testaram o backup descobriram que ele não cobria o que achavam que cobria.
O custo dessa descoberta tardia também está documentado. O At-Bay calculou que o custo médio de um sinistro onde o backup falhou foi US$190.000 maior do que quando a restauração funcionou. Empresas que não conseguiram restaurar foram três vezes mais propensas a pagar o resgate.
RTO e RPO na prática: em quanto tempo sua empresa volta a operar e quanto dado você pode perder
RTO é Recovery Time Objective: o tempo máximo que sua empresa aguenta ficar sem o sistema antes de o impacto ser inaceitável. RPO é Recovery Point Objective: o volume máximo de dados que você pode perder sem que isso cause dano irreversível.
Esses dois números existem para forçar uma conversa que a maioria das empresas nunca tem: o que é aceitável perder?
Para uma clínica com 200 atendimentos por dia e prontuários eletrônicos, um RPO de 24 horas significa aceitar perder um dia inteiro de registros. Dependendo das obrigações legais do setor, isso não é aceitável. Para um escritório de projetos onde os arquivos mudam uma vez por semana, um RPO de 24 horas pode ser suficiente.
A maioria das soluções de backup de PME no mercado oferece backups diários como padrão. Isso significa RPO de 24 horas no melhor caso. Se o ataque acontece às 23h50, você pode perder quase um dia inteiro de trabalho mesmo com backup funcionando corretamente.
RTO depende do que você precisa restaurar e de onde. Restaurar 500GB de dados de um bucket S3 Glacier com velocidade de download de 50 Mbps leva perto de 22 horas só de transferência. E isso assumindo que a restauração começa imediatamente. No modelo Glacier Deep Archive da AWS, o tempo mínimo de recuperação no modo padrão é 12 horas antes de os dados ficarem disponíveis para download. No modo bulk, 48 horas.
Se o seu RTO é "precisamos estar operando em 4 horas", um backup em Glacier Deep Archive não atende. Não importa o quanto você paga por armazenamento.
O que vale colocar em cloud e o que não vale: dado quente, dado frio e a taxa de egress que ninguém avisa
O problema começa na diferença entre dado quente e dado frio.
Dado quente é o que muda com frequência e precisa estar disponível rápido: banco de dados do sistema de gestão, arquivos em uso, e-mails dos últimos 30 dias. Dado frio é o que raramente muda e raramente precisa ser acessado: notas fiscais de dois anos atrás, contratos encerrados, gravações de reuniões antigas.
A separação importa porque os custos de recuperação são radicalmente diferentes dependendo de onde você guardou cada coisa.
AWS S3 Glacier Deep Archive cobra US$0,00099 por GB por mês de armazenamento. Isso dá aproximadamente US$1 por terabyte por mês. Parece barato. Mas a taxa de recuperação padrão é US$0,02 por GB. Isso é US$20 por terabyte para trazer os dados de volta. Além da taxa de recuperação, existe o egress: saída de dados para internet custa US$0,09 por GB, ou US$90 por terabyte.
Guardar 10TB em Glacier Deep Archive custa US$10 por mês. Restaurar esse mesmo volume custa US$1.100 em taxas de retrieval e egress. Isso não aparece no contrato inicial. Aparece na fatura do mês em que você precisou dos dados.
O blog técnico LeanOps documentou esse cenário com o título "Glacier's Trap: $1/TB to Store, $20K to Retrieve" (em referência a volumes maiores), mostrando que o custo real de restauração inclui ainda o mínimo obrigatório de 180 dias de armazenamento independente de quando o objeto é deletado.
Azure Archive Tier tem estrutura similar: US$0,003 por GB de armazenamento e US$0,022 por GB de taxa de recuperação. O custo de recuperar é aproximadamente 7 vezes o custo de armazenar, por GB.
Backblaze B2 funciona diferente: oferece egress gratuito até 3x o volume médio de armazenamento mensal e não cobra taxa de retrieval separada. Para empresas que precisam restaurar dados com alguma frequência, o modelo de precificação faz diferença real.
A regra prática: dado que você pode precisar restaurar em menos de 24 horas não vai bem em tier de arquivo frio. O custo de armazenamento barato não compensa quando o custo de recuperação é 7 a 90 vezes maior por GB restaurado.
Quanto custa backup em cloud para PME na prática: armazenamento mais restauração no mesmo cálculo
A maioria dos comparativos de preço de backup em cloud mostra só o custo de armazenamento. Isso é como comparar o preço de uma impressora sem contar o cartucho.
O custo real tem quatro componentes: armazenamento mensal, transferência de entrada (geralmente gratuita), transferência de saída (egress) e taxa de recuperação (retrieval).
Para uma PME com 2TB de dados relevantes, distribuídos entre dado quente e dado frio, um cenário realista fica assim:
Dado quente (500GB, acesso rápido necessário): solução como Backblaze B2 ou S3 Standard. Custo de armazenamento em torno de US$5 a US$12 por mês. Recuperação sem surpresas de custo.
Dado frio (1,5TB, raramente acessado): S3 Glacier ou Azure Archive. Custo de armazenamento em torno de US$1,50 a US$4,50 por mês. Mas se você precisar restaurar tudo, adicione US$150 a US$180 de retrieval mais US$135 de egress no caso da AWS. Total de recuperação: US$285 a US$330 para um volume de 1,5TB.
O ponto que a maioria dos gestores não considera: quanto o sistema inteiro custa se você precisar acionar uma vez por ano? Se a resposta for "não sei", você não tem o custo real do seu backup.
O teste mínimo que toda empresa deveria fazer uma vez por ano
Apenas 50% das empresas testam planos de recuperação anualmente. 7% nunca testam. E apenas 13% das organizações conseguem orquestrar com sucesso a recuperação durante uma situação real de desastre.
Esses números juntos descrevem o problema: quase ninguém testa, e quando uma emergência real acontece, a maioria falha.
O teste mínimo não exige equipe técnica especializada. Exige três horas, alguém disposto a executar o processo e um ambiente separado onde restaurar sem afetar o sistema em produção.
Passo 1: identifique os três arquivos mais críticos para o negócio. Não tente restaurar tudo. Escolha o banco de dados do sistema de gestão, a planilha de clientes ativos e um arquivo de configuração que o sistema precisaria para funcionar.
Passo 2: localize o backup desses três arquivos na solução atual. Onde estão? Em qual data? Quem consegue acessar?
Passo 3: restaure em um ambiente isolado. Pode ser uma máquina virtual, um computador diferente do que usa no dia a dia, ou uma pasta separada. O objetivo é não contaminar o ambiente de produção.
Passo 4: abra e valide o conteúdo restaurado. O banco de dados abre? Os registros estão lá? A data do último dado é a que você esperava?
Passo 5: cronometre o processo completo. Desde "decidir restaurar" até "dados disponíveis para uso". Esse número é o seu RTO real, não o estimado.
Se você não conseguir completar o passo 2, você não tem backup operacional. Você tem uma configuração de backup.
Se o passo 4 falhar, você tem o mesmo problema da empresa de contabilidade de BH.
Se o tempo do passo 5 for incompatível com o que sua operação aguenta parada, você tem um plano que não serve para o momento que mais importa.
O que fazer se seu backup não passar no teste
Se o teste revelar falha, o problema é quase sempre um destes: destino de backup cheio ou inacessível, credenciais expiradas, processo configurado mas nunca validado, ou incompatibilidade entre versão do sistema e versão do backup.
O caminho mais rápido para corrigir depende de onde está a falha.
Destino inacessível: verifique as credenciais de acesso ao serviço de cloud. Muitas soluções de backup usam tokens de API com validade. Se o token expirou, o backup continua reportando sucesso mas não está enviando nada.
Processo nunca validado: reconfigure do zero com um escopo menor. Escolha um único banco de dados crítico, defina backup a cada 6 horas, e faça uma restauração completa antes de expandir para o restante dos dados.
Incompatibilidade de versão: esse é o mais complicado de resolver sozinho. O backup pode estar íntegro, mas o sistema atual pode precisar de passos específicos para importar dados de uma versão anterior. Documentação do fornecedor do software é o primeiro lugar para procurar. Se não houver documentação clara, é o momento de chamar alguém com experiência no sistema.
O que não fazer: não ignore o resultado do teste esperando que funcione quando precisar de verdade. A estatística de que 13% conseguem recuperar em uma situação real existe porque a maioria das outras 87% também achava que estava coberta.
Se você chegou aqui e ainda não sabe se conseguiria completar os cinco passos do teste acima com os seus dados atuais, isso já é um diagnóstico. A Coffe&Code Labs faz uma avaliação de uma hora onde você descobre exatamente isso: se a sua proteção atual resistiria a uma emergência real, quais dados estão em risco e o que precisaria mudar para que o backup não seja só uma linha no contrato. Veja nosso serviço de consultoria cloud para empresas ou agende uma conversa com a gente.