Microsoft 365 Restore Drill and Recovery Runbook

Not in the way most people mean. Microsoft replicates your data for service resilience and gives you recycle bins, versioning, retention policies and holds — but Microsoft's own Microsoft 365 Backup FAQ draws the line clearly: a disaster-recovery copy maintains the current state of your content, not historical versions, and legal holds are optimized for export through eDiscovery rather than mass restore. Point-in-time recovery of a mailbox, a site or an account after an encryption or mass-deletion event is a separate product — Microsoft 365 Backup, or a third-party backup — that you have to turn on and pay for. This service does not sell you that product; it proves whether the one you already have can actually give your data back.

Because the purchase and the recovery are different things, and only one of them has ever been rehearsed at most organizations. Untested restores fail for mundane reasons: the mailbox was never in a policy, the site was created after the last restore point you need, the only person with the backup admin role left in March, the restore lands read-only and nobody knows how to unlock it, or the data class everyone assumed was covered — Teams messages, Loop pages, Planner boards — was never covered at all. A drill converts those from discoveries you make during an incident into findings you fix on a Tuesday, and it produces the evidence an auditor or insurer wants to see.

The drill is designed to be non-destructive and nothing runs before you approve the plan in writing. Wherever the platform offers a safe destination we use it: Microsoft 365 Backup can restore a SharePoint site or OneDrive account to a new URL instead of over the original, and mailbox items into a new dated Recovered Items folder instead of in place. Seeded content for the mass-overwrite scenario goes on a test library we agree together — we never run malware and never execute anything on a user's device. If you want an in-place restore tested because that is what you would really do in an incident, we will run it, but only against an object you nominate in writing and with a rollback and a communication plan agreed first.

Its protected workloads are OneDrive accounts, SharePoint sites and Exchange Online mailbox items — mail, notes, contacts, calendar and tasks. Retention is one year and is not adjustable. Restore points are every 10 minutes: for Exchange across the whole prior year, and for OneDrive and SharePoint for the prior two weeks, then weekly from two to fifty-two weeks. One nuance that matters more than any other: Microsoft's restore documentation puts granular file and folder recovery on a daily restore point for the trailing fourteen days and weekly beyond that, so the 10-minute figure describes a full rollback, not the recovery of one file someone lost this morning. And restore points only exist from the day protection started for that object — the drill checks that date per object rather than trusting the policy summary.

Not with Microsoft's native backup. Microsoft 365 Backup protects OneDrive, SharePoint and Exchange Online mailbox items; Teams chat and channel messages are not on that list. What is recoverable is the content behind Teams: files in a channel live in the team's SharePoint site and come back when that site is restored, and files shared in a chat live in the sender's OneDrive. Several third-party backup products do capture Teams messages using Microsoft's Teams Export APIs — if yours claims to, that becomes one of the six scenarios and we test it rather than take the datasheet's word for it. Either way, the answer for your tenant is written down in the boundary register so nobody assumes otherwise during an incident.

OneNote notebooks stored in SharePoint or OneDrive travel with the site or account they live in. Planner, Forms and similar services are not protected workloads of Microsoft 365 Backup. Microsoft Loop is the sharpest edge: Loop workspaces are stored in SharePoint Embedded containers, and Microsoft lists the SharePoint Embedded container template among the site types Microsoft 365 Backup does not support — so a deleted Loop workspace is not something the native backup will return. Third-party coverage varies, which is exactly why the register is written per product rather than in general. Where a data class cannot be protected at all, the honest treatment is a business decision recorded in writing, not a gap left implicit.

It will prove precisely what your backup does and does not do with that case, which is often not what people expect. With Microsoft 365 Backup, only mailbox items that were modified, deleted into the Recoverable Items folder or purged are restorable — an item the user moved into their Deleted Items folder is not restored by the backup, because the user can simply move it back. Drafts are never backed up. And a restore only ever lands in the same mailbox: there is no restore into a different mailbox and no export to PST. The drill runs this scenario on a volunteer mailbox so your service desk learns the real decision tree — recycle bin, recoverable items, backup, or eDiscovery — instead of guessing under pressure.

