A conversa sobre backup no Microsoft 365 raramente começa com «vamos falar de backup». Começa com um telefonema: «apagámos a pasta de um cliente — foi há uns três meses, isso está aí em algum lado, certo?». E a resposta, demasiadas vezes, é «depende» — de quando foi, de onde estava, de quem apagou e do que estiver configurado no tenant. É uma resposta desconfortável de dar, e é evitável.
Este artigo arruma essa conversa sem alarmismo — nem o «a Microsoft não faz backup de nada!» que vende soluções, nem o «está tudo na cloud, está seguro» que adia o problema. A Microsoft protege muito mais do que o discurso comercial de terceiros admite, e menos do que muitas PME assumem. O que se segue é a distinção entre quatro coisas que andam misturadas — disponibilidade, retenção, recuperação nativa e backup — com as janelas confirmadas na documentação oficial (data no fim) e as lições dos restauros em que já estive metido.
Em resumo: o Microsoft 365 garante a disponibilidade do serviço e dá-lhe janelas de recuperação nativas que resolvem a maioria dos acidentes do dia a dia — se agir dentro do prazo. O que não dá, por omissão, é uma estratégia de backup alinhada com o negócio: janelas longas, pontos de restauro independentes e a certeza, testada, de que consegue voltar atrás. Para isso existem o Microsoft 365 Backup e as soluções de terceiros. A decisão entre «chega o que está incluído» e «preciso de mais» toma-se com riscos e tempos de recuperação — e valida-se com um teste de restauro, não com uma brochura.
A resposta curta
A proteção do serviço não é o mesmo que uma estratégia de backup. A Microsoft replica os seus dados entre datacenters e compromete-se com a disponibilidade da plataforma — o serviço foi desenhado para recuperar de falhas de infraestrutura sem intervenção do cliente, embora isso não elimine completamente a possibilidade de indisponibilidade. Mas eliminações, sobrescritas, ransomware sincronizado e saídas de colaboradores não são falhas do serviço: são alterações legítimas aos olhos da plataforma, e a plataforma executa-as com a mesma eficiência com que guarda o resto. Para esses casos tem as janelas de recuperação nativas — reciclagens, versões, Files Restore — que funcionam bem dentro dos prazos, e prazos são precisamente o que uma PME sem rotina de verificação deixa passar.
A pergunta certa não é «a Microsoft faz backup?» — é «que incidentes quero sobreviver, com que perda máxima de dados, em quanto tempo?». O resto do artigo dá-lhe os números para responder.
Quatro palavras que andam trocadas
Antes dos números, o vocabulário — porque a maioria das decisões mal tomadas nesta área vem de misturar estes conceitos:
- Disponibilidade — o serviço estar acessível. É a parte dos SLA e das réplicas entre datacenters: protege-o de falhas de infraestrutura da Microsoft, não das ações de quem usa o tenant
- Retenção — quanto tempo os dados sobrevivem depois de eliminados ou alterados: reciclagens, itens recuperáveis, políticas do Purview. Atenção à armadilha do Purview: uma política de retenção preserva conteúdo para conformidade e pesquisa (eDiscovery), mas não é um backup operacional — não há «repor a pasta como estava às 9h de terça»; há encontrar itens preservados e exportá-los, o que num incidente a sério é um processo, não um botão
- Recuperação nativa — os mecanismos incluídos para desfazer: restaurar da reciclagem, repor versões anteriores, Files Restore do OneDrive e das bibliotecas, restaurar uma conta eliminada. Gratuitos, úteis, e todos com prazo
- Backup — cópias independentes, em pontos no tempo, com uma janela definida pela organização, restauráveis em massa. É a única das quatro que responde a «quero voltar a como estava há cinco meses»
A responsabilidade partilhada, dita sem juridiquês: a Microsoft responde pela plataforma; pelos dados — o que se apaga, o que se cifra, o que sai porta fora — responde quem os usa. Não é uma cláusula escondida; é o modelo de qualquer serviço cloud, e a documentação do próprio Microsoft 365 Backup existe porque a Microsoft o assume.
O que cada serviço permite recuperar
Os três incidentes mais comuns, serviço a serviço — com as janelas por omissão confirmadas na documentação:
| Serviço | Eliminação acidental | Ransomware / sobrescrita | Saída de colaborador |
|---|---|---|---|
| Exchange Online | Itens eliminados recuperáveis 14 dias (configurável até 30); calendário 120 dias | Sem reposição point-in-time nativa da caixa de correio | Caixa de correio recuperável 30 dias após eliminar a conta; caixa partilhada ou retenção para prazos maiores |
| OneDrive | Reciclagem 93 dias (duas fases); histórico de versões | Files Restore repõe tudo num ponto dos últimos 30 dias | OneDrive retido 30 dias após eliminar a conta (configurável) + 93 na reciclagem |
| SharePoint | Reciclagem 93 dias (utilizador + coleção de sites); versões | Files Restore por biblioteca, últimos 30 dias; para conteúdo permanentemente eliminado, o suporte Microsoft pode tentar repor a coleção de sites inteira a partir de cópias mantidas 14 dias após a eliminação definitiva — não é granular nem se soma à janela | Os dados são do site, não da pessoa — sobrevivem à conta; o problema é saber o que ela tinha e onde |
| Teams | Ficheiros seguem as janelas do SharePoint e do OneDrive; uma equipa eliminada pode ser restaurada durante 30 dias através do Microsoft 365 Group associado | A recuperação de ficheiros faz-se nos serviços de baixo, não «no Teams» | As mensagens de chat e de canal têm mecanismos próprios de retenção e exportação; as cópias de conformidade no Exchange servem para pesquisa e eDiscovery, mas não permitem repor uma mensagem eliminada na interface do Teams |
As janelas, lado a lado:
Duas notas de terreno sobre esta tabela. Primeira: o Files Restore é a ferramenta mais subestimada do Microsoft 365 — repõe um OneDrive ou uma biblioteca inteira num ponto anterior e desfaz um ataque de ransomware sincronizado em minutos — mas só recupera o que ainda existe: se a reciclagem foi esvaziada, esses ficheiros não voltam por aqui. Segunda: os 93 dias da reciclagem parecem confortáveis até se perceber como os incidentes aparecem — ninguém dá pela pasta apagada no dia; dá-se por ela quando um cliente pede um documento, e entre o acidente e a descoberta passam meses. As janelas nativas falham menos por serem curtas e mais por ninguém saber que estavam a contar.
Cinco cenários, sem teatro
- Eliminação acidental — o cenário mais frequente e o mais bem coberto: reciclagens e versões resolvem, se descoberto a tempo. O padrão real é a descoberta tardia — e é ela, não a tecnologia, que decide se o nativo chega
- Utilizador malicioso — quem tem permissões pode apagar e esvaziar reciclagens; com acesso suficiente, pode encurtar o que é recuperável. É o cenário que separa retenção de backup: uma política de retenção bem montada preserva mesmo contra o próprio; um backup independente idem. As reciclagens, não
- Ransomware — nos ficheiros sincronizados, o Files Restore de 30 dias é uma resposta nativa honesta (pare a sincronização primeiro; a documentação de resposta é explícita nisso). O que o cenário expõe é outra coisa: quanto tempo demora a descobrir + decidir + restaurar tudo, e se 30 dias chegam quando o ataque é detetado tarde
- Saída de colaborador — o relógio começa a contar no dia em que a conta é eliminada: 30 dias para a caixa de correio, 30 + 93 para o OneDrive. O processo de offboarding (que dados preservar, para quem) vale mais do que qualquer ferramenta — é um dos pontos do nosso checklist de segurança, e a lição repete-se: quando os RH avisam a equipa de TI semanas depois, as janelas já estão a meio
- Obrigação de retenção — contratos, fisco, setor regulado: aqui a resposta é retenção (Purview) e, se a obrigação incluir cópias independentes ou prazos longos de restauro, backup. Distinga sempre a capacidade técnica do requisito legal: «conseguimos guardar 7 anos» e «somos obrigados a conseguir restaurar em 48h» são frases de documentos diferentes
Microsoft 365 Backup e as soluções de terceiros
Desde 2024 que a resposta da própria Microsoft a este problema existe como produto: o Microsoft 365 Backup. O que a documentação confirma, em números: cobre Exchange, OneDrive e SharePoint; janela de recuperação configurável de 3, 6, 12 ou 24 meses; pontos de restauro de 10 em 10 minutos (nas duas primeiras semanas para OneDrive/SharePoint, nas 52 semanas para Exchange) e snapshots semanais depois; armazenamento imutável (append-only) dentro da fronteira de dados do Microsoft 365, respeitando a residência do tenant; restauros incluídos no preço, faturado ao consumo — 0,15 dólares por GB por mês, via subscrição Azure. Um ficheiro individual restaura em minutos; cargas grandes têm débitos documentados na ordem de 1 a 3 TB/hora.
As soluções de terceiros (Veeam, Acronis, AvePoint, Synology e afins) continuam a ter espaço, e a comparação honesta é por critérios, não por marcas:
- Onde fica a cópia — o Microsoft 365 Backup guarda dentro da plataforma Microsoft (rápido, simples, sem egress); terceiros podem guardar fora — noutro serviço cloud ou on-premises. Se um requisito contratual ou o seu apetite de risco pedir independência total do fornecedor, só a segunda opção responde
- Cobertura — o produto da Microsoft cobre os três workloads principais; quem precisar de mais (Teams como estrutura, outros serviços) encontra-o em terceiros — verifique exatamente o que do Teams cada um cobre, porque «faz backup do Teams» esconde âmbitos muito diferentes
- Janela e granularidade — 24 meses chegam à maioria das PME; obrigações de 7 anos não se resolvem aqui. No produto da Microsoft, o restauro granular de ficheiros e pastas do SharePoint e OneDrive já está disponível, com pontos aproximadamente diários nos primeiros 14 dias e semanais depois (o restauro completo de contas e sites mantém os pontos de 10 minutos nos primeiros 14 dias); o mecanismo de reposição através das versões dos ficheiros, preservando as restantes versões, continua indicado pela Microsoft como funcionalidade futura
- Custo real — ao consumo vs. por utilizador/mês: com muitos dados por utilizador, a conta ao GB cresce; simule com os seus números, não com os do exemplo do fornecedor
A minha posição, assinalada como avaliação editorial: para uma PME sem requisito de cópia externa, o Microsoft 365 Backup mudou a conversa — a fasquia para justificar um terceiro subiu. Para quem tem esse requisito, ou vive de prazos longos, a resposta continua a ser externa. Em ambos os casos, a pior opção é a mais comum: nenhuma decisão formal, e a esperança de que as reciclagens cheguem.
Os seis critérios que decidem
- RPO — quanto pode perder — a diferença entre o último ponto de restauro e o incidente. Pontos de 10 em 10 minutos vs. «o que estiver na reciclagem» é a distância entre perder uma reunião e perder um trimestre
- RTO — quanto tempo pode estar parado — meça contra o pior caso realista: restaurar tudo, não um ficheiro. É aqui que os testes desmentem as brochuras
- Granularidade — consegue restaurar um item, uma pasta, uma caixa de correio, sem arrastar o resto? E uma versão específica?
- Localização e imutabilidade — a cópia sobrevive a um administrador comprometido? Sai da plataforma se o contrato o exigir?
- Testes — um backup nunca testado é uma hipótese, não uma proteção. O roteiro trimestral está abaixo
- Custo total — licenças ou GB, mais o tempo de quem opera e testa. Compare com o custo de não recuperar: o dia parado paga muitos meses de backup
Como decidir — e como confirmar que decidiu bem
A árvore, simplificada ao essencial:
- 1. Há obrigação legal ou contratual (retenção de anos, cópias independentes, prazos de restauro)? → retenção Purview para preservar + backup que cumpra a letra do requisito — leia-o antes de escolher a ferramenta
- 2. Sem obrigação, mas há dados cuja perda de meses seria grave (projetos, contabilidade, ficheiros de clientes)? → as janelas nativas não chegam; Microsoft 365 Backup ou terceiro, decidido pelos critérios acima
- 3. Nenhum dos anteriores? → o nativo pode chegar — mas transforme «achamos que chega» em política: janelas documentadas, retenção do Exchange subida para 30 dias, offboarding escrito, e o teste trimestral na agenda
E o teste de restauro trimestral — meia hora que vale mais do que qualquer avaliação de fornecedores. O roteiro que uso: escolha um ficheiro eliminado há mais de uma semana e recupere-o da reciclagem; reponha uma versão anterior de um documento em uso; numa conta OneDrive ou biblioteca criada especificamente para testes, faça alterações controladas e use o Files Restore para repor toda a localização num ponto de há dois dias — confirme o resultado e teste também a reversão da operação (não execute este ensaio numa localização de produção sem avaliar todas as alterações que serão revertidas: o Files Restore reverte tudo, não uma pasta à escolha); se tiver backup, restaure um item de há três meses para um destino alternativo. Registe quatro coisas — quem fez, quanto demorou, o que falhou, o que ficou por saber fazer — e guarde a evidência com data. Ao segundo trimestre, este registo é a resposta pronta para o cliente, o auditor ou a seguradora que perguntar «e vocês conseguem recuperar?»; ao primeiro incidente real, é a diferença entre executar e improvisar. O nosso guia de segurança dos primeiros 30 dias põe esta rotina no calendário ao lado das restantes, e o guia de implementação trata as decisões de retenção no momento certo — antes de haver dados a perder.
Antes de concluir que a proteção atual chega: faça um teste de restauro documentado esta semana. Se correr bem, ganhou a evidência; se correr mal, descobriu-o num ensaio — que é exatamente onde se quer descobrir.
Fontes e validação
Este artigo baseia-se na documentação oficial da Microsoft, em particular:
- Microsoft 365 Backup — overview (cobertura, janelas, pontos de restauro, preços)
- Restore your OneDrive (Files Restore — janela de 30 dias e limitações)
- Handling ransomware in SharePoint Online
- Recoverable Items folder no Exchange Online (retenção de itens eliminados)
- OneDrive retention and deletion (contas eliminadas e reciclagem)
- Restore data with Microsoft 365 Backup (restauro granular e pontos de restauro)
- Data deletion no SharePoint (cópias de 14 dias após eliminação definitiva)
- Pesquisar dados do Teams (armazenamento das mensagens e eDiscovery)
- Arquivar ou eliminar uma equipa (restauro de equipas eliminadas)
