One checkbox will protect a whole workload in Microsoft 365 Backup. What it bills is not what you see in the usage report

Microsoft bills Microsoft 365 Backup at $0.15 per GB per month of protected content. Their own example: a 1 GB SharePoint site carrying 0.5 GB in its second-stage recycle bin, plus a 1 GB mailbox with a 1 GB online archive, are billed as 3.5 GB. All four figures are real and all four count. The admin centre usage report, which is where almost everybody will look, shows only two of the four.

This matters because of a change reaching production over the next few weeks. It is called Full Workload Backup, it ships under message centre notice MC1387526, and it lets you create one policy covering an entire workload: every SharePoint site, or every OneDrive account, or every Exchange Online mailbox. Three separate checkboxes, one per workload, and each one also picks up objects created later. The notice went out in June, public preview ran through July, and general availability starts rolling out in mid-September with completion expected by mid-October.

One thing before we go on, because the headline invites the wrong alarm: nothing switches itself on. The feature ships available but off, and an administrator turns it on by hand. What changes is not that a surprise invoice appears; it is that ticking the box becomes the comfortable option, and with it the scope of your backup — an architecture and budget decision — turns into something that grows by itself every time somebody creates a site. The checkbox solves a real problem, the March site nobody added to any policy. It also makes it very easy not to measure first.

What exactly gets billed

The billable base, per the pricing page, is the sum of two blocks. The first is the visible size: SharePoint sites and OneDrive accounts as they appear in the usage reports — first-stage recycle bin included — plus the live mailbox and its online archive if used. The second is what is retained so you can recover: the second-stage recycle bin, the site collection one, and the deleted and versioned items the backup holds. That distinction between the two blocks will be needed a couple of sections down.

The example is Microsoft's, quoted verbatim: "if you protect a 1-GB site that has 0.5 GB of data in its second-stage recycle bin, and a 1-GB mailbox that has a 1-GB online archive, then you'll be charged for 3.5 GB of Microsoft 365 Backup usage". It sits on the first screen of the pricing documentation, hidden from nobody. Nor is the ratio in that example a law: it depends on how much online archive and how much recycle bin each tenant accumulates, and there will be cases with far less surcharge and cases with a good deal more.

Microsoft warns its own report is incomplete. The report is what everybody looks at

To estimate the cost, the natural move is to open Usage in the admin centre and look at how much OneDrive, SharePoint and the mailboxes take up. The documentation advises against it in a sentence worth reading whole rather than by its tail: "The admin center provides better growth visualization, but doesn't include the second-stage recycle bin or online archive sizes, and is thus incomplete".

And Microsoft does not stop there: it publishes an Excel pricing calculator, aka.ms/M365BackupCalculator, whose input cell explicitly states that the total should include the size of live data plus the recycle bins and the tenant's mailbox online archives. So the information is there, the tool is there and the warning is there. None of this is small print. What happens is that the usage report opens in two clicks and the calculator has to be downloaded, and that is where it gets decided, in practice, which number somebody walks into a budget meeting with.

The gap in numbers: in the official example, the usage report would have shown you 2 GB — the site and the mailbox — and the bill is 3.5. Seventy-five per cent more than the report shows, not more than you have: that 1 GB online archive is real mail the user sees in their Outlook. The route that does work is PowerShell, and the same page gives it: Get-SPOSite for sites and the first-stage recycle bin, Get-PnPRecycleBinItem -SecondStage for what appears nowhere else, and Get-MailboxStatistics -Identity <user> -Archive for each mailbox's online archive. In a tenant with a few dozen sites that is half a morning; with thousands, the second cmdlet enumerates item by item and you have to connect to each site, so it is a script and a night.

Cleaning up does not lower the bill for a year

This is the detail that breaks the reflex of anyone who has managed a consumption cost, and Microsoft spells it out with an example of its own: if you have a protected 1 GB site, you pay for 1 GB; if you delete content and the site drops to 0.5 GB, next month's bill is still for 1 GB, because the backup retains the deleted content for the recovery window. Only when that window lapses — a year, in the example — does the half gigabyte stop counting.

