SharePoint Backup: What Microsoft 365 Covers and What It Does Not

Updated October 2026

Microsoft has my data, so it is backed up is one of the most common, and most risky, assumptions in IT. Microsoft 365 protects availability and offers genuine recovery features, but native retention is not the same as a SharePoint backup you control. Understanding that distinction is what separates a confident recovery from a very bad surprise.

What native protection covers, and why it is not a SharePoint backup

Two-stage recycle bins, version history and Microsoft Purview retention policies recover most accidental deletions and edits within their retention windows. For everyday mistakes, someone deleted a file, overwrote a document, emptied a folder, they are often genuinely enough on their own.

Each of these built-in features has its own window, set by Microsoft or by your admins:

• Recycle bin: Deleted files and folders move through the site recycle bin and then the second-stage recycle bin, and are kept for 93 days in total from the original deletion before they are permanently removed. Microsoft: restore deleted items from the recycle bin
• Version history: Document libraries keep up to 500 major versions of each file by default, and admins can set different version limits for the organization, a site or a library, so older versions may be removed sooner. Microsoft: version history limits. Our guide to SharePoint version history covers setup and restore steps.
• Deleted sites: A SharePoint admin can restore a deleted site from the SharePoint admin center for 93 days after it is deleted. After that, it is permanently deleted. Microsoft: restore deleted sites

But these are recovery features, not a SharePoint backup in the traditional sense. They have limited, configurable retention windows, and once those windows pass, the data is gone. They also do not give you an independent copy you control outside the platform, which is the very heart of what a real backup provides.

Where native features fall short

Native protection has no true point-in-time restore of an entire site to a specific moment, and its retention windows are finite. Against ransomware that encrypts content, a malicious or compromised admin, or a regulatory requirement to recover data from several years ago, native features alone may not suffice. These are exactly the scenarios a SharePoint backup is designed to cover.

The shared-responsibility model is the key idea. Microsoft is responsible for the availability and resilience of the service; you are responsible for your data and for meeting your own recovery and retention obligations. A SharePoint backup is how you hold up your end of that bargain rather than assuming someone else has.

Microsoft's own backup option: Microsoft 365 Backup

Microsoft now offers its own backup service for this gap. Microsoft 365 Backup is a separately billed, pay-as-you-go service that backs up SharePoint sites, OneDrive accounts and Exchange Online mailboxes. An admin chooses which sites and accounts to protect and can restore that content to an earlier point in time, with restore points kept for up to one year.

It is not one of the built-in features above: it has to be set up and paid for on its own. The backups also stay inside Microsoft's own service boundary, so if your policy calls for a copy held outside Microsoft, you will still need another approach. Check the current scope, retention and restore options on Microsoft Learn before you plan around it.

When to add a third-party SharePoint backup

If you face long retention obligations, meaningful ransomware risk, or a need for granular point-in-time recovery, layer a dedicated Microsoft 365 backup solution over native protection. Match the tool to your actual recovery requirements rather than buying the biggest one; a clear recovery point and recovery time objective tells you what a SharePoint backup actually needs to deliver.

Regulated industries and organizations with strict recovery SLAs almost always need this. If a regulator can ask you to produce data from five years ago, or if a single day of lost content would be a serious incident, native windows are unlikely to be sufficient on their own.

Common misconceptions about cloud data

The biggest misconception is that the cloud removes the need for backup entirely. It does remove the need to manage backup hardware, but the responsibility for your data does not disappear; it simply shifts. Microsoft keeps the service running and resilient, while you remain accountable for recovering from your own mistakes, deletions and security incidents.

A related myth is that retention policies and a backup are the same thing. Retention governs how long content is kept and when it is disposed of for compliance; it is not designed for fast, flexible restore after an incident. Microsoft Purview retention is valuable, but it solves a different problem than recovery does.

Finally, many teams assume a deleted item is recoverable forever. In reality the recycle bins and retention windows are finite, so an item discovered missing months later may already be unrecoverable. Knowing the actual windows prevents that comfortable but false sense of safety.

Build a recovery plan, not just a backup

Tools are only part of the answer. A real recovery plan defines what you must be able to restore, how quickly, and how far back, then chooses protection to meet those targets. Write down your recovery point and recovery time objectives for the content that matters, and let those numbers drive the decision rather than a vendor's feature list.

Decide what is in scope. Not every site needs the same protection: a regulated records library may justify years of point-in-time history, while a transient project site may be fine with native windows. Tiering your protection keeps cost proportional to the value and risk of the content.

Then review the plan periodically. Obligations change, new sites appear, and risk evolves, so a recovery plan that was right last year may have quiet gaps now. A light annual review keeps protection aligned with reality and your team confident it will actually work when needed.

The reassuring news is that getting this right is neither expensive nor complicated for most organizations. A clear-eyed look at your obligations, a sensible tiering of content, and a tested backup where it is genuinely needed gives you recovery you can trust without over-buying protection you will never use.

Choosing a backup solution

When you evaluate a SharePoint backup tool, look at coverage, SharePoint, OneDrive, Teams and Exchange, retention length, restore granularity, and where the backup data is actually stored. The ability to restore a single item, a whole site, or a point in time, quickly and without a support ticket, is what you are really paying for.

Before you compare products, settle these five points:

• What to protect: List the sites, libraries, OneDrive accounts, Teams and mailboxes that matter, and decide which ones need more than the built-in windows.
• Restore granularity: Confirm the tool restores at the level you will need: a single file, a library, a whole site or an earlier point in time.
• How long to keep it: Set retention to match your legal, regulatory and business obligations, not the tool's default.
• Who can restore: Decide who is allowed to run a restore, whether site owners can restore their own content, and how admin access to the backups is protected.
• Testing restores: Schedule regular test restores and record how long they take against your recovery time objective.

Test the restore, not just the backup. A backup you have never restored from is a hope, not a plan. Run a recovery drill so you know the SharePoint backup works and your team knows how to use it before a real incident puts it to the test under pressure.

Match protection to your real risk

Native Microsoft 365 features are a strong first layer, and for many everyday situations they are enough. But they are not a substitute for a SharePoint backup when the stakes are ransomware, long retention or point-in-time recovery. Understand what native protection does and does not cover, weigh it against your obligations and risk, and add a dedicated backup where the gap is real. The goal is not more tools; it is recovery you can actually count on. For help weighing that gap, see our Microsoft 365 security and compliance services.