Microsoft 365 backup and recovery

Microsoft 365 stores your data redundantly across multiple datacentres, but that's not the same thing as backup. Microsoft protects against infrastructure failure; you're still responsible for protecting yourself against your own users, malicious actors, and configuration mistakes. This is the shared responsibility model, and many organisations only learn it the hard way — usually during a ransomware incident or after a departed admin's "cleanup" script.

The distinction matters because the failure modes backup exists for are almost never "Microsoft lost the data." They are: a user (or a sync client) deleting things that aren't noticed for months, an attacker with admin rights purging mailboxes and version histories, ransomware encrypting files through the OneDrive sync client, a retention policy misconfigured to delete instead of retain, or a compliance requirement to produce data from years ago.

What's protected out of the box

• Mailbox retention — Exchange Online keeps deleted items for 14 days by default (configurable to 30) and supports litigation hold to retain everything.
• OneDrive and SharePoint — the recycle bin keeps deleted files for 93 days across its two stages. Files have version history, and OneDrive offers a self-service "restore this library to a point in time within the last 30 days" feature that also exists for SharePoint document libraries — genuinely useful after a ransomware-through-sync event, if you catch it inside the window.
• Teams — chats and channel messages are retained according to Purview retention policies. Files live in SharePoint/OneDrive and follow those rules.
• Purview retention policies — let you define longer retention across workloads (years, indefinitely) for compliance.

These features cover accidental deletion within their windows. They do not give you point-in-time restore of an entire mailbox, site, or tenant, and the windows are short relative to many incidents. Retention is also not backup: it keeps content discoverable for compliance, but recovering "the finance site as it looked on March 3rd" from retention holds is an eDiscovery project, not a restore.

Microsoft 365 Backup

In 2024 Microsoft launched Microsoft 365 Backup, a first-party service for backing up Exchange, OneDrive, and SharePoint within Microsoft's own infrastructure, with restore points and rapid restore at scale — its headline strength is speed on large restores, because the data never leaves Microsoft's estate. It's billed per protected GB (pay-as-you-go through an Azure subscription), which means cost scales with data volume and needs modelling before you protect everything by default.

It's a credible option for many customers, especially those who want backup without leaving the Microsoft estate, and the established backup vendors increasingly build on top of it via the Backup Storage APIs — so "Microsoft 365 Backup underneath, vendor tooling on top" is now a common architecture.

Know its boundaries: coverage is Exchange, OneDrive, and SharePoint. Teams-specific structures (team/channel configuration, Planner, forms, group settings) are not first-class restore targets, and the backups live inside the same tenant and billing relationship they protect.

Third-party SaaS backup

A mature third-party SaaS backup market still exists — Veeam, Druva, Acronis, AvePoint, Barracuda, Keepit, and others. The reasons to use one alongside or instead of Microsoft 365 Backup:

• Longer retention — years instead of months, at a predictable per-user price.
• Off-platform storage — an insurance policy independent of your tenant, your Microsoft billing relationship, and any attacker who gains Global Admin. If a compromised admin can delete your backups, they aren't backups.
• Granular and cross-tenant restore — items, sites, and mailboxes restored to a different location or a different tenant (relevant for mergers, divestitures, and tenant-loss scenarios).
• Broader coverage — Teams structure, Planner, and OneNote with better fidelity than native tooling.

Designing your approach

Work backwards from scenarios, not products. For each of these, decide what your recovery point and recovery time need to be:

1. Single-item loss noticed within weeks → native recycle bins and version history usually suffice.
2. Bulk loss or ransomware noticed within 30 days → native point-in-time library restore, or Microsoft 365 Backup for speed at scale.
3. Loss noticed after months, malicious admin, or compliance-driven recovery → long-retention backup, off-platform for the malicious-admin case.
4. Tenant-level catastrophe (lockout, destructive compromise, botched migration) → off-platform backup plus a documented rebuild plan; this is the scenario native tooling cannot cover by definition.

A sensible default for most organisations: turn on appropriate Purview retention policies, evaluate Microsoft 365 Backup for fast short-to-medium-term recovery, and run at least one off-platform backup for the ransomware and rogue-admin scenarios. Small tenants with low change rates can defensibly run on native protections plus retention alone — but that should be a documented decision someone signed off, not a default nobody examined.

Finally, test restores on a schedule. Restore a mailbox, a site, and a Teams channel's files at least twice a year, time it, and write down what didn't come back cleanly. The only backup that matters is one you've actually recovered from — and the gaps (Planner boards, channel structure, permissions) are far cheaper to discover in a drill than in an incident.