Verificar restauros M365 de OneDrive, SharePoint e Teams

Num restauro M365, o objeto correto, um momento de cópia adequado e um destino aprovado têm de corresponder. Um ficheiro pode ter sido reposto com sucesso e, ainda assim, estar no local errado ou visível às pessoas erradas. Este procedimento acompanha um pedido delimitado até à validação funcional para OneDrive, SharePoint e Teams.

Âmbito e revisão de 29 de outubro de 2026: Trata-se de Sophos Backup and Recovery M365 no modelo disponibilizado pela Rubrik. Os cenários seguintes ajudam a planear e validar a recuperação de cada workload. Não confirmam a disponibilidade geral de opções específicas de destino, substituição ou recuperação. A ajuda do workload e o diálogo apresentado têm de corresponder ao tenant utilizado.

A configuração, a subscrição, a atribuição de SLA e o teste Exchange separado estão em Configurar Sophos Backup & Recovery M365 e verificar um restauro. O procedimento seguinte pressupõe uma cópia de segurança configurada e não amplia permissões Microsoft nem o âmbito contratado do produto.

Delimitar o pedido de restauro

Antes de aceder a um snapshot, registar tenant de origem, subscrição e responsável. Incluir o utilizador ou site afetado, o caminho exato do objeto, o evento de perda ou alteração presumido com fuso horário e o estado pretendido. Num incidente de segurança, acordar com o responsável pelo incidente um momento adequado ainda não comprometido. A cópia mais recente não é automaticamente a correta.

Num piloto, utilizar apenas contas de teste aprovadas e dados inofensivos. backup-pilot@example.invalid, Restore-Pilot-2026-10-29.txt e Restore-Abnahme são exemplos de utilizador de teste, ficheiro e destino de verificação pretendido; não são objetos existentes no tenant. Antes de um pedido real, substituí-los por valores de teste próprios confirmados.

Definir por escrito se os dados são necessários no local original ou separadamente. Não escolher outro utilizador, site ou subscrição de destino apenas porque o assistente o permite. As permissões, a região dos dados e a responsabilidade pelo destino fazem parte da mesma aprovação.

Esclarecer conflitos de ficheiros antes da escrita

O destino pode conter ficheiros com o mesmo nome, edições mais recentes ou documentos bloqueados. Antes de confirmar, deve estar claro se o procedimento concreto substitui, muda o nome, ignora ou cria uma cópia separada. Não deduzir estas variantes a partir de um restauro Exchange. Para OneDrive, por exemplo, a Rubrik distingue resultados bem-sucedidos e parciais e pode indicar objetos com nomes alterados devido a conflitos. Isto não estabelece uma regra geral para todos os workloads.

Se o efeito do modo proposto não for inequívoco, não iniciar o restauro. Esclarecer primeiro a ajuda específica do workload e, se necessário, o caso de suporte. Um restauro in-place aparentemente rápido não deve substituir uma edição atual sem consentimento.

Abrir o snapshot correto e a ajuda do workload

1. Abrir My Products > Backup and Recovery M365 no Sophos Fusion (anteriormente Sophos Central). Após o redirecionamento, verificar a organização Rubrik.
2. Abrir Inventory > SaaS > Microsoft 365. Identificar a subscrição confirmada para o pedido; não adivinhar com base num nome de apresentação semelhante.
3. Verificar o âmbito protegido, a atribuição de SLA e as cópias existentes do objeto afetado. Um estado de integração verde não comprova um snapshot com a versão de ficheiro necessária.
4. Antes de um pedido de escrita, abrir o ícone Help e, no Help Center, a ajuda correspondente ao workload. Para SharePoint, o título documentado é Backup and recovery of SharePoint sites and site collections; para Teams, Teams data recovery. Para OneDrive, procurar no Help Center por OneDrive e pelo percurso de recuperação pretendido.
5. Comparar o momento com o evento e o fuso horário. Verificar o objeto selecionado no snapshot perante origem, caminho e conteúdo esperado. Antes do último passo que escreve dados, voltar a comparar origem, âmbito, destino e comportamento perante conflitos com o pedido aprovado.

As verificações seguintes não substituem a sequência exata de cliques específica do workload. Uma opção documentada para Exchange, como Recover to a new folder, não garante a existência do mesmo diálogo para OneDrive, SharePoint ou Teams. Se a ajuda não corresponder ao procedimento apresentado, parar antes da recuperação e esclarecer a diferença.

OneDrive: comprovar uma versão específica de um ficheiro

Num cenário de teste delimitado, a pessoa autorizada cria um ficheiro de texto inofensivo com nome inequívoco. O conteúdo recebe inicialmente o valor de verificação Alpha. Após um snapshot confirmado, alterar o ficheiro para Bravo e voltar a efetuar a cópia. Registar ambos os momentos e a versão esperada em cada um. Este cenário é um plano de teste, não um resultado já observado no produto.

