Set up Sophos Backup & Recovery M365 and verify a restore

Sophos Backup and Recovery M365 is a cloud-based backup and recovery offering powered by Rubrik for Exchange, OneDrive, SharePoint, and Teams. Its entry point is My Products > Backup and Recovery M365 in Sophos Fusion (formerly Sophos Central); actual configuration and recovery take place in the Rubrik Security Cloud portal. An activated licence or successful redirect does not yet mean the intended data is being backed up.

The safe sequence is to check entitlement and tenant, connect Microsoft 365 to Rubrik, assign backup policies through an SLA Domain, check successful backups, and verify a narrowly scoped restore. The following click path follows Sophos admin help dated 27 May 2026, reread on 27 October 2026. It describes the Rubrik-hosted model and an example Exchange restore, not a universal recovery procedure for every M365 workload.

Clarify the scope, tenant, and permissions first

Before starting, record which Microsoft 365 organisation, users, and workloads need protection. Owners confirm the Sophos Fusion tenant, purchased subscription, and provisioning status. Sophos M365 Backup and Recovery does not support Enterprise Master Licensing. Its licences cannot be shared between sub-estates; separate licences are required for each customer tenant when there are several. Licensing and allocation of the intended Microsoft 365 organisations/subscriptions are confirmed separately before ordering. See Enterprise Master Licensing.

A Microsoft 365 administrator account with the permissions required for the connection is also necessary. General Sophos instructions specify no universal minimum role. Before consent, the actual requested permissions, affected applications, and approving person must therefore be clear. Sophos administrator rights do not replace Microsoft permissions.

Planning also needs a data region, retention requirements, acceptable data loss, and recovery time in the change ticket. The last two are often called RPO and RTO: how old may the recovered copy be, and how long may the service be unavailable? Backup does not replace separately required archiving, eDiscovery, or legal-hold solutions.

Confirm commercial terms before ordering: check minimum quantity, included storage, term, expansion options, and trial and MSP availability against the current quote. Older launch statements do not guarantee today’s terms. The detailed assessment of Sophos Backup & Recovery with Rubrik explains purchasing and architecture questions; this guide focuses on setup and evidence.

1. Connect the Microsoft 365 subscription to Rubrik

1. In Sophos Fusion, open My Products > Backup and Recovery M365. After redirection, check the correct Rubrik organisation and choose Inventory > SaaS > Microsoft 365 > Add Subscription.
2. Continue with Next in Microsoft 365 Setup. Under Grant Rubrik Access to Azure, enter the intended Entra tenant’s domain in Microsoft Entra Domain. It can be found in that tenant’s Entra overview. Sign in to Azure opens sign-in; then choose Add Subscription. Stop if the tenant is unexpected or consent is unclear.
3. Under Azure Configuration, define data placement. Sophos recommends Store data in its original geographic regions; also select the central data location. Check this against your residency plan rather than treating it as confirmation of every privacy requirement.
4. Rubrik generates an Azure key by default. Use your own Azure key is a separate option with Azure Tenant ID, Azure Key Vault ID, and Azure Key Name. Use your own key only with agreed operations, access controls, and recovery procedures. This guide establishes no need to replace existing keys speculatively. Continue the configuration step with Add Subscription.
5. Under Authorize Access to Microsoft 365, perform the intended sign-ins for Exchange, OneDrive, SharePoint, and Teams. Under Grant Access to Microsoft Management App, grant access through Sign in to Microsoft 365 Management app. Check the displayed permissions and tenant each time, then finish Add Subscription.

A connected subscription initially establishes integration. Whether particular data is protected also depends on scope, SLA assignment, and successful backups. Repeating consent for all applications does not resolve a failure in one workload; first isolate the affected step and message.

2. Assign a suitable SLA Domain

An SLA Domain describes the backup policy, particularly backup frequency and retention. It is not simply the email system’s domain or a guaranteed recovery time.

Under Inventory > SaaS > Microsoft 365, click Assign SLA Domain. In Manage Protection, select the intended Microsoft 365 applications and continue with Next. Under Assign an SLA Domain, choose the appropriate existing policy. Sophos documents these defaults:

