Verify M365 restores for OneDrive, SharePoint and Teams
An M365 recovery must bring together the right object, a suitable backup time and an approved destination. A file can have been written back successfully yet still be in the wrong place or visible to the wrong people. This workflow therefore leads from a bounded request to substantive acceptance for OneDrive, SharePoint and Teams.
Scope and review date, 29 October 2026: This concerns Sophos Backup and Recovery M365 using the Rubrik-hosted deployment model. They confirm no general availability of particular destination, overwrite or recovery options. The specific workload help and displayed dialogue must match the actual tenant.
Sophos Backup & Recovery M365: configure and verify a restore explains setup, subscription, SLA assignment and the separate Exchange test. The following workflow assumes backups are configured and expands neither Microsoft permissions nor the purchased product scope.
Define the recovery request precisely
Before accessing a snapshot, record the source tenant, subscription and owner. Include the affected user or site, exact object path, suspected loss or change event with its time zone, and the required state. During a security incident, agree a suitable point before compromise with the incident owner. The latest backup is then not automatically the right one.
Use only approved test accounts and harmless test data for a pilot. backup-pilot@example.invalid, Restore-Pilot-2026-10-29.txt and Restore-Abnahme are examples of a test user, file and intended verification destination; they are not existing tenant objects. Replace them with confirmed test values before an actual request.
| Request | Precise source | Further points to clarify |
|---|---|---|
| OneDrive file or folder | User and complete path | Destination user, existing objects with the same name, sharing |
| SharePoint content | Site URL, library or list, and object | Scope, metadata, version and permission requirements |
| Teams content | Team, channel and required content type | Channel type, associated site, and separate message and file acceptance |
Record the destination decision in writing: is content required in its original location or separately? A different destination user, site or subscription must not be selected merely because the wizard offers it. Permissions, data region and ownership of the destination belong in the same approval.
Clarify file conflicts before writing
The destination may contain files with the same name, newer edits or locked documents. Before confirmation, establish whether this specific workflow overwrites, renames, skips or creates a separate copy. Do not infer these variants from Exchange restore behaviour. For OneDrive, for example, Rubrik distinguishes successful and partial results and can report objects renamed because of name conflicts. This establishes no general conflict rule for every workload.
If the effect of an offered mode is unclear, do not start a restore yet. Clarify the workload-specific help and, where necessary, the support case first. An apparently quick in-place restore must not replace current edits without consent.
Open the correct snapshot and workload help
- In Sophos Fusion (formerly Sophos Central), open My Products > Backup and Recovery M365. Check the Rubrik organisation after redirection.
- Open Inventory > SaaS > Microsoft 365. Identify the subscription confirmed for the request; do not guess from a similar display name.
- Check the affected object’s protection scope, SLA assignment and available backups. A green integration status does not prove a snapshot contains the required file version.
- Before a write request, open the Help icon and the workload-specific help in the Help Center. The documented SharePoint help title is Backup and recovery of SharePoint sites and site collections; for Teams it is Teams data recovery. For OneDrive, search the Help Center for OneDrive and the intended recovery path.
- Compare the time with the event and time zone. Check the selected snapshot object against its source, path and expected content. Before the final write step, compare source, scope, destination and conflict behaviour with the request again.
The checks below do not replace the precise workload-specific sequence of clicks. An Exchange-documented choice such as Recover to a new folder does not promise the same dialogue for OneDrive, SharePoint or Teams. If the help does not match the offered workflow, stop before recovery and clarify the difference.
OneDrive: verify a specific file version
For a bounded test scenario, the approved tester creates a harmless text file with a unique name. Its content initially contains the verification value Alpha. After a confirmed snapshot, change the file to Bravo and back it up again. Record both times and the expected version at each. This scenario is a test plan, not a product result already observed.
Deliberately choose the snapshot containing Alpha for recovery. Before starting, check the confirmed destination user, complete path and treatment of the existing Bravo file. If the selected workflow supports and authorises a separate copy, that makes comparison easier. Such a mode is not assumed; do not continue when overwrite behaviour is unclear.
After the request, check the job message and object counts first, including warnings, partial failures and renaming. The tester then opens the file actually created at the documented destination. It must contain the expected verification value. If an additional destination folder or different filename was used, record that precise path. An unchanged file in the old location is not substitute evidence.
Also check access and sharing: the intended tester must be able to open the file, while an unauthorised test account must gain no new access as a result. A text file checked in a pilot does not confirm a complete user restore or preservation of every sharing link and file property.
SharePoint: accept content, destination and properties separately
For SharePoint, the request starts with the precise site URL. Then define whether a single file, folder, library, list or more extensive structure is required. A library with the same name in a different site is a different destination.
An approved test library with a small file and a previously recorded verification value suits the pilot. Where relevant to later use, also document a metadata field and the expected permission group. The snapshot must contain this precise starting data. Version history, list structure or individual permissions are confirmed as recovered only when they belong to the chosen scope and have been checked separately.
Before the final write step, check the destination site, object scope and potential collisions with current content. Do not restore an entire site as a precaution when only one file is needed. After the job, the owner checks the content at the correct destination, the intended properties and access. A completed job in the Rubrik portal does not prove a business application can work with the recovered structure.
If the site structure differs between the snapshot and the present, explicitly check the source path and destination mapping. Do not create additional accounts, sites or roles speculatively when a destination is missing or permissions are unclear. First, the request must establish the supported destination path and its required responsibilities.
Teams: distinguish files from collaboration
A request to “restore Teams” is too vague. It must specify whether messages, a channel, files or other content is needed. Microsoft documents that standard-channel files reside in the team’s SharePoint site; private and shared channels have their own sites. A channel name alone is therefore insufficient to identify the right file snapshot.
For a bounded pilot, agree an approved test team, channel type and harmless test content. For a channel file, record the actual SharePoint site, library and file, then check it using the SharePoint acceptance plan. Recovering a file confirms neither recovery of channel messages nor memberships, tabs or the entire Teams configuration.
If messages or channel structures are required, clarify in Teams data recovery which object types and destinations the specific deployment supports before restoring. Document source team, channel, snapshot and destination separately. After the request, an authorised test member checks the required content in Teams; files still require an additional check of their actual storage location. Do not promise a blanket complete Teams recovery without a confirmed scope and suitable snapshot.
Record the result and end the test
The acceptance record captures the source object, snapshot time with time zone, destination, chosen mode and traceable job identity. Include object counts, warnings, renaming, sampled content, access and measured duration. Keep expected result and actually observed result separate.
If a request reports an error or an unclear completion, do not immediately run the same restore again. Establish in the portal and at the destination whether data has already been written. Even partial success can create or change objects. When escalating, provide the precise source, time, destination and sanitised message; do not copy file contents, credentials or complete export files into public tickets.
A restore has no general undo switch. Additional test copies are cleaned up only after acceptance and strictly within the agreed test scope. Production files, recovered business content or backups are not blanket “rollback” material. The request remains open while required content or permissions are unconfirmed, even if the technical job display appears successful.