That is the question the drill exists to answer for your tenant, and we will not print a number here that we did not measure in your environment. For orientation, Microsoft publishes its own expectations: roughly 30 minutes for a single OneDrive account or SharePoint site, around two hours for a single mailbox, with mailbox items typically restoring at 200–500 items per minute, and large multi-site recoveries running at published protection-unit and terabyte-per-hour rates. Real numbers move with restore-point type, data volume and how quickly a human decides to press the button — which is frequently the largest term in the equation and the one your runbook can actually shorten.

For Microsoft 365 Backup, Microsoft asks that restores for testing purposes stay at roughly twice a month per protection unit; restores for genuine recovery are not limited. That constraint shapes the engagement honestly: the drill uses a bounded set of named objects rather than sweeping the tenant, and the quarterly calendar rotates scenarios and targets so the programme stays comfortably inside the guidance. If your backup is a third-party product, the equivalent limits are commercial rather than technical — usually storage, restore concurrency or an API throttle — and the plan is sized against your vendor's documented limits instead.

The method is identical: the same scenarios, run in your vendor's console with your vendor's roles, timed the same way. What changes is the boundary register, usually for the better — third-party products often protect Teams chat and channel messages, restore to alternate locations, and export to file, none of which the native product does. We state what your product protects strictly per the vendor's current documentation, cited and dated, and record what the console actually did. Where the two disagree, the report shows both and you have a supportable conversation with your vendor.

Your administrator does the clicking, with our engineer alongside. That is deliberate: the value of a drill is partly the evidence and partly the muscle memory, and muscle memory does not transfer by watching a consultant. For the scope session we want the people who would actually be woken up — the Microsoft 365 admin, whoever owns the service desk, and someone who can speak for the business about what an hour of downtime costs. The readout is for IT leadership. Expect roughly a day of your administrator's time across the week, plus two short meetings for everyone else.

For Microsoft 365 Backup we prefer the dedicated backup admin roles Microsoft provides — the Microsoft 365 Backup Administrator role, or the SharePoint and Exchange Backup Administrator roles — rather than a Global Administrator account, and we will say so if someone offers more. Granular file and folder restore requires the SharePoint Backup Admin role, and one Global Administrator action is worth knowing about in advance: a site restored to a new URL arrives with a read-only lock that only a Global Administrator can remove. For a third-party product, the equivalent console permission is enough. Access is agreed in writing before the drill and removed at the end if you want it removed.

That a named person, on a named date, restored a named workload from a named restore point, in a measured time, with the result checked — and that your organization knows what it cannot recover. It contains the console paths, restore points, operators, timestamps, item counts, fidelity checks, screenshots and the platform's own record of the restore session, which Microsoft retains for 366 days. That is materially stronger than a policy document asserting that backups exist. What it is not is a certification: whether it satisfies a particular framework, questionnaire or policy wording is a judgement for your auditor, broker or counsel, and this page will not pretend otherwise.

The setup service turns Microsoft's native backup on: it configures policies, estimates the consumption charge and validates that restores work for the configuration it just built. This drill assumes a backup already exists — whoever built it, whatever product it is — and asks a harder question: can your people recover, how fast, and what will they never get back? It also goes where the setup service explicitly does not, into Teams recovery expectations and per-workload ownership. The Ransomware Recovery Tabletop and Technical Restore Drill sits alongside rather than underneath: it puts leadership in the room for a timed ransomware scenario and proves one restore on whichever platform holds the data, Azure Backup or Microsoft 365 or a third-party product. This engagement goes narrow and deep instead — six scenarios inside Microsoft 365, an owner per workload, a boundary register and a calendar your team can repeat. The Business Continuity and Disaster Recovery Plan sits above all of it: dependency mapping, downtime costing, leadership-level objectives and a board-ready document. Many organizations run this drill first because it is cheap, fast and produces the facts the other two need.

One Microsoft 365 tenant, up to six agreed restore scenarios, one calendar week, and every deliverable listed above — fixed price, quoted in writing before work begins, payable after you approve delivery. Additional tenants, extra scenarios, a night change window or a larger rehearsal are quoted in writing before anything starts, and the price is fixed once agreed. If the drill's findings turn into remediation work, that is a separate quote from the gap register — and you are entirely free to hand that register to your own team or another provider. The runbook and evidence are yours either way.