Backup de Teams e SharePoint: o que a Microsoft nao restaura por voce

O mito da retenção infinita no Microsoft 365

Existe uma crença confortável entre gestores de TI: "está tudo na nuvem da Microsoft, então está protegido". A confusão nasce de uma leitura equivocada do modelo de responsabilidade compartilhada. A Microsoft garante a disponibilidade da infraestrutura, a redundância dos datacenters e a integridade da plataforma. O que ela não garante é a preservação dos seus dados contra as ações dos seus usuários.

Na prática, isso significa que uma falha de hardware em Dublin não vai apagar o seu SharePoint — mas um colaborador que exclui uma biblioteca de documentos inteira na sexta-feira, e ninguém percebe até a auditoria de dois meses depois, vai. A Microsoft cumpriu o contrato dela integralmente nesse cenário. O dado sumiu porque a retenção nativa expirou, e a retenção nativa é curta por design.

O próprio contrato de serviços da Microsoft é explícito sobre isso, ainda que poucos leiam o parágrafo:

Recomendamos que você faça backup regular do Seu Conteúdo e Dados armazenados nos Serviços ou armazenados usando Aplicativos e Serviços de Terceiros, usando ferramentas de terceiros.

Não é uma sugestão de rodapé. É o reconhecimento formal de que a plataforma não é um sistema de backup, e nunca pretendeu ser. Lixeira, versionamento e políticas de retenção são recursos de continuidade operacional — resolvem o "apaguei sem querer agora há pouco". Não resolvem corrupção silenciosa, ransomware com dwell time longo, ex-funcionário mal-intencionado ou exigência regulatória de guarda por sete anos.

Os prazos reais: quanto tempo você realmente tem

Vale conhecer os números exatos, porque a diferença entre o que as pessoas imaginam e o que a plataforma entrega costuma ser de ordens de grandeza. No SharePoint Online e no OneDrive, um item excluído vai para a lixeira do site por 93 dias. Dentro desse período, ele pode ser restaurado pelo usuário ou, na segunda etapa (lixeira do administrador do conjunto de sites), pelo admin. Passados os 93 dias, o item é purgado definitivamente e nem o suporte da Microsoft consegue trazê-lo de volta.

Quando o site inteiro é excluído, o prazo é o mesmo: 93 dias na lixeira de sites do Centro de Administração do SharePoint. Depois disso, a coleção some, com todas as bibliotecas, listas, permissões e metadados. Se o site era o repositório de contratos do jurídico ou o histórico de projetos da engenharia, a perda é estrutural, não pontual.

O Teams é o caso mais delicado, porque não é um produto monolítico — é uma camada de experiência sobre vários serviços distintos. Cada peça de um time vive em um lugar diferente:

• Arquivos de canais padrão — armazenados no site do SharePoint associado ao time, sujeitos aos 93 dias.
• Arquivos de chat privado — vão para o OneDrive de quem compartilhou, na pasta "Arquivos do Microsoft Teams Chat".
• Mensagens de chat e de canal — gravadas em pastas ocultas de caixas de correio do Exchange (na caixa do usuário para chats, na caixa do grupo para canais), inacessíveis pela interface normal do Outlook.
• Estrutura do time — abas, conectores, aplicativos fixados, configurações de canal e associação de membros vivem no Microsoft Graph e no Azure AD.
• Canais privados e compartilhados — possuem sites do SharePoint próprios, separados do site principal do time.

Essa fragmentação tem uma consequência prática incômoda: restaurar "um time" não é uma operação única. Um grupo do Microsoft 365 excluído fica recuperável por apenas 30 dias — prazo bem mais apertado que os 93 do conteúdo. Se o grupo for purgado nesse intervalo, o time deixa de existir como entidade lógica mesmo que os arquivos ainda estejam tecnicamente na lixeira do SharePoint. Você recupera os documentos soltos, mas perde as conversas, o contexto e a organização que davam sentido a eles.

O que a retenção nativa não cobre — e por que isso importa

Políticas de retenção do Microsoft Purview ajudam bastante, mas costumam ser mal compreendidas. Elas foram desenhadas para compliance: impedir a exclusão de dados que a empresa é obrigada a guardar, ou forçar a exclusão de dados que a empresa é obrigada a descartar. Não foram desenhadas para recuperação.

A distinção é concreta. Uma política de retenção mantém uma cópia do item na Biblioteca de Retenção de Preservação, que é uma área oculta do próprio site. Se você precisa recuperar 4.000 arquivos de uma biblioteca atingida por ransomware, não existe um botão "restaurar tudo para o estado de terça-feira às 14h". Existe a pesquisa de conteúdo do eDiscovery, que exporta itens individualmente, sem estrutura de pastas preservada, sem permissões, sem metadados de versão — e com limites de exportação que tornam volumes grandes um exercício de paciência de vários dias.

Some a isso os cenários que a plataforma simplesmente não endereça:

