No dia 94 depois que um colaborador apagou por engano uma pasta inteira do SharePoint, alguém finalmente percebeu a falta. A equipe de TI foi até o painel administrativo tranquila, porque sabia que havia uma política de retenção configurada no ambiente havia meses. Abriu o Microsoft Purview, procurou a pasta, e não havia nada para restaurar. A política de retenção estava lá, ativa, bem configurada, e mesmo assim não devolveu o que tinha sido perdido. Retenção e backup não fazem a mesma coisa, e essa diferença costuma aparecer justamente no dia em que alguém precisava que ela não existisse.
Esse tipo de confusão é comum o suficiente para já ter virado alerta de mercado: no guia completo de backup do Microsoft 365 da InfoB, citamos o consultor e Microsoft MVP Ben Stegink, que resumiu o problema num webcast da Redmond Magazine dedicado a reformular estratégias de backup para 2026: muitas organizações tratam política de retenção e backup como sinônimos, quando retenção foi desenhada para compliance e e-discovery, não para restaurar a operação depois de um incidente. Este artigo aprofunda exatamente essa distinção: o que cada mecanismo faz por dentro, onde a retenção realmente ajuda, e em que ponto ela para de proteger.
Qual é a Diferença Entre Backup e Retenção?
A diferença começa numa pergunta simples: quantas cópias do dado existem depois que o mecanismo age? Uma política de retenção não cria copia nenhuma. Ela pega o dado que já existe, no mesmo local onde ele sempre esteve, e impede que seja apagado definitivamente antes do prazo configurado. Se o dado for corrompido, criptografado por ransomware ou alterado por engano, a retenção preserva exatamente essa versão comprometida — preservar o que já está lá, bom ou ruim, é a função para a qual ela foi desenhada.
Backup segue uma lógica diferente: cria uma segunda cópia, guardada separadamente do dado original, capturada num momento específico no tempo. Se o ambiente inteiro for comprometido, se um administrador malicioso apagar tudo, ou se um ataque de ransomware criptografar arquivos em massa, essa cópia separada continua existindo em outro lugar, intacta, pronta para restaurar o estado de antes do incidente.
O que a retenção resolve de verdade
No Microsoft 365, retenção é administrada pelo Microsoft Purview através de políticas e rótulos que colocam o conteúdo numa espécie de estado protegido. Para SharePoint e OneDrive, isso significa mover o item para a Preservation Hold Library, uma biblioteca oculta que guarda o conteúdo mesmo depois que o usuário o exclui. No Exchange, funciona de forma parecida: mensagens sujeitas a retenção ou a litigation hold vão para uma pasta oculta, fora do alcance da exclusão comum. Isso resolve muito bem três problemas específicos: impedir que um funcionário apague algo que a empresa é legalmente obrigada a manter, sustentar um processo de e-discovery quando a Justiça pede acesso a comunicações antigas, e provar, numa auditoria, que a política de ciclo de vida da informação foi cumprida.
O que a retenção não resolve
Retenção está amarrada ao mesmo tenant que está tentando proteger. Se uma credencial administrativa for comprometida e a política de retenção for alterada ou desativada, a proteção desaparece junto. E mesmo funcionando perfeitamente, retenção não sabe distinguir uma versão boa de uma versão ruim do mesmo arquivo: ela preserva o que está lá, criptografado ou não. Um item recuperado da Preservation Hold Library depois de um ataque de ransomware continua sendo o item criptografado, só que agora fora do lixo. Restaurar a operação de verdade exige achar uma versão anterior ao ataque, e isso é trabalho de outro mecanismo.
A Retenção do Microsoft 365 Protege Contra Ransomware?
Essa pergunta gera mais falsa sensação de segurança do que qualquer outra neste tema. O Microsoft 365 tem três camadas nativas que costumam ser tratadas como sinônimos e não são: a lixeira de dois estágios, a retenção via Purview, e o Files Restore.
A lixeira de dois estágios do OneDrive e do SharePoint guarda o item excluído por 93 dias. Se o ransomware criar uma cópia criptografada e apagar o arquivo original, esses 93 dias dão margem para restaurar o item apagado, mas, de novo, o item que volta é o criptografado, não o original. Quem resolve o problema de fato é o Files Restore, um recurso separado que permite reverter todo o OneDrive ou uma biblioteca inteira do SharePoint para um ponto específico dos últimos 30 dias, de uma vez, sem precisar recuperar arquivo por arquivo. Segundo a própria documentação de proteção contra ransomware da Microsoft, em cenários de ataque em massa a Microsoft também consegue ajudar a reverter arquivos do OneDrive e do SharePoint para até 14 dias antes, uma camada adicional além do autoatendimento do Files Restore.
O Exchange Online não tem um Files Restore equivalente. E-mails contam com recuperação de item único e com as próprias políticas de retenção, que preservam mensagens excluídas, mas não oferecem um botão de “voltar a caixa inteira para antes de terça-feira”. Essa assimetria entre workloads é um dos motivos pelos quais uma estratégia de backup séria não pode se apoiar só no que já vem habilitado por padrão.
Como Isso se Conecta com Compliance e LGPD
Retenção e backup também respondem a exigências legais diferentes. Uma política de retenção plurianual, de cinco ou sete anos, prova que a empresa manteve um documento fiscal ou trabalhista pelo prazo exigido. Isso satisfaz a obrigação de guarda, mas não satisfaz sozinha o Art. 46 da LGPD, que exige medidas técnicas capazes de proteger dados pessoais contra destruição acidental ou ilícita. Guardar um dado por sete anos no mesmo ambiente que pode ser comprometido por um único administrador mal-intencionado não é a mesma coisa que ser capaz de recuperá-lo depois de um incidente. O guia completo de backup do Microsoft 365 detalha como estruturar essa camada de recuperação junto com o restante da estratégia de compliance; aqui o ponto é mais estreito: retenção prova que você guardou, backup prova que você consegue voltar atrás.
Como Saber se Sua Empresa Está Confundindo os Dois
Um teste rápido costuma expor o problema antes que um incidente real precise fazer isso por você: peça para alguém do time restaurar, agora, um item específico de 60 dias atrás, sem usar a lixeira comum. Se a resposta envolver abrir um chamado com a Microsoft, esperar um SLA de suporte, ou admitir que não existe esse caminho, a empresa provavelmente está usando retenção como se fosse backup. Outros sinais: ninguém sabe apontar onde fica a cópia separada dos dados de Teams e Power Platform, o RPO e o RTO nunca foram formalmente definidos com as áreas de negócio, ou a única resposta para “e se o tenant inteiro for comprometido” é um silêncio desconfortável.
Se esse teste rápido não teve uma resposta clara na sua empresa, o próximo passo natural é um diagnóstico completo, não outra política de retenção configurada em cima da mesma lacuna. A InfoB é parceira certificada Microsoft e ajuda a estruturar essa camada de recuperação junto com o time de TI. Fale com um especialista da InfoB.
Conclusão
Retenção e backup nasceram para resolver problemas diferentes, e tratá-los como intercambiáveis é o tipo de decisão que só custa caro na hora em que já é tarde para corrigi-la. Retenção garante que um dado não some antes do prazo que a lei ou a política interna exige. Backup garante que existe um caminho de volta quando esse mesmo dado, ou o ambiente inteiro ao redor dele, deixa de estar íntegro. Nenhum dos dois substitui o outro, e uma estratégia de proteção de dados completa para o Microsoft 365 precisa dos dois funcionando ao mesmo tempo, não escolhendo um no lugar do outro. Para montar essa estratégia do zero, o guia completo de backup do Microsoft 365 da InfoB e o artigo Microsoft 365 tem backup? são os próximos passos naturais depois deste.
Perguntas Frequentes
Retenção é a mesma coisa que backup?
Não. Retenção é uma política que impede a exclusão definitiva de um dado por um período determinado, mas continua sendo a mesma cópia, no mesmo ambiente. Backup cria uma cópia independente, guardada separadamente, que pode ser restaurada para um ponto no tempo mesmo que o dado original seja apagado, corrompido ou criptografado.
A retenção do Microsoft 365 protege contra ransomware?
Só parcialmente. Se um arquivo é criptografado e depois excluído, a retenção impede a exclusão definitiva e permite recuperar o arquivo dentro do prazo, mas o arquivo recuperado continua criptografado. Retenção preserva o que existe, não devolve uma versão limpa de antes do ataque. Quem cumpre esse papel é o Files Restore do OneDrive e do SharePoint, ou uma solução de backup de terceiros.
Por quanto tempo o Microsoft 365 mantém dados apagados?
O Exchange Online mantém itens excluídos por 14 dias, configurável até 30. OneDrive e SharePoint mantêm por 93 dias em lixeira de dois estágios. Depois desse prazo, existe uma janela adicional de até 14 dias em que a própria Microsoft ainda pode recuperar o dado em cenários de ataque em massa, e depois disso a exclusão é definitiva.
Se já configurei retenção no Purview, ainda preciso de backup?
Precisa, sim. Retenção e backup respondem perguntas diferentes: retenção garante que um dado não desapareça antes do prazo exigido por lei ou por política interna; backup garante que existe uma cópia recuperável se o ambiente inteiro, incluindo a retenção, for comprometido. Uma política de retenção bem configurada não substitui uma cópia guardada fora do tenant.
O Microsoft 365 Backup nativo é retenção ou é backup?
Tecnicamente, backup: ele cria uma cópia separada dos dados de Exchange Online, SharePoint e OneDrive, com restauração para um ponto no tempo. A diferença em relação a uma solução de terceiros é que essa cópia continua dentro do perímetro da Microsoft, o que reduz, mas não elimina, a dependência do mesmo provedor que se está tentando proteger.
Retenção de longo prazo, de 5 ou 7 anos, substitui backup?
Não substitui. Retenção de longo prazo garante que um dado fique disponível para fins fiscais, trabalhistas ou de auditoria, mas continua sendo uma única cópia dentro do ambiente Microsoft 365. Se essa cópia for corrompida, criptografada ou apagada por erro de configuração, o prazo de retenção não cria uma segunda versão para restaurar.