The general product offering lists up to ten years’ retention and immutable backups. This does not mean a default already configures ten years or the desired immutability. If different values are required, plan a suitable Custom SLA Domain using current Rubrik help and check its actual entitlement and configuration. Default names are not recommendations for every customer.

After Next, check the entire scope and policy under Confirmation, then choose Assign. For an initial pilot, check the intended test objects and their protection status in the portal; selecting applications in the wizard does not prove arbitrarily fine pilot scoping is available.

3. Prove backups work before a restore is needed

Use the following acceptance checks before extending the backup scope. Choose an authorised test mailbox and create a harmless, clearly named test message, such as Backup-Pilot-2026-10-27. It must contain no credentials or company or customer data. Record the expected backup window and recovery point beforehand.

Then check the expected subscription, protection scope, assigned SLA Domain, and successful backup run in the Rubrik portal. Only an available snapshot containing the expected object enables the restore evidence below. A green integration status, configured SLA Domain, or older backup does not prove the new test message was captured.

4. Perform a limited Exchange restore

A restore writes data or creates an export. The target, scope, and approval must therefore be settled before the final Recover. A test mailbox suits a pilot; do not restore a production mailbox in-place as a precaution.

1. Open Inventory > SaaS > Microsoft 365. Under Selected Subscription, choose the confirmed subscription and click Enter Subscription.
2. Under Data Source, select Exchange. Under Username, choose the authorised test user and, under Snapshots, an appropriate time in the calendar.
3. Open the snapshot with Recover. In Exchange Recovery, select Mailbox and continue with Next to folders or messages. Select only the agreed test message; use search if needed.
4. Deliberately select the recovery route. Restore to original user uses the original person; Restore to another user uses someone else. Download from Cloud creates a ZIP export containing one or more PST files; Recover to a different subscription involves a different tenant/subscription context. These variants need different approvals and are not interchangeable test options.
5. In the documented next step, choose between In-place recovery and Recover to a new folder. For the limited test, use a new folder in the confirmed target if offered in the selected workflow. According to help, Recover to a new folder remains in the original region. Check target, region, and scope again before Next.
6. Review the summary and only then confirm Recover. Check job completion and messages in the portal. Together with the responsible test user, verify that the expected message is readable at the correct target. Compare subject, content, and any attachment with the original test object.

The verification report records snapshot time, job ID or traceable job reference, source and target object, scope, outcome, and measured duration. A successful single-message restore does not verify an entire mailbox, SharePoint site, or Teams structure. Plan separate representative tests for those tasks.

For OneDrive files, SharePoint content and Teams data, prepare and accept an M365 restore for further workloads explains source, destination and conflict boundaries through three separate test scenarios. Before restoring, confirm the permissions and suitable snapshot for each workload.

A completed restore has no general undo button. After verification, clean up additional test folders, restored objects, or PST exports only within the agreed test scope and retention policy. Do not delete production messages or snapshots as a supposed rollback.

If sign-in, backup, or recovery fails

Rubrik returns to Fusion sign-in after a session timeout: Sophos lists this as PHISH-11524 in the known-issues directory read on 27 October 2026. It concerns an expired Rubrik SSO session while the Fusion session remains valid. The documented temporary workaround is to sign in to Sophos Fusion again and then reopen Rubrik SSO. This is not a permanent fix or a reason to remove the subscription or broaden permissions.

The subscription is connected but expected snapshots are missing: check tenant, workload, actual protection scope, SLA assignment, backup time, and the specific error separately. Successful backups from another subscription are not substitute evidence.

A restore has no usable result: compare source user, snapshot time, selected message, target, and job message with the ticket. Do not repeatedly trigger the same write operation while its outcome is unclear. First determine whether data has already been recovered.

For detailed help, open the Help icon in the Rubrik portal and search for the exact title, such as Setting up a Microsoft 365 subscription for Rubrik hosting or Recovering email messages to the original location. Sophos notes that direct Rubrik help links may initially require sign-in. Stay within the intended authorised portal workflow; this article assumes no additional sign-in or permission escalation.

For escalation, provide subscription, workload, time and timezone, affected step, sanitised error, and known job reference. Tokens, keys, PST contents, and confidential messages do not belong in a public description. Use the confirmed support case and transfer route as described in Prepare and open a support ticket.