M365 Backup18 Aug 2026 · 7 min read

"We Back Up Microsoft 365" Is Not a Specification

The covered list is marketing. The not-covered list is where your restore fails

By Kapardyn Engineering

Microsoft 365 is not one thing. It is a set of workloads with different APIs, different data models and — critically for backup — different levels of vendor support. "We back up Microsoft 365" is a category, not a specification.

The gap between those two shows up exactly once: during a recovery, when someone asks for something that was never in scope.

Where your clients actually keep things

Mail and files are the easy part, and every vendor covers them. The workloads that hurt to lose are the ones that accumulated quietly.

Teams is where a large share of decisions now happen, and it is structurally awkward to back up because messages live against a channel or a chat rather than against a user. That distinction is exactly where our restore path splits: channel messages restore back into Teams directly; private one-to-one and group chats are backed up too, but land as export and eDiscovery material rather than a live repost — Microsoft’s Graph API has no way to re-post historical chat history on our behalf. Shared mailboxes are owned by nobody, which is why they fall outside per-user scopes. SharePoint sites grow sideways for years and end up holding the operational memory of a department.

MICROSOFT 365 SCOPE · STATED BOTH WAYS
WorkloadStatusWhy it matters
Exchange Online✓ yesThe part every vendor covers
OneDrive✓ yesPer-user files, usually straightforward
SharePoint sites✓ yesWhere six years of structure lives
Teams channel messages✓ yesChannels, attachments, membership, settings, tabs
Teams private + group chatscapturedBacked up and eDiscovery-exportable; Microsoft Graph has no API to restore chat history back into Teams
Shared mailboxes✓ yesOwned by nobody, missed by most default scopes
Planner boardscapturedBacked up and eDiscovery-exportable; Planner writes are Microsoft-restricted, so restore is export only
SharePoint sub-sites✗ noNot separately handled — verify against your estate
The row marked no is the point of this article — and the two marked captured come with a restore caveat worth reading before you rely on them. A published gap costs less than an implied capability discovered at recovery time.

Why we publish the second list

A gap you know about is a decision. You can put a compensating control against it, exclude it from a client commitment, or accept it. A gap you discover during an incident is none of those things — it is a conversation with a client about why the thing they assumed was protected was not.

This has a commercial cost and we would rather pay it here. Publishing a not-covered list loses some deals to vendors whose list is silent. It also means no client of yours learns the boundary of our scope from us at the worst possible moment.

The question to ask every vendor

Not "what do you cover" — you will get a list. Ask for what they do not cover, in writing, and notice how long it takes to arrive.

Scope and retention are different questions

Scope determines whether an object was ever captured. Retention determines whether the capture still exists when you go looking. A platform can be perfect on one and useless on the other, and buyers routinely evaluate only the first.

The pair of questions worth asking together: is this workload in scope, and for how long is the copy kept? Both answers should come from documentation rather than a call.

More in M365 Backup & Restore →
See what's shipping

Every price we quote is published in full, no form required, on pricing. For what the platform protects, VentraID.