How Microsoft 365 Protects Your Data (Hint: It’s Not a Backup)

Recently I’ve presented at a couple of conferences talking about where different types of Microsoft 365 (M365) data are stored in the service. Think Teams chat records, Loop files, meeting transcripts, and so on. The slightly facetious answer I give in the first two minutes is that everything lives in Exchange Online and SharePoint Online. While there are devils in the detail, it’s broadly true.

That got me thinking: when I was an M365 consultant, many customers hadn’t really considered what protections were in place at the service level. Most assumed Microsoft must be doing something but hadn’t looked into what that actually meant.

We often assume that because our data lives in M365, it’s automatically backed up. But that’s not quite the case. What Microsoft provides out of the box is protection, through replication and retention, not backup (unless you pay extra).

And while that might be fine if you understand the limits, it’s risky if you don’t. So let’s dig into what protections M365 gives you out of the box for its two primary services…

Replication: How Microsoft Keeps Your Data Available

First on our hit list is looking at what service-level protections there are to make sure that the data inside M365 services is available, online, and remains uncorrupted.

Exchange Online: Built-In Resilience with DAGs

Back with the release of Exchange 2010 Microsoft introduced the concept of DAGs (Database Availability Groups). DAGs fundamentally changed how Exchange was architected and provided native, built-in support for multiple data stores where email data was replicated across services and datacentres.

This architecture is still used in Exchange Online today where an M365 mailbox is replicated between multiple datacentres in the same M365 service region. Usually this will be across four datacentres if they exist, and to other regions if that isn’t possible. With DAGs it is possible to have both live and lagged copies of the mailbox data, so of those four copies, three are live and one is lagged. The lagged copy helps provide some redundancy against corruption or full system wide failures.

These lagged copies use log-replay to update themselves so the database itself is seven days out of date, with the logs available to make it current when replayed into the database. Microsoft does make a point that these lagged copies should not be considered as “point in time” backups as they do not have guaranteed service availability, etc.

As well as using DAGs there are a bunch of clever things happening to minimise the risk of lost data for mail in transit, and to identify and protect against data corruption etc.

SharePoint and OneDrive: Dual-Writes and Local Redundancy

With SharePoint Online (and let’s assume OneDrive for Business too as it’s sharing the same storage mechanisms) they aren’t storage solutions like your typical NAS or disk drive that you have on your computer. There are two mechanisms that are used as file storage, first is Blob storage, this is the actual data that is being stored. Any file metadata etc is then stored in an Azure SQL database associated with the file store.

This means that we then have two redundancy mechanisms to consider, first for the blob storage, Microsoft uses Azure storage replication to do a “dual write” process for file changes. This means that as data is written to the primary location a near-real time copy is written into a datacentre in a different region. If there is any sort of error writing this data to either region the operation is aborted and the application can then handle the issue of retrying etc.

At the actual data layer, inside each datacenter Microsoft is using Locally Redundant Storage (LRS) to write the data across multiple disks.

Metadata resiliency comes from the Azure SQL replication where, similar to Exchange, changes are written across multiple copies of the database.

Retention: What Happens When You Hit Delete

As you can see there is a lot of effort that Microsoft has put into making sure each layer of the “stack” has multiple copies and aims to provide protection for full datacenter and  regional service issues in their stack.

But what about deletions, or issues where selected data needs to be recovered? Well that is where retention comes into play.

Exchange: Recoverable Items and Mailbox Lifelines

Exchange has a built-in mechanism with the deleted items folder, when items are removed from here, they go into the “Recoverable Items” store where they will remain for a further 14 days before being purged. Note that you can extend this to 30 days.

Whole mailbox deletion is covered by the service only performing a soft delete, where the mailbox can be recovered for up to 30 days.

After this period any deleted items, in the mailbox, or the mailbox itself are gone.

SharePoint and OneDrive: Recycle Bins and Version History

SharePoint Online and OneDrive for Business will allow the restoring of deleted files for up to 93 days after deletion. They are either kept in the site recycle bin, or the site collection recycle bin depending on how they were deleted. The only way to keep deleted data beyond this point is to archive it somewhere externally, or by setting a retention policy but this would need licensing for the Purview suite.

Both of these services also offer version history for office files (configurable, but 500 as a default) too. Again this isn’t something that should be relied on for restoring data.

If you find that data has expired past the 93 days it can be worth contacting Microsoft via support as they do have emergency access for another 14 days to be able to restore content.

So… Is That a Backup?

Hopefully you now have a better understanding of what Microsoft does behind the scenes to make sure that the data kept in their services is protected, both against datacenter issues (replication) and user error (retention).

However, this isn’t the same as providing backups. Replication and retention are powerful tools for maintaining availability and recovering from short-term issues, but they’re not designed to protect against long-term data loss, accidental deletions beyond retention windows, or ransomware.

Now that you understand what M365 does and doesn’t do to protect your data, it’s a good time to review your current backup strategy. Are you relying solely on what’s built in? If so, it might be time to explore third-party backup solutions or revisit your risk posture to ensure your data protection strategy is truly complete.

To find out how Cove Data Protection can help you with your Microsoft 365 backup requirements, click here

Ben Lee is a Head Nerd at N‑able and has a long history working in the Microsoft space. You can find him on LinkedIn as BenLeeUK or email him at [email protected]