This question comes up constantly — and Microsoft's own marketing doesn't help clarify it. The short answer is: Microsoft protects its infrastructure, not your data. They have geo-redundancy, uptime SLAs, and disaster recovery for the SharePoint service itself. But if your data gets deleted — by accident, by malice, or by ransomware — Microsoft is not going to restore it for you after the recycle bin empties.
Let's be specific about what exists and what doesn't, because the nuance matters.
What Microsoft Does Provide
SharePoint Online includes two levels of recycle bin. When you delete a file or list item, it goes to the First-Stage Recycle Bin, where it sits for 93 days or until the bin fills up (it's capped at 10% of your storage quota). After that — or if the bin fills — items move to the Second-Stage Site Collection Recycle Bin, shared across all users in the site collection. After 93 days total from the original deletion, the item is permanently removed.
Site collection administrators can also trigger granular site restores from the SharePoint admin center, rolling back a site to a previous state within the last 30 days. This sounds useful until you realize it rolls back the entire site — meaning any work done after the point you're restoring to gets wiped. It's a blunt instrument, not a surgical recovery tool.
Microsoft also maintains their own infrastructure backups for disaster scenarios — if an entire Azure region goes down, they can restore service. But that's for them, not for you. As their own service terms make clear, Microsoft's backups are not available for customer data restoration requests. Their support team will not restore a deleted document library from Microsoft's internal backup.
Where the Gaps Are
The 93-day window is the most obvious gap, but it's not the only one. Version history helps if someone overwrites a file — SharePoint keeps previous versions based on your library settings — but version history doesn't protect against deliberate site deletion, and it can be disabled by site owners. It also doesn't survive the recycle bin purge; once the container is gone, so are the versions.
Ransomware presents a particularly nasty scenario. Modern ransomware that syncs through OneDrive clients can encrypt files locally, and those encrypted versions then sync to SharePoint — overwriting the clean originals. Version history survives here, technically, but if the ransomware runs for several days before detection, it may have overwritten enough versions that the clean version has been pushed off the version limit. Most libraries have a version limit of 500, which sounds like a lot until files are being rewritten rapidly.
There's also the human error scenario that people underestimate: an IT admin running a migration script with a bug, or a SharePoint admin accidentally deleting a site collection that contains a dozen team sites. Those kinds of bulk accidents can exceed the recycle bin's storage cap and trigger automatic purging of older items.
What You Should Be Doing Instead
An independent SharePoint backup captures point-in-time snapshots outside Microsoft's ecosystem. It covers document libraries, list items and their version histories, content types, site structure, and permissions — all stored in your own S3 bucket or on-premise storage. Recovery is granular: you restore a specific file, a specific list item, or a specific version without touching anything else.
The practical difference is control. With native SharePoint tools, you're working within Microsoft's 93-day window, their storage caps, their version limits. With a dedicated backup, you define the retention, you define the restore granularity, and you're not racing a deletion clock during an incident.
To answer the original question directly: no, Microsoft does not back up SharePoint in any meaningful sense of the word as it applies to data recovery. They back up their service. You're responsible for your data.