The Microsoft 365 backup that never leaves Microsoft

For years the line "Microsoft does not do your backups" was enough to end the conversation. Not any more: Microsoft sells its own Microsoft 365 backup, you switch it on from the admin centre and you pay for what you use. So the useful question has moved. It is not whether it exists, it is what exactly it protects you from. And that is written down, with numbers and names, in the product documentation. Including the part where Microsoft explains that its backup storage is not immutable, but append-only.

We read all of it. Before going further, the conflict of interest up front: we provide managed Microsoft 365 backup and we make money if you buy that service from us, so read everything below with an eyebrow raised. The product does its job very well and has a boundary stated in writing. Almost every scare we have seen with Microsoft 365 backups comes from not knowing where that boundary is.

First, what it does well, which is a lot

The numbers in the feature table are good, and it is worth saying so before turning critical. OneDrive and SharePoint get restore points every 10 minutes for the previous two weeks, plus roughly daily "express" points and weekly ones out to 52 weeks. Exchange Online gets 10-minute points across the full 52 weeks. Recovery granularity is the OneDrive account, the SharePoint site, and the individual mail, contact, calendar or task item.

In our view, restore speed is what sets this product apart. Microsoft publishes medians: a site under 1 TB comes back whole in under 20 minutes using an express restore point; in bulk recoveries, up to 250 protection units per hour and on the order of 1 to 3 TB per hour, a figure the large-recovery table lowers to 2 TB per hour; in mailboxes, between 100 and 500 items per minute. Restores are not billed.

Those twenty minutes, mind you, are the page's best-case figure. A few paragraphs down, the performance table gives 30 minutes for a single protection unit with an express restore point, and a footnote widens the range to between 10 and 120 minutes depending on site size. Three numbers for the same operation in the same document: if one of them is going into a recovery plan, use the footnote.

Even with the wider range, pulling those same terabytes over the internet from a third party's vault is a different order of magnitude. Which leaves the question almost nobody asks during the demo: why is it so fast?

The sentence that decides everything else

It sits in the list of architectural takeaways, with no bold type and no warning: "data never leaves the Microsoft 365 data trust boundary" and it honours whatever geographic residency you already have. Only limited metadata travels to Azure — the tenant ID, the site IDs — and only for billing. The backups are created inside the data boundaries of the protected services themselves.

That is where the twenty minutes come from: there is nothing to move. Microsoft 365 Backup works as a time machine inside your tenant, and that architecture has consequences both ways. On the good side, restores no external product can match, because none of them can skip the journey. On the other, a set of situations that fall outside its reach by construction: a locked account, a dispute that cuts off access, an identity incident that leaves you outside your own admin centre, the decision to move to another provider. In any of those, the copy still lives in exactly the system that has stopped answering you, no matter how many restore points it holds.

We work to the old rule: three copies, two media, one off site. Turning on Microsoft 365 Backup adds copies and adds points in time, but it does not add the "off site", which is precisely the leg the rule put there for a reason. It is the same circular dependency we wrote about with the backup server joined to the domain, in different scenery: the system that has to hand your data back needs the system that failed to let you in first.

"Immutable", with an asterisk Microsoft writes itself

This part of the documentation deserves credit for honesty and a very careful read. Microsoft defines immutability as storage that cannot be altered, deleted or overwritten for a set period, and then writes that Backup meets that definition except for disallowing deletion. What it uses is append-only storage: SharePoint and OneDrive blobs can only grow with new content, Exchange items cannot be reached from Outlook, OWA or MFCMAPI, and no process can corrupt older versions.

To be fair to the page, a few lines earlier it says the opposite in short form: "the backups are immutable unless expressly deleted by the Backup tool admin via product offboarding". Both sentences are true. The second is the one to take into the meeting.

Protection against overwriting is therefore real. Deletion is deliberately allowed, so you can offboard and for the control GDPR requires. In its place there are three counterweights, and it helps to see them for what they are: a 90-day grace period after offboarding, which works like a recycle bin for the backups; isolation from Purview retention and deletion policies, which do not touch the backup period; and multi-admin notifications.

Who can switch the backup off

The documentation itself lists the potentially harmful events that trigger an alert, and read in one go they are almost a script: disabling Backup, pausing billing through an issue or an admin action, removing protection units from a policy, offboarding units — that is, deleting backups — pausing a policy, transferring backup controllers between Microsoft and a third party, revoking the controller app, changing the notification list, and enabling or disabling the notifications feature itself. Anyone who has been close to a ransomware incident will recognise the order: the first thing touched is not the data, it is whatever gives it back.

Who can do all that is written down too. The global administrator controls everything; the SharePoint administrator covers OneDrive and SharePoint; the Exchange administrator covers mailboxes. And there is a dedicated role, Microsoft 365 Backup Administrator, that governs the whole tool. That this role exists is the best news in this section, because it allows what we have been asking for in Zero Trust for years: that administering backups should not be a side effect of administering email.

The new dependency: your backup hangs off an Azure subscription

Switching Backup on needs two things: being a SharePoint or global administrator, and a valid Azure subscription with a resource group, a region and an account holding owner or contributor rights. Billing is pay-as-you-go. Anyone who onboarded before 1 April 2026 has it under Org settings and can migrate to the new billing experience; anyone arriving later starts there, with budgets and alerts, and the option to split consumption across several subscriptions by department.

