O tempo e o backup: o risco omitido que a maioria das empresas ainda ignora

O erro invisível da retenção herdada

Na quinta-feira, durante uma análise de segurança com uma empresa de software, eu fiz uma pergunta simples:

“Por quanto tempo vocês mantêm o backup dos sistemas dos clientes?”

A resposta veio pronta:

“Trinta dias. Sempre foi assim.”

Perguntei o motivo. O silêncio que veio depois dizia muito. Alguns segundos se passaram até que o responsável completou:

“Porque o antigo provedor também fazia com trinta dias.”

E ali estava o erro — um dos mais perigosos que se perpetuam na rotina das empresas de tecnologia: a retenção herdada.

São configurações copiadas de ambientes anteriores, políticas que nunca foram revisitadas e decisões tomadas sem contexto de negócio. Com o tempo, esse hábito se transforma em regra. E a regra se transforma em crença. De repente, a empresa acredita que está fazendo backup de forma correta — quando, na verdade, está apenas repetindo uma prática sem propósito.

Nos últimos meses, ouvi respostas semelhantes em empresas de diferentes segmentos.

Uma healthtech que mantinha apenas três dias de cópias completas, acreditando que “seria suficiente”. Um e-commerce que guardava sete dias, confiando que “nunca precisou de mais do que isso”. E um caso particularmente emblemático: uma fornecedora de ERP que atendia centenas de clientes e garantia que “guardava todos os dados desde o início do contrato”, porque fazia o backup do banco de dados completo.

Mas, quando fomos verificar o processo real, descobrimos que o backup de fato era de apenas 30 dias, o mesmo erro, o mesmo conceito distorcido. Eles acreditavam que o backup do banco guardava todo o histórico, quando, na prática, ele apenas copiava o estado atual do banco, não o passado.

Esse é o tipo de engano que se multiplica porque soa lógico à primeira vista.
Afinal, o banco de dados tem histórico, certo? Então, se o backup do banco é feito hoje, ele guarda tudo o que está lá. O problema é que ninguém percebe que, se um dado for apagado ou alterado, e essa alteração passar despercebida por mais de 30 dias, aquela versão do dado deixa de existir para sempre. Quando a empresa finalmente precisar provar uma informação antiga — seja uma nota fiscal, uma transação, ou um registro de cliente — ela vai descobrir que o backup foi feito, sim, mas apenas das versões mais recentes. O passado foi sobrescrito.

Essa é a natureza silenciosa do problema: ele não aparece nos testes de restauração, não gera alerta, não causa lentidão, não estoura disco. Ele simplesmente apaga o tempo.
E quando isso acontece, é tarde demais para corrigir.

Hoje, com o avanço das soluções em nuvem, esse erro mudou de formato, mas não desapareceu. Empresas que utilizam o Microsoft 365 ou o Google Workspace acreditam que estão seguras porque “nunca apagam e-mails” ou porque “está tudo na nuvem”.

Mas as políticas padrão dessas plataformas também mantêm retenção de apenas 30 dias após exclusões. Ou seja, se alguém apagar um e-mail acidentalmente, ou se uma conta for comprometida e os dados forem removidos, depois de 30 dias não há mais volta.

É a mesma falha conceitual, travestida de modernidade.

O que está em jogo aqui não é uma limitação técnica, mas um erro de entendimento.
A maioria das empresas fala sobre backup como se fosse uma questão de ferramenta, quando, na verdade, é uma questão de tempo — tempo de negócio, tempo de responsabilidade e tempo de prova. E é justamente por não compreenderem essa dimensão temporal que tantas empresas vivem sob uma falsa sensação de segurança.

O backup existe, mas não cumpre seu papel. Existe para atender à conformidade, mas não à necessidade. Protege o ambiente, mas não o histórico. E, no fim, a empresa acredita que tem cópia de tudo — quando, na verdade, só tem cópia do último mês de sua própria história.

Retenção não é histórico; backup não é continuidade

O que pouca gente percebe é que o backup, em si, não é garantia de continuidade.
Ele é apenas um dos elementos do plano, e talvez o mais incompreendido. As empresas fazem backup como quem cumpre uma obrigação técnica, mas raramente param para pensar no que aquele backup representa em termos de tempo, negócio e responsabilidade. E quando o backup não é pensado a partir do tempo, ele perde o sentido — porque o que o backup protege não é o arquivo, é a história que ele carrega.

