Microsoft 365 Backup and Purview retention both keep old content, and that's where the resemblance ends. Retention decides how long a record must exist and when it may be deleted. Backup lets an administrator put a SharePoint site, a OneDrive or a mailbox back the way it was at an earlier point in time. Learn is explicit that the two don't touch: retention and deletion policies from Purview don't affect the backup recovery window, which stays fully isolated from them.
That isolation is good for recovery. It also means a records owner who has only read the retention schedule doesn't know everything the tenant is keeping.
What Backup keeps, and for how long
From Learn's Microsoft 365 Backup overview and FAQ:
Recovery window. Set per backup policy: 3 months, 6 months, 1 year or 2 years. Existing policies default to 1 year.
Recovery points. For OneDrive and SharePoint, any 10-minute point in the last two weeks, then weekly points back to 52 weeks. For Exchange, 10-minute points across the prior 52 weeks.
Restore types. A full site or OneDrive restore rolls back to the earlier state and overwrites all content and metadata since then. Exchange restores bring back only the modified or deleted items. File-level restore via versions is listed as coming soon.
People and sites that leave. When a user is removed from the policy or deleted from Entra ID, their OneDrive and mailbox backups are kept for one year from when each backup was made. A site removed from the policy keeps its restore points for 52 weeks.
Deleting backups. Backups are append-only, but deletion isn't blocked; offboarding the tool starts a 90-day grace period. A multi-admin notification can tell a preset group when someone takes a potentially harmful action.
Not everything is covered. Group and room mailboxes aren't supported, and neither are a handful of site templates, including SharePoint Embedded containers.
The roadmap also lists backup activity logs as launched (ID 500019): in-product logs of backup policy changes and restore tasks, for monitoring and audit.
Where records and backup collide
Learn's FAQ is clear on why backup exists at all. Versions don't scale for an attacker encrypting thousands of files, and they can run out under the version limits an admin sets; our version history post covered those limits. Legal holds keep data, but they're built for export through eDiscovery, not mass restore.
Two consequences follow, and both are our reading rather than Microsoft's wording.
First, a file deleted on schedule by a Purview retention policy can still sit in restore points until the backup window passes. If your disposition record says "destroyed on 30 June," the honest version adds "and out of backup by" a later date. That later date should be in the schedule, not discovered in an audit.
Second, a full-site rollback puts the site back as it was. Learn doesn't say how a rollback treats items a retention policy deleted after the restore point. Read literally, they come back. Test that on a non-production site before you need it, and decide who may approve a full rollback of a site that holds records. Restoring a site after ransomware is the security lead's call. Bringing back records that were disposed of properly is the records owner's.
Archive state has its own rule. Per the FAQ, a restore doesn't change a site's current archive tier, but each file returns to the tier it had at the restore point. If you've started using archive actions in retention policies, a rollback can make archived files active again, and visible to Copilot again.
The signatures
The records owner adds the backup recovery window to the retention schedule, next to each disposition rule, and signs off any full rollback of a site that holds records. The Backup administrator sets the window per policy, names the multi-admin notification group and limits who may restore. The security lead owns the ransomware runbook that picks the restore point.
Backup is how you get the tenant back. Retention is how you prove what you kept and what you let go. Give each its own owner.
