Segundo a documentação oficial da Microsoft sobre o Microsoft 365 Backup, o cenário que motivou a criação do produto não é, na maioria das vezes, um ataque sofisticado — é "a exclusão ou sobrescrita acidental ou maliciosa de conteúdo por um funcionário". A frase descreve o dia a dia de qualquer empresa que trabalha com pasta compartilhada: alguém apaga a pasta errada, ou salva um arquivo em cima da versão que ainda valia.
O motivo de a própria Microsoft vender um produto separado para esse problema é simples: o que já vem junto do Microsoft 365 — o antigo Office 365 — foi pensado para o erro do dia a dia, dentro de um prazo curto, não para devolver qualquer coisa depois de meses. Passado esse prazo, o arquivo não volta mais pelos meios normais, e muitas vezes ninguém percebe até alguém precisar exatamente daquele documento.
Para quem decide o orçamento de TI da empresa, a pergunta que interessa não é "a nuvem é segura". É: quando alguém apagar ou sobrescrever alguma coisa por engano, quanto tempo a empresa tem para perceber — e o que acontece depois desse prazo.
O erro que ninguém vê acontecer
Numa pasta compartilhada do Microsoft 365, por padrão, mais de uma pessoa tem permissão para apagar e para sobrescrever o que está ali. É o que torna a pasta útil para o time inteiro trabalhar junto. É também o que torna o erro fácil: um clique errado numa pasta inteira, um arquivo salvo com o mesmo nome de outro que já existia, uma limpeza de fim de ano que levou junto algo que ainda estava em uso.
A sobrescrita é o caso mais traiçoeiro dos dois. Quando um arquivo é apagado, a empresa ao menos sabe que ele sumiu: a pasta fica visivelmente menor. Quando um arquivo é sobrescrito, o nome continua no mesmo lugar, do tamanho de sempre, e ninguém percebe que o conteúdo mudou até abrir o documento e notar que faltam páginas, cláusulas ou uma planilha inteira.
Segundo a documentação da Microsoft sobre como funcionam as configurações de retenção, quando um documento tem uma política de retenção configurada, uma cópia é guardada automaticamente numa biblioteca de preservação sempre que alguém edita ou apaga o conteúdo. O detalhe que passa despercebido é a condição: essa cópia extra só existe se alguém, antes, configurou essa política. Sem ela, editar ou apagar um arquivo não deixa nenhuma cópia adicional além da lixeira e do histórico de versão padrão.
E a lixeira tem prazo. Pela documentação oficial de retenção e exclusão do OneDrive, itens removidos ficam na lixeira do site por 93 dias — depois disso, a recuperação deixa de ser possível pelos meios normais. Para quem descobre o problema no dia seguinte, 93 dias parecem uma margem folgada. Para quem só percebe quando um cliente pede de volta um contrato específico — semanas ou meses depois —, o prazo já pode ter passado sem ninguém notar.
O intervalo entre o erro e a descoberta é, na prática, o verdadeiro problema. Não é a exclusão em si — é o tempo que a empresa leva para perceber que algo sumiu, tempo em que o prazo de recuperação continua correndo sem que ninguém saiba que precisa correr atrás dele.
O jeito comum não resolve
O jeito comum de lidar com isso é confiar que "está na nuvem" já é garantia suficiente. A frase não está errada sobre o que a nuvem oferece — redundância física, funcionamento mesmo se um equipamento falhar —, mas ela responde a uma pergunta diferente da que interessa aqui. Redundância protege contra a Microsoft perder o dado num problema de data center. Não protege contra a própria empresa apagar ou sobrescrever o que é dela.
Outra versão do mesmo hábito é deixar a pasta compartilhada com permissão ampla demais: todo mundo edita, todo mundo apaga, e ninguém decidiu isso de propósito — foi crescendo à medida que a equipe cresceu e ninguém revisou depois. Quanto mais gente pode apagar uma pasta inteira, maior a chance de alguém fazer isso sem querer, e menor a chance de identificar rápido quem foi.
O terceiro hábito comum é nunca ter testado a recuperação. A empresa sabe que existe uma lixeira, mas ninguém nunca tentou recuperar um arquivo antigo dali para ver se ainda estava disponível, comparar a versão restaurada com a que fazia falta, ou medir quanto tempo o processo leva. Descobrir que o prazo já passou, ou que a versão recuperada não é a esperada, no meio de uma emergência real, é o pior momento possível para aprender isso.
O que precisa existir na prática
Um ambiente preparado para esse tipo de erro cotidiano se apoia em mecanismos verificáveis, não na confiança de que "a nuvem cuida disso".
Uma cópia de segurança separada da lixeira padrão, com um prazo de retenção maior do que os poucos meses do recurso nativo — para o documento que só vai fazer falta daqui a um ano.
Permissão de apagar restrita a quem realmente precisa dela, em vez de liberada para a pasta inteira por padrão. Quem só precisa ler ou editar um documento não precisa poder apagar a pasta inteira.
Simulação periódica de recuperação de um arquivo real, para saber, antes de precisar de verdade, quanto tempo o processo leva e se a versão recuperada é a que a empresa esperava encontrar.
Um responsável único acompanhando o que muda nas pastas mais críticas, em vez de a descoberta depender de o cliente ligar perguntando pelo contrato que sumiu.
Revisão periódica de quem tem acesso a cada pasta compartilhada, para que a lista de quem pode apagar acompanhe quem realmente ainda trabalha com aquilo — e não quem trabalhava há dois anos.
É assim que a Skills IT trabalha: com cópia de segurança separada da lixeira nativa, permissão de apagar restrita a quem precisa dela, e simulação periódica de recuperação para garantir que o arquivo volta quando for preciso.
O ganho para a empresa
O ganho aqui não é abstrato. Uma empresa que descobre a exclusão ou a sobrescrita no mesmo dia tem uma tarefa simples: restaurar um arquivo da lixeira, ou de uma cópia de segurança recente. Uma empresa que descobre semanas depois enfrenta outra coisa: reconstruir o documento de memória, pedir de volta a informação a alguém que talvez já tenha saído da empresa, ou aceitar que aquele conteúdo não existe mais.
Tem também o lado que a LGPD coloca na mesa quando a pasta que sumiu guarda dado de cliente ou de funcionário. Segundo a Autoridade Nacional de Proteção de Dados, um incidente de segurança é um evento que compromete a confidencialidade, a integridade, a disponibilidade ou a autenticidade de um dado pessoal — ou seja, perder o acesso a um dado também conta, não só vazar ele. Quando esse incidente representa risco relevante aos titulares, a comunicação à ANPD precisa acontecer em até três dias úteis. Uma empresa que só percebe o problema meses depois já perdeu esse prazo sem nem saber que ele existia.
Há ainda um ganho menos visível: ninguém precisa mais decidir, no meio da correria, se aquele arquivo salvo há dois anos "provavelmente ainda está lá". Com um prazo de retenção conhecido e já testado, a resposta está definida antes de o problema acontecer — e a equipe gasta o tempo trabalhando, em vez de reconstruindo o que já existia antes.
Um roteiro para começar
- Pergunte quanto tempo um arquivo apagado ou sobrescrito fica recuperável na sua empresa hoje. Se a resposta for "não sei", essa é a primeira lacuna a fechar.
- Liste quem pode apagar cada pasta compartilhada importante. Se a resposta for "todo mundo", vale rever antes que alguém descubra isso por acidente.
- Peça para alguém testar a recuperação de um arquivo antigo. Se o processo demorar mais do que a empresa imaginava, ou a versão recuperada não for a esperada, é melhor descobrir isso agora.
- Verifique se existe alguma cópia de segurança além da lixeira padrão. Sem ela, o prazo de recuperação da empresa é exatamente o prazo da lixeira, e nada além dele.
- Combine, por escrito, quem é avisado quando um documento sensível some. Sem um caminho claro, a descoberta acaba dependendo de coincidência — um cliente que liga perguntando, um contrato que alguém procura e não acha.