O ponto central é simples, mas ignorado: retenção não é histórico. Retenção é o intervalo de tempo em que uma cópia é mantida disponível para restauração. Histórico é o conjunto de versões que contam a trajetória de um dado ao longo do tempo. Uma empresa pode ter 30 dias de retenção e nenhum histórico. Pode ter cópia de ontem e de anteontem, mas ter perdido para sempre uma informação de seis meses atrás — porque o ciclo de retenção já a apagou.

Quando eu explico isso a gestores e técnicos, costumo desenhar uma linha do tempo. Marco seis pontos, representando seis meses:

1. No primeiro, nasce o dado.

2. No segundo, ele é alterado.

3. No terceiro, ele é apagado.

4. No quarto, ninguém percebeu a perda.

5. No quinto, a perda continua desapercebida.

6. E quando chegamos ao sexto, o backup mais antigo já não existe e com ele, desaparece também a única prova de que aquele dado apagado um dia existiu.

Não houve falha técnica. Houve apenas o tempo, fazendo o que sempre faz: apagar o que não foi preservado.

Esse é o tipo de risco que não gera alerta, não dispara e-mail e não aparece em relatório.
Ele só se revela quando alguém precisa de algo que não existe mais. E quando isso acontece, o backup deixa de ser uma ferramenta de confiança para se tornar uma evidência de omissão. Porque o dado não se perdeu por acaso — ele se perdeu por falta de critério.

O mesmo raciocínio vale para os ambientes em nuvem, que deram às empresas uma perigosa sensação de segurança infinita. É comum ouvir frases como “está tudo na Microsoft” ou “o Google já faz backup”. Mas o que está na nuvem é a disponibilidade, não a retenção. Essas plataformas protegem o ambiente contra falhas estruturais, mas não contra o erro humano, o acesso indevido ou a exclusão intencional. E quando o problema vem de dentro — quando o próprio usuário apaga, altera ou substitui — a nuvem não tem obrigação de manter o passado por você.

Backup também não é continuidade porque continuidade é sobre tempo de reação e não sobre cópia. É sobre saber o que precisa voltar primeiro, em quanto tempo e com que impacto. Uma empresa pode ter backup de todos os seus servidores e, ainda assim, ficar uma semana parada porque ninguém sabe qual deles precisa ser restaurado primeiro. Pode ter backup de banco, mas não ter ambiente compatível para restaurar. Pode ter backup completo, mas não ter conexão para transferir os dados em tempo hábil. E é nesse intervalo que a empresa perde clientes, contratos e reputação.

Continuar operando após uma falha é muito mais do que restaurar arquivos. É entender o que é crítico, o que é essencial e o que pode esperar. E isso exige um raciocínio de negócio — não de ferramenta. Enquanto as decisões sobre backup forem tomadas com base em limitações técnicas ou comparações com “o antigo provedor”, as empresas continuarão confundindo segurança com conformidade.

O backup existe, mas o plano não. O dado está salvo, mas o processo não está preparado. E o tempo — o único elemento que não volta — continua sendo o maior inimigo da continuidade.

O custo do risco omitido

O maior problema do risco omitido é que ele não se apresenta como risco. Ele se disfarça de normalidade. O backup é feito todos os dias, os relatórios mostram sucesso, as cópias estão no ar. Nada parece errado — até o dia em que alguém precisa recuperar um dado que não existe mais. E quando isso acontece, a surpresa vem acompanhada de silêncio, culpa e explicações tardias.

Eu já vi empresas enfrentarem processos judiciais sem poder comprovar transações de meses anteriores, simplesmente porque o backup já havia rodado por cima. Vi empresas de e-commerce perderem evidências de fraudes com cartão de crédito, porque acreditavam que “o histórico estava no banco”. E vi gestoras financeiras descobrirem, tarde demais, que suas planilhas e documentos haviam sido sobrescritos por uma versão incorreta — e o backup, fiel à sua função, guardou apenas o erro.

Não houve invasão, nem falha técnica. Houve omissão. O risco estava ali o tempo todo, apenas adormecido sob a ilusão da rotina.

O custo do risco omitido é difícil de mensurar porque ele não se manifesta de forma imediata. Não é um servidor parado, não é uma queda de link, não é um alerta vermelho piscando na tela. É o custo da perda invisível: o trabalho repetido, o retrabalho silencioso, a desconfiança que surge quando os dados não batem. E, em muitos casos, o dano vai além do financeiro — ele afeta a credibilidade. Quando uma empresa perde um dado, ela perde também a confiança do cliente que esperava que aquele dado existisse.