1. Corrupção lenta. Um script de sincronização mal configurado sobrescreve arquivos por semanas. Quando alguém nota, todas as versões dentro da janela de retenção já estão corrompidas.
2. Ransomware com detonação atrasada. Famílias modernas criptografam gradualmente e aguardam. O versionamento do SharePoint guarda as versões novas, criptografadas, empurrando as boas para fora do limite configurado.
3. Saída de colaborador. Licença removida, caixa e OneDrive entram em contagem regressiva. Trinta dias depois, o histórico de um vendedor sênior evapora junto com o contrato dele.
4. Exigência regulatória longa. LGPD, normas setoriais e contratos com cláusula de guarda pedem retenção de anos. Noventa e três dias não conversam com isso.
5. Erro administrativo. Um admin com privilégio global aplica uma política de exclusão errada em escopo amplo. A plataforma obedece — é exatamente o que foi mandada fazer.

Em todos esses casos, o dado não foi perdido por falha da Microsoft. Foi perdido porque não existia uma cópia independente, fora do domínio de controle do tenant, com histórico longo o suficiente para atravessar o intervalo entre o incidente e a descoberta dele.

Restauração granular: o que realmente diferencia uma solução de backup

Backup de Microsoft 365 sem restauração granular é quase inútil na prática. O critério de qualidade não é a capacidade de copiar dados — isso qualquer ferramenta faz. É a capacidade de devolver exatamente o item certo, no lugar certo, com as propriedades certas, sem derrubar o resto do ambiente.

Ao avaliar uma solução, cobre estes pontos com testes reais, não com resposta comercial:

• Item único do Teams. Restaurar uma mensagem específica de um canal, com autor, timestamp e thread preservados — não um arquivo .PST solto para o usuário abrir na mão.
• Point-in-time por objeto. Voltar uma biblioteca inteira ao estado de uma data e hora, não apenas restaurar os itens excluídos.
• Permissões e metadados. Restauração que devolve colunas personalizadas, tipos de conteúdo, herança de permissão e fluxos de aprovação. Arquivo sem permissão restaurado em biblioteca aberta é incidente de segurança, não recuperação.
• Cross-user e cross-tenant. Devolver o OneDrive de quem saiu para a pasta do gestor, ou migrar dados entre tenants numa fusão.
• Canais privados e compartilhados. Muitas ferramentas ignoram esses sites. Confirme explicitamente — é a lacuna mais comum.
• Imutabilidade do repositório. Backup gravado em storage com bloqueio de objeto ou WORM, para que credencial comprometida não apague as cópias.
• Teste de restauração documentado. Backup nunca testado é hipótese, não proteção. Rotina trimestral, com evidência.

Vale também dimensionar o RTO com honestidade. Restaurar 200 GB de SharePoint via API do Graph esbarra em throttling da Microsoft, e throttling não é negociável. Uma solução que promete restauração instantânea de tenant inteiro merece ceticismo: pergunte quantos itens por hora ela sustenta na prática e planeje a janela de recuperação com esse número, não com o do folheto.

Como estruturar a proteção do seu Microsoft 365

Uma arquitetura sólida separa camadas com propósitos distintos, sem tentar fazer uma resolver o problema da outra. A retenção nativa cobre o dia a dia — usuário que apagou algo hoje e percebeu amanhã. As políticas do Purview cobrem compliance e obrigação legal de guarda. O backup de terceiros cobre desastre, ataque, malícia interna e retenção longa.

Sobre essas camadas, monte o operacional: backup com frequência compatível com o RPO acordado (para ambientes ativos, quatro execuções diárias é um piso razoável), repositório imutável e fora do tenant, monitoramento de jobs com alerta em falha — porque backup que falha em silêncio por seis semanas é o pior dos mundos —, e o teste de restauração periódico que valida a promessa. Documente o RPO e o RTO por tipo de dado: o site do jurídico e a pasta de fotos do evento de fim de ano não merecem a mesma janela.

Na Duk Informática & Cloud, esse desenho é rotina. Ao longo de 18+ anos e mais de 550 empresas atendidas, o padrão que se repete é sempre o mesmo: a descoberta de que a retenção nativa era insuficiente acontece no dia do incidente, nunca antes. Como Microsoft Gold Partner, trabalhamos os dois lados da mesa — configuramos corretamente o que a plataforma já oferece de retenção e compliance, e complementamos com backup independente, em repositório próprio no data center em Alphaville, com restauração granular de arquivos, sites, chats e canais do Teams. Monitoramento e teste de restauração entram no escopo do contrato, com suporte 24/7 e SLA, porque proteção que ninguém verifica é apenas uma linha de custo na planilha.

Se o seu ambiente Microsoft 365 hoje depende exclusivamente da lixeira de 93 dias, o exercício útil é curto: escolha o site mais crítico da empresa e pergunte quanto tempo levaria para descobrir que ele foi comprometido. Se a resposta passar de três meses, a conta já não fecha.