Three mechanisms with three different objectives
In Microsoft 365, backup, retention, and eDiscovery holds can all preserve copies of data, but they answer different questions. Backup restores a usable state after deletion, corruption, or attack. Purview retention applies lifecycle rules. An eDiscovery hold preserves potentially relevant items for an investigation or legal matter.
No mechanism automatically replaces the other two. A seven-year email retention policy does not guarantee fast restoration of an entire mailbox to yesterday’s state. A restorable backup does not prove that required items were preserved under a case with the expected scope and governance. Authorized stakeholders must define legal requirements; this article is not legal advice.
| Mechanism | Primary objective | Trigger | Expected result |
|---|---|---|---|
| Backup | Continuity and recovery | Incident, mistake, corruption, or ransomware | Restore data from an earlier recovery point |
| Purview retention | Lifecycle and compliance | Broad rule or content-level label | Retain, delete, or retain then delete |
| eDiscovery hold | Specific investigation or matter | Approved case, custodians, locations, and queries | Prevent deletion of in-scope data until release |
Recycle bins and version history are not a backup strategy
Exchange, SharePoint, and OneDrive include native recovery mechanisms such as recoverable items, recycle bins, and version history. They help with common mistakes, but their windows, limits, and dependencies differ by service and configuration. Logical deletion, a policy change, or a broad incident can exceed what they restore conveniently.
A backup strategy defines recovery point objective (RPO), recovery time objective (RTO), recovery window, scope, recovery roles, and testing. It also lists exclusions: Entra configuration, applications, groups, settings, conversations, and metadata are not necessarily protected in the same way as mailboxes and files.
What Microsoft 365 Backup actually does
Microsoft 365 Backup protects supported workloads within Microsoft 365 data boundaries and provides restore points for Exchange, SharePoint, and OneDrive according to configured policies. It is designed for fast recovery from accidental or malicious deletion and overwrite. Partners can use Microsoft 365 Backup Storage infrastructure or offer their own architecture; compare actual scope rather than product names.
Recovery window and restore-point frequency are technical backup-policy settings. Purview retention and deletion policies do not change the Microsoft 365 Backup recovery window. Once restored, live data is again governed by applicable retention or deletion policies. Backup and retention are therefore separate control planes.
Billing, eligible licenses, regions, and workloads evolve. Confirm current Microsoft documentation, pay-as-you-go billing, and administrator rights before a pilot. For a third-party product, also document data residency, encryption, service identity, APIs, throttling limits, and exit procedures.
Purview retention governs content in place
A retention policy generally applies to containers or locations—Exchange mailboxes, SharePoint sites, OneDrive accounts, Teams messages, and other supported locations. A retention label applies to an item and can provide more precise treatment, including declaring a record when licensing and the scenario support it.
A rule can retain content, delete it after a period, or retain and then delete it. When a user changes or deletes an item still under retention, Microsoft 365 preserves a copy in the workload’s internal location, such as Recoverable Items or the Preservation Hold Library. That copy supports preservation; it does not necessarily provide the mass-recovery experience of backup.
- Broad policy: common baseline by location, user, group, or eligible adaptive scope.
- Label: item-level exception or treatment, applied manually, by default, or automatically when licensed.
- Record: additional controls; a regulatory record label creates strong constraints and requires formal governance.
Retention principles determine which setting wins
An item can be subject to multiple policies, labels, and holds. You cannot predict the outcome from the friendliest policy name. Microsoft applies retention principles: retention takes precedence over deletion, the longest retention period can win, and explicit deletion takes precedence over implicit deletion when preservation no longer applies.
Use Microsoft’s decision flowchart and test representative items. Record when the period starts—creation, modification, labeling, or an event—because it changes the end date. Account for policy distribution, workload limits, and storage consumed by preserved copies.
eDiscovery hold is scoped to a case
An eDiscovery hold is created in a case to preserve data from specified custodians, locations, or queries. It remains until an authorized person releases it; it is neither a backup timer nor a broad lifecycle policy. Microsoft also distinguishes it from an Exchange retention hold, which temporarily suspends MRM processing in specific scenarios.
Define scope with legal, privacy, and investigation owners. Avoid an excessively broad query just in case: it raises review volume, cost, and exposure. A query that is too narrow can miss relevant data. Record authorization, custodians, sources, dates, query tests, and case changes.
Never release a hold to free storage or delete a user without formal approval. Several mechanisms can preserve the same item; removing one does not guarantee deletion, and Microsoft can apply a delay hold after release.
Inventory before changing anything
Start with Purview policies, rules, distribution status, and labels. The first script is read-only. It requires ExchangeOnlineManagement and an authorized Purview role. Returned properties can vary with policy type and module version; timestamp output in UTC and redact sensitive identifiers.
For Exchange, sample high-risk mailboxes and former-employee mailboxes. LitigationHold, InPlaceHolds, Single Item Recovery, MRM policy, and Purview represent different mechanisms. The second script changes nothing, but access to hold properties should be limited and audited.
# Read-only inventory. Requires ExchangeOnlineManagement and an authorized role.
Connect-IPPSSession
Get-RetentionCompliancePolicy -DistributionDetail |
Select-Object Name,Enabled,Mode,Type,DistributionStatus,
ExchangeLocation,SharePointLocation,OneDriveLocation,TeamsChatLocation
Get-RetentionComplianceRule |
Select-Object Name,Policy,RetentionDuration,RetentionComplianceAction,
ExpirationDateOption,Disabled
Get-ComplianceTag |
Select-Object Name,RetentionAction,RetentionDuration,RetentionType,
IsRecordLabel,Regulatory# Read-only sampling. Replace the fictional mailbox.
Connect-ExchangeOnline
Get-Mailbox user@example.invalid |
Select-Object DisplayName,LitigationHoldEnabled,LitigationHoldDate,
LitigationHoldOwner,RetentionPolicy,RetentionHoldEnabled,
SingleItemRecoveryEnabled,InPlaceHolds
Get-OrganizationConfig |
Select-Object InPlaceHoldsThree incidents show why the layers complement each other
In every scenario, assign recovery, data-governance, and legal-case responsibilities appropriately. Where separation of duties is required, one person should not create a hold, export results, and release it without oversight.
| Scenario | Primary mechanism | Why the others still matter |
|---|---|---|
| A user overwrites thousands of files | Backup and point-in-time recovery | Retention may preserve versions but may not optimize rapid service restoration |
| Internal policy requires deletion after seven years | Purview retention | Backup needs a compatible window; recovery must not permanently defeat authorized deletion |
| An investigation targets five custodians and a date range | eDiscovery hold | Backup supports continuity; broad retention may preserve more but does not replace case scope |
| Employee departure | Offboarding plus a preservation decision | Do not automatically create a permanent archive; decide recoverability, access, and obligations separately |
Licensing, roles, and cost require feature-level validation
Basic retention policies, labels, adaptive scopes, auto-application, Records Management, and eDiscovery do not all carry the same use rights. Rights can also differ for shared or resource mailboxes. Check the Microsoft Purview service description against covered users and features; do not infer that an E3 or E5 label covers the entire scenario.
Microsoft 365 Backup adds its own activation, billing, and role assignments. A partner solution has its own contract, capacity, retention, and exit costs. Price protected storage, growth, restore-point frequency, restores, administrator licenses, networking, and annual exercises.
Apply least privilege: backup administrators for protection and recovery, Data Lifecycle Management or Records Management roles for retention, and eDiscovery Manager or Administrator for cases according to responsibility. Confirm exact role names and capabilities in the tenant portal.
Deploy through a pilot with realistic rollback
First inventory sources, policies, holds, volumes, and owners. Then write a workload matrix with RPO, RTO, retention duration, rationale, restore destination, and approval authority. Pilot one non-critical mailbox, OneDrive account, and SharePoint site with fictional data.
Test deletion, modification, restoration to the original location, and restoration to an alternate location where supported. Measure time, permissions, links, versions, metadata, and the effect of Purview policies after recovery. For Teams, test messages, files, and recordings separately because they span multiple services.
Rolling back a new retention policy means stopping rollout or restoring its previous scope after analysis; immediate policy deletion does not necessarily undo preservation already applied. An eDiscovery hold has no improvised technical rollback: changes and release follow case authorization. For backup, maintain old coverage until the replacement has protected and successfully restored data.
- Exit criteria: complete inventory, named owners, confirmed licensing, successful recovery, and documented actual timing.
- Light quarterly tests and an annual broader recovery exercise with evidence and corrective actions.
- Alerts for protection failures, policy changes, ownerless holds, and expired exceptions.
Build a defensible architecture
A defensible architecture maps business objectives to the right mechanism: backup for recovery, retention for lifecycle, and eDiscovery for targeted preservation. Document uncovered areas and never promise recoverability without executing a restore.
A Microsoft 365 assessment can map data, policies, holds, licensing, privileged accounts, and recovery scenarios. It turns accumulated settings into an operating plan without replacing advice from legal or privacy professionals.
About the author
Marc-Antoine Lambert
Montréal-based senior IT consultant and Team Lead specializing in architecture, cybersecurity, Microsoft infrastructure, networking and business continuity.
Discuss your environment →