Key takeaways

  • Retention policies and recycle bins keep deleted items for a limited time. They are not a backup: they do not give you a point-in-time copy of a whole mailbox or site from before an incident.
  • A real test restores a named mailbox, a shared mailbox, a OneDrive and a SharePoint site into a clean location, then checks the content, not just that a job said it finished.
  • Measure three things: how far back you can restore, how long the restore takes, and how much work a person must do by hand. Those turn into your recovery targets.
  • Permissions are the part that fails quietly. Test who can run the restore, who can see the result, and whether shared mailbox and site permissions come back with the data.
  • Large restores run into service throttling, so a restore of many mailboxes takes longer than a single test suggests. Measure with realistic volume.
  • Write down the result, fix what broke, and repeat on a schedule, because the tenant keeps changing.

Why test, and what you are really testing

A backup you have never restored is a belief, not a control. In a Microsoft 365 tenant the belief is often that Microsoft handles it. Microsoft runs the service and keeps it available. Protecting your data from your own mistakes, from a compromised account or from an administrator's bulk deletion is a shared responsibility, and the tools differ in what they can bring back. A restore test finds out which tools you actually have. Our article on backups that restore covers the general design. This one is the Microsoft 365 test.

What native retention covers, and what it does not

Microsoft 365 has several built-in layers. Know each one's limits before you rely on it.

  • Deleted item recovery in Exchange Online. A deleted message goes to Recoverable Items for a limited period, 14 days by default and adjustable to 30. After that it is gone unless a hold applies.
  • SharePoint and OneDrive recycle bins. Deleted files stay in the recycle bins for 93 days in total. A deleted parent such as a library can block restoring a version of a file inside it.
  • Retention policies and labels in Microsoft Purview. These keep a copy of content that is changed or deleted so you can meet legal or policy rules. They are built to preserve records, not to roll a mailbox or site back to how it looked at 9 a.m. yesterday.
  • Version history and file restore in OneDrive and SharePoint. Helpful against ransomware on a file library, but time-limited and file-focused.

Microsoft 365 Backup is a separate Microsoft service that adds point-in-time restore for Exchange mailboxes, OneDrive accounts and SharePoint sites, with configurable recovery windows. Third-party backup tools do similar work and can store copies outside your tenant. Whichever you use, the test below applies. Check the vendor's current documentation for what each one supports, because the feature set changes.

Pick the test scope

Start small enough to finish, but wide enough to find real problems. A good first test includes:

  • One ordinary user mailbox, including a calendar and a folder with many items.
  • One shared mailbox, because it behaves differently from a user mailbox (see below).
  • One user's OneDrive with a folder tree and some large files.
  • One SharePoint site with unique permissions on at least one library.
  • One Microsoft Teams team, if you rely on it, to see what comes back and what does not.

Run it like an incident, not a demo

  • Choose the scenario: a single deleted mailbox folder, a bulk deletion by a compromised account, or ransomware that encrypted a library. Each needs a different restore.
  • Record the start time. Have the person who would do this in a real incident perform it, using the runbook as written, so you test the people and the document too.
  • Restore into a separate location where possible: a test mailbox, a new site. Overwriting production in a test is how you create the incident you were practicing for.
  • Record when data first appears, when it is complete, and how many manual steps were needed.
  • Verify the content. Open items, compare item counts and sizes, check that attachments open, that folder structure survived and that dates and senders are correct.

What to measure

  • Recovery point: how old is the newest copy you can restore from? This is your real data loss window.
  • Recovery time: from decision to usable data. Measure per mailbox and per gigabyte so you can scale it.
  • Completeness: items, versions, permissions and metadata that did not return.
  • Effort: how many hands, how many steps, and whether the person doing it had the access they needed.

Permissions and shared mailboxes

Permissions are where tests fail without anyone noticing. Check these:

  • Who is allowed to start a restore, and is that role protected by multi-factor authentication and kept separate from daily admin accounts? A backup that an attacker with a global admin role can delete is weaker than it looks.
  • Whether a restored mailbox is visible to its owner and to the people who had delegate access (Full Access, Send As, Send on Behalf) before. Delegations may need to be re-created.
  • Shared mailboxes have no sign-in of their own and usually no license, so they may be left out of a backup scope by default. Confirm they are included and that you can restore one.
  • SharePoint restored content: do unique permissions, sharing links and sensitivity labels come back, or only the files?
  • Legal hold, litigation hold and retention settings on the restored items, which may differ from the original.

Throttling and time

Microsoft 365 limits how fast any client can read or write data so that no one tenant harms the service. When an application exceeds a limit, Microsoft Graph returns HTTP 429, Too Many Requests, with a Retry-After header telling the caller how long to wait. Exchange Online and SharePoint have their own limits too. A restore tool or script has to back off and retry, and the total time stretches. The lesson for a test is simple: one mailbox restoring in minutes tells you little about restoring two hundred. Time a batch of realistic size, or ask your backup vendor how they handle throttling and what their published restore throughput is.

After the test

  • Write down the recovery point and recovery time you actually got, and compare them with what the business believes it has.
  • List every gap: items not restored, permissions lost, steps that depended on one person.
  • Fix and re-run the part that failed, not only the part that passed.
  • Schedule the next test, at least yearly and after major tenant changes such as a migration or a new backup tool.
  • Share the one-page result with whoever owns the risk. Insurers and clients increasingly ask whether you have tested restores.

If you want this test run for you, with a written result and a fix list, ask about our Disaster Recovery and Managed IT services. This article is general information and not a promise of any particular recovery outcome.

Sources

This article is general information, not legal, contracting or technical advice for your environment. Retention periods and product features change; check Microsoft's current documentation for your licenses before relying on any figure here. Last reviewed .

Next article

Related reading

Need help with this?

Know how long you can be down, and prove you can come back before the day you must.

Disaster Recovery Planning