E é nesse ponto que o erro conceitual se transforma em risco corporativo. Porque a partir do momento em que a empresa assume obrigações contratuais, fiscais ou legais, o dado deixa de ser apenas um registro técnico: ele se torna prova de compromisso. E não manter essa prova é, em essência, descumprir uma obrigação.

O backup que não preserva o tempo deixa a empresa exposta a questionamentos jurídicos, auditorias incompletas e, em alguns casos, penalidades regulatórias.

Mais do que isso: quando a política de backup não é formalizada, a responsabilidade fica sem dono. A operação executa, mas não decide. A diretoria confia, mas não entende. E quando algo dá errado, o dedo aponta sempre para o mesmo lugar — a TI. O técnico vira culpado de uma escolha que nunca foi dele. E é aí que mora o verdadeiro custo do risco omitido: a transferência injusta de responsabilidade.

Risco conhecido é gestão.

Risco omitido é negligência.

E quando a negligência é institucional, ela não é mais um erro operacional — é uma falha de governança. A empresa que escolhe manter 30 dias de retenção sabendo o que isso significa está fazendo gestão de risco. Mas a empresa que mantém 30 dias porque “sempre foi assim” está apenas empurrando o risco para alguém que não tem poder de decisão.

O mais curioso é que o custo para corrigir o problema é pequeno quando comparado ao custo de ignorá-lo. Criar uma política de backup estruturada, alinhada ao tempo de negócio, é simples e barato. Mas poucas empresas fazem, porque o retorno não é imediato. O problema é que, quando o impacto vem, ele chega multiplicado — e quase sempre no pior momento possível: uma auditoria, uma disputa judicial, uma investigação fiscal, um incidente de segurança. É o tipo de prejuízo que não se prevê em orçamento, mas que pode definir o futuro da empresa.

Backup é decisão de negócio, não da ferramenta

O que pouca gente percebe é que o backup não pertence à TI. Ele é uma decisão de negócio, disfarçada de tarefa técnica. A função da equipe técnica é garantir que o processo ocorra, que as cópias sejam verificadas, que as restaurações funcionem. Mas o quanto manter, por quanto tempo e por quê são decisões que pertencem à gestão — porque envolvem custo, risco e responsabilidade.

Quando a TI define sozinha a retenção, ela assume um risco que não deveria carregar. É o mesmo que o contador decidir, por conta própria, quais documentos fiscais a empresa deve guardar. A decisão sobre o tempo de retenção deve nascer de um diálogo entre o técnico e o gestor. O técnico traduz o impacto; o gestor define o apetite ao risco. E é dessa conversa que surge a maturidade.

Por isso, toda política de backup precisa responder a três perguntas simples:

1. O que precisa ser protegido?

2. Por quanto tempo?

3. Qual o custo e o impacto de perder isso antes desse prazo?

Quando essas respostas são claras, o backup deixa de ser um script automático e se transforma em uma política de continuidade. A empresa passa a ter domínio sobre o seu próprio tempo — sobre o quanto de passado deseja manter disponível para o futuro.

Na prática, isso significa que o backup deve nascer a partir da necessidade do negócio, e não da capacidade do disco. Não é o armazenamento que define o risco; é o compromisso da empresa com o seu cliente, com a lei e com a própria história. O custo de guardar pode ser alto. Mas o custo de não guardar costuma ser incalculável.

O papel da TI é levar essa conversa à mesa de decisão. Mostrar, com dados, o que se ganha e o que se perde em cada cenário. Explicar que manter 30 dias é uma escolha possível — desde que o negócio aceite conscientemente o risco que vem com ela.

Esse é o ponto da virada: assumir o risco não é errado. Errado é fingir que ele não existe.

E quando o backup é tratado como uma política de negócio, ele deixa de ser uma obrigação e passa a ser uma estratégia. A estratégia de proteger a história da empresa — não apenas os seus dados.

O tempo continua sendo o maior inimigo da continuidade. Mas quando o tempo é mapeado, medido e protegido, ele deixa de ser ameaça e passa a ser ativo. E é exatamente aí que a maturidade em segurança começa.

Um convite à reflexão

E na sua empresa?

• O backup é uma decisão técnica ou uma decisão de negócio?

• Quem define o tempo de retenção — o servidor ou a gestão?

• Você sabe quanto tempo do seu passado realmente está protegido?

Se esse texto fez sentido para você, compartilhe com quem precisa pensar sobre isso — porque segurança não é apenas sobre dados. É sobre tempo, responsabilidade e continuidade.