A nuvem da Microsoft mantém o serviço de pé; ela não devolve o que a empresa apagou

Resiliência de infraestrutura é o trabalho que o provedor faz para o serviço não parar: replica dados entre data centers, troca hardware com falha, mantém a disponibilidade. É por isso que o Microsoft 365 raramente perde uma mensagem por defeito de disco. Proteção de dados é outra coisa: é ter uma cópia que a empresa controla, com retenção própria, em local separado, restaurável por item e independente das credenciais que um invasor pode ter. As duas camadas se somam; uma não substitui a outra.

O backup nativo do Microsoft 365 existe e é útil — lixeira, versionamento e políticas de retenção resolvem parte dos acidentes do dia a dia. O problema começa quando a empresa trata essa camada como se fosse backup completo. Ela não é uma cópia independente: vive dentro do mesmo tenant, sob as mesmas contas administrativas e pelo prazo que a configuração vigente define. Quando o incidente foge do acidente corriqueiro, é justamente essa independência que falta.

O que o backup nativo do Microsoft 365 não cobre

Cinco situações aparecem com frequência e não são resolvidas pela camada nativa. Elas não dependem de o provedor falhar; dependem do desenho da proteção.

Comparar as camadas ajuda a enxergar o buraco:

Dimensão	Resiliência nativa do Microsoft 365	Backup independente
O que mantém	O serviço disponível e o dado replicado	Uma cópia histórica dos dados, com retenção própria
Contra o que protege	Falha de hardware, de data center e de plataforma	Erro humano, exclusão, saída de colaborador, ransomware e erro de configuração
Quem tem a credencial	A mesma conta de produção que usa o serviço	Conta separada, com privilégio próprio
Retenção	Definida pela política do serviço contratado	Definida pela empresa, conforme a necessidade do negócio
Restauração	Dentro do que a plataforma oferece e do prazo vigente	Granular: item, caixa, site ou usuário, em ambiente separado
Independência	Dependente do provedor e do tenant	Fora do ambiente principal e das credenciais de produção

Um exemplo corriqueiro mostra a diferença: um analista apaga por engano a pasta compartilhada de contratos. A lixeira nativa resolve se alguém perceber dentro do prazo. Se o erro for percebido três semanas depois, ou se a conta que apagou for a mesma que deveria restaurar, a camada nativa não ajuda — e é aí que a cópia independente deixa de ser redundância e passa a ser o único caminho de volta.

Cópia imutável: o requisito que o ransomware impôs

Ransomware moderno não ataca só o dado: ataca a capacidade de recuperar. O invasor procura o repositório de backup, usa credencial que encontra no ambiente, apaga pontos de restauração e só então cifra a produção. Um backup que o próprio administrador do tenant consegue apagar não é barreira contra esse tipo de ataque — é mais um alvo.

Imutabilidade, no sentido de WORM (write once, read many), significa que a cópia não pode ser alterada nem excluída durante a janela definida — nem pelo administrador, nem pela conta comprometida. O dado continua legível e restaurável; o que fica bloqueado é a alteração e a exclusão. É uma propriedade do repositório e da política, não uma caixa de seleção na tela de configuração.

Para a imutabilidade valer, algumas condições precisam existir juntas:

• Repositório compatível com retenção imutável, e política aplicada sobre a cópia — não só sobre o job.
• Credencial separada da conta que administra o Microsoft 365. Se a mesma identidade abre os dois, a independência é só de nome.
• Janela de retenção maior que o tempo necessário para detectar e responder ao incidente. Uma janela curta demais protege contra o ataque de ontem, não contra o de hoje.
• Procedimento de restauração documentado, porque imutabilidade não impede restaurar: ela impede sobrescrever e apagar.

Cópia imutável não é selo de marketing. Se a conta que administra o tenant também abre o repositório de backup, a cópia não é independente — e o ataque que alcança a produção alcança o backup. Confirme no documento vigente do produto como a retenção é aplicada e teste a restauração antes de considerar o requisito atendido.

Backup não testado não é backup

Job concluído com sucesso diz que o dado saiu do ambiente de origem. Não diz que ele volta, nem que volta utilizável. A diferença entre as duas coisas só aparece no teste de restauração — e é comum o primeiro teste revelar que a política excluiu justamente o que precisava ser recuperado, que a caixa restaurada perdeu permissão ou que o tempo de retorno não cabe na janela combinada com o negócio.

Um teste útil responde a perguntas concretas: consigo restaurar um único item sem tocar no restante da caixa? Consigo restaurar a caixa inteira de um usuário desligado? Consigo voltar uma versão anterior de um arquivo que foi alterado em massa? Consigo restaurar um site do SharePoint sem sobrescrever o site em produção? O tempo que isso leva cabe no que o negócio tolera?

• Restauração por item: prova que a granularidade existe e que a permissão acompanha o dado.
• Caixa de correio completa: prova que o escopo do usuário foi capturado por inteiro, não só as mensagens recentes.
• Site e biblioteca: prova que o conteúdo compartilhado e suas versões estão na cópia.
• Restauração em ambiente separado: prova que o processo não depende de sobrescrever produção para funcionar.
• Registro de tempo e resultado: prova que o teste foi feito e permite comparar com o objetivo definido pelo negócio.