The same timing trap applies to the lever of pulling things out of the policy. The documentation says that when a site or mailbox is removed from protection, the size it had at the moment of removal keeps being used as a proxy for its live size until the restore points expire. The good side is that from then on it cannot go up. The awkward side is that it does not come down in the quarter when somebody needs it to.

Here we need to be exact about an easy piece of arithmetic to get wrong, and we got it wrong in a first draft of this article. The recovery window does not multiply the bill. It acts only on the second of the two blocks, the deleted and versioned content being retained; live size costs the same at 3 months as at 2 years. In the official example, 3 of the 3.5 GB are live size and only 0.5 depends on the window. Going from 2 years to 3 months does not divide the invoice by eight: it trims the part that depends on how much your content churns, which in some places is negligible and in others is half the bill. Lowering restore point frequency, by contrast, achieves nothing, because the documentation itself says it doesn't materially impact the cost. That leaves one big lever, what you protect, and a smaller one, for how long: 3 months, 6, 1 year or 2 years per policy, with existing policies defaulting to 1 year.

Purview deletes and the backup does not notice

There is a sentence in the documentation worth reading twice: retention and deletion policies — Purview's, for instance — do not affect the backup recovery window, which remains fully isolated from those policies. To survive a malicious deletion that is precisely what you want, that whoever tampers with retention does not touch the copy. In September we wrote about Priority Cleanup, the feature that deletes above retention, and this isolation is its counterweight.

Microsoft does not put it in these words, but the practical consequence is worth seeing coming: if somebody exercises their right to erasure, the deletion you run in Purview does not reach the backup. The only documented way out is offboarding the whole product, which is not a surgical deletion, and which additionally carries a 90-day grace period during which the backups remain recoverable. Microsoft is aware of the tension and mentions it when explaining why it does not block deletion: full immutability has, in their words, the drawback of lacking GDPR control. This is our reading of the consequence, not a legal interpretation. If your organisation has specific compliance obligations, that conversation belongs before the checkbox.

What protects you from a compromised admin

We wrote about the architecture of these copies in August, when we covered that they never leave the Microsoft 365 trust boundary, so here is only what bears on today's subject. The documentation contradicts itself about immutability and both sentences deserve quoting: in one place it says the product follows the definition of immutable storage except for disallowing deletion, and in another that "the backups are immutable unless expressly deleted by the Backup tool admin via product offboarding". The second reads better and says the same as the first, with the exception tucked into the subordinate clause.

What remains as a real control, then, is three things: the 90-day grace period after offboarding, the isolation from Purview, and an email notification to a preset group of admins when somebody takes a potentially harmful action on the tool. That last one deserves a nuance that is rarely mentioned: it arrives as a daily digest, not in real time, and it takes up to twenty individual recipients besides lists and groups. A digest that goes out the next day is good for finding out; for stopping somebody acting this afternoon, it is not. It is worth deciding today who is on that list.

What it does well, with the numbers as published

The product attacks the right problem, which is not having the copy but how long you take to come back, and the backups are made inside the service's own data boundary, without pulling terabytes through a pipe. That said, the restore figures have to be given as they stand, and on the same page they do not entirely agree with each other. For a single site, one section says an express restore point brings back a site under 1 TB in under 20 minutes; a table says 30 minutes for one protection unit; and a footnote says it can run from 10 to 120 minutes depending on size. For bulk restores, the feature table talks about a median rate of 1 to 3 TB per hour and the performance table about up to 250 protection units per hour and up to 2 TB per hour. In Exchange, on the order of 100 to 500 items per mailbox per minute.

Microsoft attaches to those numbers a caveat that is rarely quoted: the ones above 1,000 units come from internal benchmarking with sites averaging 12 GB and mailboxes of around 26,000 items. If your sites weigh five times that, the number is not yours. Even with that discount, they are good figures for a mass recovery scenario, and that deserves saying.

