Microsoft 365 backup: what is actually covered

Microsoft 365 backup is not one thing, and that is the source of most of the confusion. Your tenant ships with recycle bins, retention policies and a 30-day drive rollback — short, deletion-shaped windows that were never designed as backup. Separately, Microsoft now sells a first-party Backup add-on that does behave like backup: it protects OneDrive, SharePoint and Exchange Online with a configurable retention period of up to two years, billed on consumption rather than per user. What it does not do is cover every workload, or hold a copy outside your tenant. So the real question is not "is Microsoft 365 backed up" but which of the three layers you are relying on, and what each one leaves on the table.

Layer one: what your tenant already gives you

These are the defaults every Microsoft 365 subscription has. They are genuinely useful for the everyday "I deleted the wrong folder" case, and each has a hard edge.

Native mechanism	Window	Shape of the limit
OneDrive / SharePoint recycle bin (two stages)	93 days from the original deletion	The two stages split one window, they do not grant two
OneDrive Files Restore	Any point in the last 30 days	All-or-nothing rollback of an entire drive, manual
Exchange deleted item retention	14 days by default, raisable to 30	Applies to items a user hard-deleted
Soft-deleted mailbox	30 days	Then the mailbox is unrecoverable
Deleted team or channel	Around 30 days	Chat messages have no self-service restore path

Three properties are common to all of them. They count from the deletion, not from the moment anyone notices. They handle deletions, not files encrypted or overwritten in place. And they are per-item interactions, not designed for restoring thousands of objects with permissions and structure intact.

The mechanics matter more than the numbers, and we have covered them workload by workload: the OneDrive and SharePoint recycle bin and why 93 days is often much less in practice, Exchange Online mailbox recovery and its three separate clocks, and where Teams data actually lives — which is not in Teams at all.

Retention policies are not in this table on purpose. A Purview retention policy stops data being removed before a date you choose. That is preservation, and retrieval runs through an eDiscovery search and export rather than a restore. It answers a compliance question, not an availability one — the distinction we unpack in the SaaS shared responsibility model.

Layer two: the Microsoft 365 Backup add-on

Microsoft 365 Backup is a first-party product, and any honest discussion of Office 365 backup in 2026 has to start with it rather than pretend the only options are native windows or third-party tools. Per Microsoft's documentation, the essentials are:

• Coverage: SharePoint sites, OneDrive accounts and Exchange Online mailboxes — all or a selected subset.
• Retention: configurable per backup policy at 3 months, 6 months, 1 year or 2 years, for each of the three workloads. Existing policies default to 1 year.
• Recovery points: ten-minute restore points for the preceding two weeks, then weekly snapshots from weeks 2 to 52 for OneDrive and SharePoint. Exchange Online keeps ten-minute points across the full 52 weeks.
• Restore shape: full site or OneDrive rollback to a prior point in time, and full or item-level mailbox restores for modified or deleted items. Microsoft lists file-level restore via versions for SharePoint and OneDrive as coming soon.
• Speed: the headline benefit, because backups and restores happen inside the service rather than copying data across a network from a remote location.
• Billing: pay-as-you-go on consumption, not per-user licensing.

If your requirement is "recover fast from a large-scale deletion or encryption event in those three workloads, within the last two years", this is a serious option and it is fair to say Microsoft closed a real gap by shipping it.

What the add-on still leaves to you

Four things, all of them documented rather than inferred.

Workload coverage stops at three. Microsoft's feature summary lists OneDrive, SharePoint and Exchange Online. Teams, Groups, Planner and OneNote are not listed as protected workloads. Teams files live in SharePoint and OneDrive, so those are covered indirectly — but chat has no documented restore path, and a Planner plan or a OneNote notebook is not something you can point the add-on at.

Retention stops at two years. There is a dial — 3 months, 6 months, 1 year or 2 years — but it stops turning at two, and a policy left alone sits at one. That is far better than 93 days and still a fixed ceiling. If your sector expects seven years of recoverable records, or a dispute surfaces evidence from 2021, two years is the wrong number.

Every copy stays inside the tenant boundary. Microsoft is explicit that data never leaves the Microsoft 365 data trust boundary. That is a feature for data-residency and speed, and a constraint for isolation: your backup shares its fate with the tenant it protects. A compromise of tenant administration, or a subscription lapse, does not leave you an independent copy somewhere else.

Append-only is not the same as immutable. Microsoft states the backups use append-only storage so they cannot be modified or overwritten, but that deletion is deliberately not blocked — with a fixed 90-day grace period to recover backups after offboarding, plus multi-admin notifications as a partial guard. Read the documentation and this is stated plainly; read a marketing summary and you would assume immutability.

So which layer do you actually need?

The useful way to decide is to write down four numbers before you look at any product:

1. How far back must you be able to restore? If the honest answer is more than two years, both layer one and layer two are ruled out on their own.
2. Which workloads carry real risk? If your organisation runs its work in Teams channels and Planner, three-workload coverage is a partial answer.
3. How independent must the copy be? Ask what happens if the tenant itself is the problem — administrative compromise, a malicious insider with global admin, a lapsed subscription.
4. What granularity does a restore need? Rolling a whole site back to Tuesday also discards everything legitimate done since Tuesday. Whether you can restore one file, one mailbox item or one folder without collateral damage is a design question, not a detail.

A fifth, and the one most often skipped: when did you last actually test a restore? An untested backup is an assumption, whichever layer it lives in. If ransomware is the scenario you are sizing for, our Microsoft 365 ransomware recovery walkthrough sets out what the timeline looks like from inside an incident — detection lag, not backup existence, is usually what determines the outcome.

Where we fit

We do not run your tenant and we do not sell you a one-size answer. We help you work through those five questions, choose the solution that fits your workloads, retention obligations and compliance position, and get it deployed with guided onboarding. You own the licence and you operate it afterwards, which is deliberate — getting your own data back should never depend on a phone call to us.

The things worth insisting on, whatever you choose: retention you set rather than inherit, restore granularity down to the item, structure and permissions preserved so restored content is usable, anomaly detection on mass-delete and mass-change activity so the clock starts when something happens rather than when someone complains, and restore logs you can hand to an auditor for NIS2, ISO 27001 or GDPR conversations. Our Microsoft 365 backup and recovery page sets out what that covers workload by workload.

If you cannot currently say which of the three layers would answer a bulk deletion discovered four months late, that is exactly what an assessment is for — a short, practical review of the windows you are relying on today and what a real restore would take.