Is Your SharePoint Actually Backed Up? What Microsoft Won't Tell You
Ask your IT team one question: "If somebody deleted our entire SharePoint library tomorrow, how would we get it back?" If the answer sounds anything like "Microsoft handles that," you have a problem.
When Eric Thompson runs an evaluation on a new client's Microsoft 365 environment, this is one of the first things he looks at. He's yet to find one that had a real third-party backup in place for SharePoint, OneDrive, and Teams. Varying degrees of better and worse, but the same underlying gap, every time.
Here's why that matters, what Microsoft actually does and doesn't protect, and what you should do about it.
Microsoft Does Not Back Up Your SharePoint Data
This surprises almost everyone. When you pay for Microsoft 365 licenses, you get access to SharePoint, OneDrive, and Teams. Microsoft's position on your data is explicit: it's your data, you own it, it's your responsibility to protect it. They give you the platform. The rest is on you.
Microsoft provides infrastructure redundancy. If one of their data centers has a hardware failure, your data isn't lost. That's not the same as a backup. If an employee accidentally deletes a folder, if ransomware encrypts your files through a compromised account, or if somebody restructures a SharePoint library and makes a mess of it, Microsoft is not going to restore that for you.
What Microsoft Actually Provides
Microsoft does offer some built-in protections, but they're limited and they're not backup:
Recycle Bin: Deleted SharePoint and OneDrive files live in a recycle bin for up to 93 days total (across the site and site collection recycle bins combined). After that, they're gone. In a large SharePoint environment, deletions regularly go unnoticed inside that window, and once it closes, the data is unrecoverable through Microsoft's native tools.
Version History: SharePoint keeps previous versions of files, which can help if somebody overwrites a document. But version history doesn't protect against bulk deletion, ransomware encryption, or account-level compromise. It's a convenience feature, not a disaster recovery tool.
Retention Policies: These exist primarily for legal and compliance purposes: preserving data so it can be produced in response to a court order or eDiscovery request. That's not the same as backup and restore. You can't use a retention policy to recover from a ransomware event or to roll an accidentally deleted SharePoint site back to yesterday's state.
Microsoft protects their infrastructure. They do not protect your data from your own users, from cyberattacks, or from mistakes.
What Actually Goes Wrong Without SharePoint Backup
We've seen every version of this story.
Accidental deletion and restructuring disasters are the most common. SharePoint is so easy to use that people constantly try to reorganize, move, or clean up their data, and before they realize what happened, files are gone or duplicated across locations. By the time people figure it out, it's a giant mess. Duplicate data, things in two spots, missing libraries, broken links inside Teams. We do a lot of accidental deletion restores for our clients.
The ransomware scenario is worse. We had a client (a corporate entity with branches across the country) where we managed the Minnesota location only. Their New York office housed a lot of the company's data. Somebody at New York got ransomware on their computer. Because that user's account was tied into SharePoint, the compromise translated into the ransomware crippling the whole company's SharePoint database across every location.
They had no backup. Microsoft did nothing for them.
Real client incident, 2024We were able to help them with a limited version history recovery (not from backup, but from the native version history feature) which salvaged some data. They still lost a significant amount. The Minnesota branch was fine because it wasn't tied into the same exposure.
How McNallan Handles SharePoint Backup
Our approach is to treat SharePoint, OneDrive, and Teams data the same way we treat any critical business system: it gets its own dedicated backup, separate from everything else.
We use a Microsoft 365 tenant-integrated backup product called AFI. It covers SharePoint data, Teams data (including messages and channels), and email. Backups run four times per day.
This is separate from our server backup, separate from our file-level backup, and separate from our disaster recovery infrastructure. That's by design. If one backup system is compromised, the others remain intact. A backup that's stored inside the same Microsoft 365 tenant it's supposed to protect is not really a backup. It is a copy in the blast radius.
Air-gapped insurance
For our most critical client environments, our server and DR backups go into immutable storage. Think of it as a digital safety deposit box that even we cannot delete. Rocky has an agreement with Amazon that says: put this over here, and if I come asking for it back, don't listen to me. Even under the worst possible ransom scenario, the last copy is still there because nobody (not an attacker, not a compromised admin, not Rocky himself) can reach in and wipe it.
We've done full SharePoint library restores using our backup tool. We've run simulations where we take a client's entire SharePoint environment offline and restore it, so we know it works before anyone actually needs it, not after. And we've used it in real cyber incidents to get clients back to normal without paying a ransom or starting from scratch.
Three Things to Ask Your IT Team Today
Do we have a third-party backup for SharePoint, OneDrive, and Teams?
If the answer is "Microsoft handles that," it is wrong. You need a dedicated solution that runs independently of your Microsoft 365 tenant.
How often are backups running, and where are they stored?
"We have a backup" is not good enough. You need frequency (our solution runs four times per day) and you need the backup stored outside the Microsoft 365 environment.
Has anyone ever tested a restore?
A backup that has never been restored is not a backup, it's a hope. You should be able to point to a specific date somebody tested restoring SharePoint data and confirmed it worked.
Not sure if your SharePoint is backed up?
Tell us how your M365 tenant is configured today: backup, permissions, MFA, security defaults. We will tell you what is missing.
Get in Touch