Duas definições do negócio precisam estar escritas antes do teste: RPO, quanto de dado a empresa aceita perder, e RTO, quanto tempo aceita ficar sem o serviço. Sem esses dois números, o teste não tem critério de aprovação — e o backup vira uma promessa sem medida. O teste precisa ser periódico, ter dono e deixar registro. Um teste único na implantação não prova nada seis meses depois, quando o escopo mudou e a política foi ajustada.

Backup não testado não é backup; é esperança com painel verde. O teste de restauração é o único momento em que a empresa descobre se a cópia existe de verdade, se está completa e se volta no tempo que o negócio precisa.

Como dimensionar: workload × armazenamento

Dimensionar backup não é multiplicar o número de funcionários por um valor. O que define o tamanho é o workload — o que entra na cópia — e o armazenamento é consequência do escopo, da retenção e da frequência. Duas empresas com o mesmo número de usuários podem ter volumes muito diferentes se uma usa o e-mail como arquivo morto e a outra usa SharePoint e Teams como repositório principal.

As variáveis que precisam entrar na conta:

• Escopo: quais cargas entram — Exchange, OneDrive, SharePoint, Teams, endpoints e servidores — e quais ficam fora, com o motivo registrado.
• Volume inicial: quanto dado existe hoje em cada carga, incluindo arquivos antigos e caixas inativas.
• Taxa de mudança: quanto muda por dia. É o que define a frequência de cópia e o consumo ao longo do tempo.
• Retenção: por quanto tempo a empresa precisa guardar cada versão, por exigência de negócio ou de contrato.
• Pontos de restauração: quantas versões por dia e por quanto tempo ficam disponíveis para restauração.
• Destino: onde a cópia fica, com qual região, qual conta e qual política de imutabilidade.

A vWare trabalha com o Acronis Cyber Protect Cloud, que reúne backup de Microsoft 365 e de endpoints e servidores na mesma console. A contratação é por workload e por armazenamento, conforme o pacote e o contrato — a composição de pacotes e as capacidades incluídas mudam com o tempo, então a conferência é no documento vigente do fabricante. O ponto prático é que o mesmo console cobre cargas diferentes, o que reduz a chance de uma delas ficar fora do escopo por descuido.

O erro de dimensionamento mais comum é comprar pelo número de usuários e descobrir o volume real depois da primeira cópia. A primeira carga costuma ser maior do que o previsto e pode levar dias; planejar a janela e validar a integridade faz parte do dimensionamento, não da implantação.

Da decisão à rotina: cinco etapas

Backup é processo, não instalação. A sequência abaixo evita os dois extremos: contratar sem escopo e implantar sem teste.

A etapa mais negligenciada é a quarta. Implantação que termina na primeira cópia entrega a sensação de proteção sem a prova de restauração. O teste não é opcional: é o que transforma cópia em backup.

Perguntas frequentes

O backup nativo do Microsoft 365 não basta?

Ele cobre recuperação de curto prazo dentro da política do serviço: lixeira, versionamento e restauração do que a plataforma oferece. Não é cópia independente e não cobre retenção além do prazo, saída de colaborador, exclusão em cascata nem ransomware que alcança a conta. Para esses casos, a camada nativa e o backup de terceiro se somam.

OneDrive e SharePoint já não são backup?

Não. Sincronização replica o estado atual — inclusive a exclusão. Se um arquivo é apagado na pasta compartilhada, ele desaparece para todos os que sincronizam. Backup guarda versões ao longo do tempo, com retenção própria; sincronização guarda o presente.

Cópia imutável impede restaurar?

Não. Imutabilidade bloqueia alteração e exclusão durante a janela definida; a leitura e a restauração continuam disponíveis. O que ela impede é que a conta comprometida apague a cópia antes de a empresa perceber o incidente.

Com que frequência o teste de restauração precisa ser feito?

A frequência é decisão do negócio, ligada ao RPO e ao RTO definidos. O que não pode faltar é dono, escopo e registro. Testar só na implantação não cobre mudança de escopo, alteração de política nem crescimento do volume — e é justamente aí que o restore costuma falhar.

Backup resolve ransomware?

Reduz o impacto quando existe cópia íntegra, imutável e testada, mas não impede o ataque. Ransomware começa por identidade, e-mail ou endpoint; a camada de recuperação é a última linha, não a única. Por isso backup e proteção de endpoint são decisões que se conversam, não que se substituem.

Próximo passo: liste as cargas que precisam de cópia independente — caixas, sites e arquivos —, o prazo que o negócio exige para recuperar um item apagado e quem aprova o teste de restauração. A vWare dimensiona o escopo por workload e armazenamento e confirma, por escrito, o que fica coberto e o que fica fora antes da proposta. Para entender o que a assinatura do Microsoft 365 já inclui, vale ver o guia de planos e riscos do Microsoft 365.