Here something appears that was on nobody's risk map, and the list of harmful events confirms it: "pausing billing due to issues or admin action" is a backup event. An expired card, an Azure subscription someone tidies away in a cost review, a change of account holder on the cloud contract: any of those three pieces of paperwork now touches your ability to recover. It is a real dependency and a perfectly manageable one, provided you write it down where dependencies are managed, and not in the head of whoever set it up.

The price, to keep in your head without commissioning a study: $0.15 per protected GB per month, charged on all protected data rather than on the increment, restores included. A protected terabyte is about $154 a month, roughly $1,840 a year; five terabytes, close to $770 a month (counting a terabyte as 1,024 GB). The figure comes from the documentation table, in dollars and before whatever your contract and currency say. And it climbs on its own, because a tenant's data only grows.

A year is a year

The retention period is one year across all three services. For recovering from a disaster that is more than enough; for a records obligation covering contracts, invoicing, employment files or certifications it falls well short, because those are counted in years. We have found no Microsoft announcement extending that period, so the number you can put in a contract or a procedure today is the one in the table: one.

And no, Purview retention does not fill that gap: it has a different purpose and its rules can delete on inactivity, as we wrote when the last-accessed criterion appeared.

The list of what is covered is short, and it is literal

OneDrive, SharePoint and Exchange Online. That is everything in the table, and the protection units you pick in a policy are just as literal: a OneDrive account, a SharePoint site, a mailbox. Teams does not appear as a workload, as an application or in any other form; what is recoverable is whatever lives in a site, a OneDrive or a mailbox, and only if that site, OneDrive or mailbox is inside a policy. It is worth half an hour of review before declaring a whole tenant protected.

There is also a nuance to restoring that belongs in a conversation with whoever runs the business, not only with whoever administers the tenant. Restoring a SharePoint site or a OneDrive is a rollback to the earlier state that overwrites all content and metadata created since that point. File-version restore, the one that would spare what happened afterwards, is listed as "coming soon" in the feature table itself. Translated into any given Thursday: recovering Monday on a live site means throwing away three days of work, and that is not a signature the technician provides. Which is why we keep insisting on working out RTO and RPO before buying the tool.

How we decide this (and what we get out of it)

With our stake in this already on the table, here is the reasoning first so it can be argued with. Everything above reduces to two scenarios, and they do not compete with each other.

Most of the mid-sized companies we work with have scenario A reasonably covered and scenario B as an assumption. Our job is to turn B from an assumption into a procedure with a number attached, even when the answer turns out to be that what they already have is enough.

When we would not switch it on yet

If nobody has written down what has to be recoverable, in what time, who asks for it and who authorises overwriting three days of work, switching Backup on means paying $0.15 per gigabyte a month for reassurance that has not been defined. The tool takes an afternoon to enable; the procedure and the stopwatch restore test take longer, and they are what tell you whether the tool was needed. And if the Microsoft 365 volume is small and there is already an external copy covering both scenarios, this is optional and there is no harm in saying so.

The question we close these meetings with is always the same, and it is deliberately uncomfortable: if you lose access to the tenant tomorrow — not the files, the access — where do you restore from? If the answer starts with "we log into the admin centre", the backup and the problem live in the same house. That can be a perfectly reasonable decision; what it cannot be is a surprise.

Sources (verified on 17 August 2026): the one-year retention period across OneDrive, SharePoint and Exchange Online, the restore-point cadence (every 10 minutes for the prior two weeks, roughly daily or weekly "express" points, weekly from 2 to 52 weeks; Exchange every 10 minutes across 52 weeks), the median restore figures (a site under 1 TB in under 20 minutes with an express restore point, 1-3 TB/hour, up to 250 protection units per hour, 100-500 items per minute for mailboxes), the price of $0.15 per protected GB per month with free restores, the line "data never leaves the Microsoft 365 data trust boundary", the append-only versus immutable explanation ("Backup follows that definition except for disallowing deletion"), the 90-day grace period after offboarding, isolation from Purview policies, the full-site rollback on restore and file-version restore marked "coming soon", from "Overview of Microsoft 365 Backup" (Microsoft Learn). The setup requirements (an Azure subscription with resource group, region and owner or contributor role; SharePoint or Global Administrator), the new billing experience for onboarding after 1 April 2026 and departmental billing, the list of potentially harmful events — including billing being paused through issues or admin action — notifications sent as a daily digest, the limit of 20 individual recipients plus lists and groups, the exclusion of jobs with a 10-minute RPO, and the role table with the new Microsoft 365 Backup Administrator, from "Set up Microsoft 365 Backup" (Microsoft Learn). We found no Microsoft announcement extending that year, so this post sticks to what is written in the table. The three restore-time figures the same page gives for the same operation (under 20 minutes for a site smaller than 1 TB, 30 minutes for one protection unit with an express restore point, and a 10-to-120-minute range in the footnote) are reported as they stand, as is the difference between the summary table's 1-3 TB per hour and the bulk-recovery table's up to 2 TB per hour. The cost examples ($154/month per TB, $1,840/year, $770/month for 5 TB) are our arithmetic on that list price and exclude tax, currency and contract terms. The reading of the two scenarios, the criticism of the detection window and the role recommendations are ours.