There is another contradiction worth declaring before promising management anything. The feature table marks file-level restore via versions as coming soon, while the performance section of the same page describes the granular folder and file restore option as if it existed, with restores taking "only a couple of mins on average". Until you see it working in your own tenant, do not take it as given. What is clear is the backup unit, which is the whole site or account, and that in Exchange the restore returns items to the same folder or another one inside the user's mailbox. If your scenario is recovering what someone who has since left the company deleted, this is not always the route; we covered the layers underneath when we wrote about Exchange Online's 14 days and 30 GB of recoverable items.

When to tick the box without thinking

If you are a twenty-person company with a tenant of a few hundred gigabytes and no regulated content, tick it and stop reading. At that size all the arithmetic in this article fits inside the rounding error of a phone bill, and the realistic alternative for many companies like that is not a better backup but no backup. We say it knowing it sells us less.

If you have terabytes in SharePoint, mailboxes with online archives, content subject to legal retention periods or a real obligation to keep a copy outside the provider, the order matters: measure with PowerShell or the calculator, choose the window per policy instead of leaving everything on the default year, decide what stays out knowing that leaving the policy takes time to show, and tick the box afterwards. A stretch of boring work at the start can be corrected in minutes; a badly set scope takes twelve months to leave the invoice.

We do not sell Microsoft licences, or anybody's, so it makes no difference to us whether you switch this on. What we do in Backup 365 is the part no checkbox decides: what gets protected, for how long, what stays out, and which copy lives outside the provider when the case calls for it. Then comes the only test that counts, which is restoring for real and timing it. Our last full recovery drill took 14 minutes, and that is an internal figure from a test of ours, not a contractual promise. An untested backup is a lucky charm.

Note on sources

From Microsoft Learn's official Pricing model for Microsoft 365 Backup page (updated 18 August 2026) come: the $0.15 per GB per month list price for protected content; the two-block composition of the billable base; the 3.5 GB example; the example of the site that drops to 0.5 GB and still bills 1 GB for a year; that removing a site or mailbox from the policy uses the size it had at removal as a proxy; that restore point frequency does not materially impact cost; the full sentence about the admin centre ("The admin center provides better growth visualization, but doesn't include the second-stage recycle bin or online archive sizes, and is thus incomplete"); the aka.ms/M365BackupCalculator calculator and the instruction that its total storage field must add live data, recycle bins and online archives; and the three PowerShell cmdlets. From the official Overview of Microsoft 365 Backup page come: restores being free; the 3, 6, 12 and 24-month recovery windows with the one-year default; the restore figures (under 20 minutes for a site smaller than 1 TB with an express restore point, 30 minutes for one protection unit in the performance table, between 10 and 120 minutes in the footnote, 1 to 3 TB per hour in the feature table, up to 250 units and 2 TB per hour in the performance table, 100-500 items per mailbox per minute in Exchange) and the caveat that figures above 1,000 units come from internal benchmarking with sites averaging 12 GB and mailboxes of around 26,000 items; the coming soon label on version-based file restore against the section describing granular folder and file restore, a contradiction we point out ourselves; Exchange restoring to the same or another folder within the user's mailbox; the two sentences on immutability ("follows that definition except for disallowing deletion" and "The backups are immutable unless expressly deleted by the Backup tool admin via product offboarding"); the 90-day grace period; the isolation from Purview policies; and that data does not leave the Microsoft 365 trust boundary. That the multi-admin notification arrives as a daily digest and takes up to twenty individual recipients besides lists and groups comes from the Microsoft 365 Backup setup documentation and notice MC1102791. The Full Workload Backup details — notice MC1387526 published in June 2026, public preview in July, one policy per workload, automatic protection of eligible objects not covered by another policy including those created later, custom policies taking precedence, available but off until an admin enables it, general availability from mid-September with completion expected by mid-October 2026 — come from the message centre notice itself as reproduced by public Microsoft 365 change round-ups; we have not consulted a tenant's message centre. Spanish and Catalan quotations are our own translations from the English original; where the nuance depended on the exact wording we left the original. The mention of the right to erasure is our reading of the practical consequence of that isolation, not a legal interpretation or legal advice. The 14-minute figure is from an internal everyWAN drill and we give it as such. The cover photograph is by The National Archives (UK), published on Wikimedia Commons under a CC BY 3.0 licence.