Para o restauro, escolher deliberadamente o snapshot com Alpha. Antes de iniciar, verificar o utilizador de destino confirmado, o caminho completo e o tratamento do ficheiro Bravo entretanto existente. Se o procedimento escolhido suportar e autorizar uma cópia separada, esta facilita a comparação. Não pressupor esse modo; não avançar se a substituição não estiver esclarecida.

Após o pedido, verificar primeiro a mensagem do trabalho e as contagens de objetos, incluindo avisos, falhas parciais e alterações de nomes. Depois, a pessoa de teste abre o ficheiro efetivamente criado no destino documentado. Deve conter o valor de verificação esperado. Se tiver sido utilizada outra pasta de destino ou outro nome, registar precisamente esse caminho. Um ficheiro inalterado no local antigo não constitui uma prova alternativa.

Verificar também acesso e partilhas: a pessoa prevista deve conseguir abrir o ficheiro; uma conta de teste não autorizada não deve obter novo acesso. A validação de um ficheiro de texto num piloto não comprova o restauro integral de um utilizador nem a preservação de todos os links de partilha ou propriedades.

SharePoint: validar separadamente conteúdo, destino e propriedades

Em SharePoint, o pedido começa pelo URL exato do site. Determinar depois se é necessário um ficheiro, uma pasta, uma biblioteca, uma lista ou uma estrutura mais abrangente. Uma biblioteca com o mesmo nome noutro site é outro destino.

Para o piloto, é adequada uma biblioteca de teste aprovada com um ficheiro pequeno e um valor de verificação previamente registado. Se relevante para a utilização posterior, documentar também um campo de metadados e o grupo de permissões esperado. O snapshot deve conter exatamente estes dados iniciais. Só confirmar o restauro do histórico de versões, estrutura de listas ou permissões individuais se estes fizerem parte do âmbito selecionado e tiverem sido verificados separadamente.

Antes do último passo de escrita, verificar site de destino, âmbito dos objetos e eventuais colisões com conteúdos atuais. Se apenas for necessário um ficheiro, não restaurar preventivamente um site inteiro. Após o trabalho, o responsável verifica conteúdo no destino correto, propriedades previstas e acesso. Um trabalho concluído no portal Rubrik não demonstra que uma aplicação de negócio consegue usar a estrutura restaurada.

Se a estrutura do site diferir entre o snapshot e o presente, verificar expressamente o caminho de origem e a associação ao destino. Perante um destino ausente ou permissões por esclarecer, não criar contas, sites ou funções por tentativa. O pedido deve primeiro definir o percurso de destino suportado e os responsáveis necessários.

Teams: não confundir ficheiros com colaboração

Um pedido de «restaurar Teams» é demasiado impreciso. Deve indicar se são necessárias mensagens, um canal, ficheiros ou outros conteúdos. A Microsoft documenta que os ficheiros dos canais padrão ficam no site SharePoint da equipa; os canais privados e partilhados têm sites próprios. O nome do canal, por si só, não identifica o snapshot correto dos ficheiros.

Para um piloto delimitado, acordar uma equipa de teste aprovada, o tipo de canal e conteúdo de teste inofensivo. Se estiver em causa um ficheiro de canal, registar site SharePoint, biblioteca e ficheiro efetivos e verificá-los segundo o plano de validação SharePoint. Recuperar um ficheiro não confirma o restauro de mensagens do canal, membros, separadores ou da configuração completa de Teams.

Se forem necessárias mensagens ou estruturas de canais, esclarecer antes do restauro, em Teams data recovery, os tipos de objetos e destinos suportados pelo estado concreto da implementação. Documentar separadamente equipa de origem, canal, snapshot e destino. Após o pedido, um membro de teste autorizado verifica o conteúdo necessário em Teams; para ficheiros, continua a ser necessária a verificação adicional do local de armazenamento real. Sem âmbito confirmado e snapshot adequado, não prometer um restauro completo genérico de Teams.

Registar o resultado e terminar o teste

O relatório de validação regista objeto de origem, hora do snapshot com fuso horário, destino, modo escolhido e identificação verificável do trabalho. Incluir contagens de objetos, avisos, alterações de nomes, amostras de conteúdo verificadas, acesso e duração medida. Resultado esperado e resultado efetivamente observado permanecem separados.

Se um pedido mostrar um erro ou uma conclusão ambígua, não repetir imediatamente o mesmo restauro. Esclarecer primeiro no portal e no destino se já foram escritos dados. Mesmo um sucesso parcial pode ter criado ou alterado objetos. Na escalada, indicar origem, momento, destino e mensagem expurgada exatos; não copiar conteúdos de ficheiros, credenciais ou exportações completas para tickets públicos.

Um restauro não tem um botão universal de anulação. Limpar cópias de teste adicionais apenas após a validação e exclusivamente no âmbito de teste acordado. Ficheiros de produção, conteúdos de negócio restaurados ou backups não constituem um «rollback» genérico. Enquanto um conteúdo ou uma permissão necessária não estiver confirmado, o pedido continua aberto, mesmo que o estado técnico do trabalho pareça bem-sucedido.