Does Microsoft 365 Back Up Your Data?

Does Microsoft 365 back up your data?

Short answer: no. Microsoft does not back up your data the way most people imagine. It keeps the service online and protects your tenant against its own hardware and datacentre failures, and it does that part well. But the moment someone deletes your content, or ransomware reaches it, getting that content back becomes your job. Microsoft's own Services Agreement says as much, and recommends you keep your own backup.

The confusion is fair. The data lives in Microsoft's cloud, so it feels reasonable to assume Microsoft is keeping a copy you can roll back to. What Microsoft actually guarantees is that the service stays available and the infrastructure under it is resilient. Whether last Tuesday's version of a mailbox still exists, and whether you can get it back, is a separate question with a separate owner.

Microsoft 365 does include recovery features: recycle bins, recoverable items, version history and retention policies. They are real and they are useful. But they exist to undo recent, obvious mistakes, and most of them run on a clock. None of them is a copy you own and can restore from months later, even if something goes badly wrong inside the tenant.

What Microsoft actually protects: the shared responsibility model

Microsoft is on the hook for the service: keeping it available, replicating it across datacentres, securing it physically, and making sure your tenant does not vanish because a disk failed in a rack somewhere. Microsoft handles that platform-resilience side well, and it matters. What sits on your side of the line is the content itself. Delete a SharePoint site, or let a retention policy quietly age data out, and recovering from it is your job. Microsoft keeps the lights on. It will not rebuild your content for you.

This split has a name, the shared responsibility model, and it is not buried in the fine print as a gotcha. It is how every major cloud platform works. Microsoft secures the platform, and you look after the data you put on it.

What native Microsoft 365 recovery actually does (and its time limits)

Go through the native tools one by one and the same pattern keeps showing up. Each one buys you a limited window to undo a recent mistake, and then the option is gone.

In Exchange Online, deleted email lands in recoverable items and can be brought back for a set period. Deleted-items retention and single-item recovery stretch that a little. A deleted mailbox is kept for a limited default window, which varies by configuration, before it is purged for good. You can preserve things longer with a retention policy or a litigation hold, but only if you set one up beforehand.

In OneDrive and SharePoint, a deleted file passes through a first-stage and then a second-stage recycle bin for a limited number of days, version history keeps recent edits, and a departed user's OneDrive is retained for a window you can configure. The exact day counts depend on the workload and your settings, which is why memorising a number and treating it as guaranteed is a mistake.

Every one of these is operational recovery: a safety net for the 'I deleted that an hour ago' moment. None of it will bring a whole mailbox or site back from a year ago. It earns its place on a bad morning, and it is worth having, but it does not do the job a backup does.

Retention policies aren't backups

Microsoft Purview retention deserves credit. For compliance and legal holds it does a real job, and it stops data being destroyed too early. But preserving data under a policy is a different thing from holding a restorable copy you control. You cannot browse retention like a backup catalogue and pull yesterday's mailbox back in a couple of clicks. Retention is also fiddly to configure, and that cuts both ways. A misconfigured retention or deletion policy is one of the most common causes of permanent loss, because it deletes the version you needed on schedule, exactly as it was told to. Treat retention as one useful layer. It does not replace a backup.

What about the Microsoft 365 Backup product?

Microsoft now sells one, and it is worth understanding before you assume it closes the gap. The first-party Microsoft 365 Backup product became generally available in 2024 and covers Exchange, OneDrive and SharePoint. Because it restores inside the platform, recovery is fast and works at scale. You are not dragging terabytes back across the internet, and the integration is tight. For a large tenant, the speed alone can justify it.

The catch is where the copy lives. It stays inside the same Microsoft 365 trust boundary as the data it protects, so it is exposed to the very tenant you are trying to insure. Retention is capped at around a year under Microsoft's published limits, which is short for anyone with multi-year legal or record-keeping obligations. It is billed per gigabyte, so the cost climbs as your data grows. The product lowers real risk, especially for fast recovery inside the platform. What it does not give you is an independent copy that lives outside the tenant and stays under your control.

Risks native Microsoft 365 recovery misses

Native recovery is built for fast, visible mistakes. It struggles with the slow, quiet ones, which are the failures that actually cost people their data.

• Offboarding. Someone leaves, you remove their licence to stop paying for an unused seat, and the retention clock on their mailbox and OneDrive starts running. Months later, finance needs an old contract or invoice thread from that account, and the window has already closed.
• Long-dwell ransomware. A strain gets in and waits weeks before it triggers, encrypting cloud-synced files as it spreads. By the time anyone notices, the last clean version has aged out of version history and the recycle bin.
• Malicious or accidental mass deletion, including by someone with admin rights, that native tools cannot undo once the window has passed.
• Retention misconfiguration that deletes the exact version you needed, on schedule and without warning.
• Teams. Chats live in back-end Exchange mailboxes and files live in SharePoint, so Teams data is scattered across stores, which makes consistent native recovery harder than it looks.

The 3-2-1 rule, applied to Microsoft 365

The 3-2-1 rule is older than the cloud and still a useful starting point: keep at least three copies of important data, on two different types of storage, with one copy off-site. The two-media part is largely a hangover from the tape-and-disk era. For something cloud-native like Microsoft 365, the part that actually bites is the off-site requirement, which means keeping at least one copy somewhere independent of Microsoft. Hold your tenant up against it and the result is blunt. Recycle bins, retention, version history, even the first-party Microsoft 365 Backup product: every one of those copies lives inside Microsoft's own boundary. They cover useful ground, but they all fail the same test. If the problem is the tenant itself, a copy that lives inside that tenant is exposed to the same problem.

So the lesson 3-2-1 leaves you with for Microsoft 365 is narrow and practical: keep at least one copy of your data somewhere independent of Microsoft. For cloud data, that single off-platform copy is the whole job. You do not need a sprawl of disks and tapes. The modern phrasing of the rule, 3-2-1-1-0, sharpens it further by adding an immutable copy that ransomware cannot touch, plus a verified restore. That restore half deserves its own attention, and there is a companion piece on how to test if your backups actually work that covers it.

What a real Microsoft 365 backup looks like

Strip out the jargon and the specification is short:

• Independent and off-platform, in a different trust boundary from your tenant.
• Immutable, so the stored copies cannot be altered or encrypted for as long as the retention lock holds.
• Encrypted in transit and at rest with strong, current encryption (for example AES-256).
• Long, controllable retention beyond the native caps, including the data of deleted users kept for as long as your policy says.
• Covers Exchange, OneDrive, SharePoint and Teams together, as a single restorable set.
• Restore-tested on a schedule, so you know it actually comes back.

That last point is the one almost nobody checks. A green 'backup successful' message tells you a job ran. It says nothing about whether the data comes back. Until a backup has been restored and verified, all you really have is a claim that it works. Hold any setup to that standard, your own or a provider's, and ask for a recent date when a restore was last confirmed. That is the test a managed, off-platform Microsoft 365 backup should be able to pass.

So, do you need to back up Microsoft 365?

For almost any organisation keeping real work in Exchange, OneDrive, SharePoint or Teams, the answer is yes. This is not scaremongering. It is the sensible default once you see how the model works. Microsoft hosting your data and Microsoft backing it up for you are two different things, and the space between them is exactly where departing employees, ransomware, mistaken deletions and retention slip-ups quietly do their damage.

If your answer is "our IT person handles that," fair enough. The useful question is not whether they are capable. It is narrower: when did anyone last restore a mailbox or a SharePoint site end to end, and write down the date? Most setups have a backup job running. Very few can answer that question. The gap is rarely about competence. It is that almost nobody has actually checked.