Backup and retention are two of the most frequently conflated terms in enterprise IT. Both involve keeping data for a period of time. But they serve completely different purposes, operate on different technical mechanisms, and solve different problems. Confusing them – as many organizations do – creates compliance risk, recovery failures, and data loss events that could have been prevented.
This post explains what each term actually means, how they differ in practice, and why Microsoft 365 environments need both.
What Is Data Retention?
Data retention is the practice of preserving data for a minimum defined period, typically to satisfy a legal or regulatory requirement. Retention policies say: ‘This data must not be deleted for X years.’
In Microsoft 365, retention policies are configured in the Microsoft Purview compliance center. They can be applied to Exchange Online mailboxes, SharePoint sites, OneDrive accounts, and Teams content. A retention policy can be set to preserve content, delete content after a period, or preserve then delete.
The purpose of retention is compliance. If a regulator, auditor, or court asks you to produce records from three years ago, your retention policy ensures those records were not deleted. If litigation hold is applied to a user’s mailbox, a retention policy ensures that content cannot be purged while the hold is active.
What retention does not do is give you the ability to restore data to a prior state. If you retained all email for three years but need to restore a mailbox to the state it was in on a specific Tuesday in February, your retention policy cannot do that. It was never designed to.
What Is Data Backup?
Data backup is the practice of creating periodic copies of data at specific points in time, so that data can be restored to a known-good state if it is lost, corrupted, or otherwise unavailable.
A backup solution takes scheduled snapshots of your data – daily, hourly, or at whatever interval is defined. Those snapshots are stored independently of the source data. When a recovery event occurs, the administrator can browse available recovery points and restore data to a specific prior state.
The purpose of backup is operational recovery. If a user deletes their entire mailbox, if ransomware encrypts SharePoint content, if a misconfigured script deletes all contacts – backup is how you get the data back.
What backup does not inherently do is satisfy regulatory retention requirements. A backup solution is not designed to produce records for legal discovery in the same way a compliance retention policy is. These are different tools with different interfaces, different legal standing, and different operational purposes.
The Four Key Differences
1. Purpose
Retention: Compliance. Ensuring data is preserved for a minimum period to satisfy legal, regulatory, or organizational policy requirements.
Backup: Recovery. Ensuring data can be restored to a known-good state after a loss or corruption event.
2. Recovery Capability
Retention: Not designed for point-in-time recovery. Content preserved by retention policy exists in-place in its current state. You cannot restore a retained mailbox to the state it was in three months ago using retention tools.
Backup: Specifically designed for point-in-time recovery. Recovery points represent the state of data at a specific moment, and administrators can browse and restore to any available point.
3. What Triggers the Activity
Retention: Triggered by policy rules – a hold is applied, a timer runs, a condition is met. The process is largely automated and passive.
Backup: Triggered by scheduled backup jobs that actively snapshot data and store it externally. Restore is triggered by an administrator in response to a data loss event.
4. Where the Data Lives
Retention: Data remains in-place within the source system (the Microsoft 365 tenant). Retention preserves the data where it is. It does not create a separate copy in an external location.
Backup: Data is copied to an external location, independent of the source system. This is what protects backup data from insider threats, tenant-level events, and ransomware attacks that compromise the source environment.
Why Retention Policies Are Not a Backup Strategy
The distinction matters most in recovery scenarios. Consider the following:
- A ransomware attack encrypts SharePoint content. Retention policies preserved the content, but the preserved content is the encrypted version. There is no clean prior copy to restore from.
- An administrator accidentally deletes a user’s mailbox. The content was retained by policy. But retention does not give the administrator a restore interface – the retained content exists in a compliance-accessible location, not in a restorable mailbox structure.
- A former employee’s mailbox was deleted 45 days ago. The 30-day Exchange deleted item recovery window has passed. Retention policy was never applied to this mailbox. The data is gone.
In all three scenarios, retention failed to provide the recovery capability that backup would have provided. This is not a criticism of retention – it was not designed for these use cases. But treating retention as backup guarantees that these gaps exist.
When You Need Both
Most organizations subject to regulatory requirements need both retention and backup, and they need them configured deliberately for different purposes.
- Retention policy: Ensures that email, files, and Teams content are preserved for the minimum period required by regulation – whether that is 3 years, 7 years, or longer. Managed in Microsoft Purview.
- Backup: Ensures that data can be recovered to a specific prior state if it is lost, corrupted, or destroyed. Managed through a third-party backup solution operating independently of the Microsoft 365 tenant.
The two systems complement each other. Retention satisfies the question ‘can we prove this data was never deleted?’ Backup satisfies the question ‘can we get this data back to the state it was in before the incident?’
What This Means for Microsoft 365 Specifically
Microsoft 365 environments are particularly prone to retention-as-backup confusion because Microsoft’s compliance tools are genuinely sophisticated. Purview, Litigation Hold, eDiscovery – these are powerful features that create the impression of comprehensive data protection.
But Microsoft has been explicit in its service documentation: data protection is a shared responsibility. Microsoft’s retention and compliance tools are built for regulatory compliance. Operational recovery requires a separate backup solution.
For Exchange Online specifically, this means implementing a third-party backup product that takes scheduled snapshots of mailbox content, stores them externally, and provides point-in-time restore capability down to the item level.
ExchangeSavvy Exchange Online Backup provides the point-in-time recovery that Microsoft 365 retention policies cannot – independent, scheduled backups with granular item restore for Exchange Online mailboxes. Visit exchangesavvy.com/exchange-online-backup.
