A Microsoft 365 retention policy and a backup both “keep data,” which is why they get confused — and why the confusion is expensive. Retention keeps data inside the tenant for a defined period, so it cannot be permanently deleted before then. A backup is a separate copy, in storage you control, that you can restore to a point in time. One is an in-place compliance control; the other is a recovery control. You usually need both.
What retention actually does
Retention in Microsoft 365 — recycle bins, retention labels and retention policies, and litigation hold — prevents data from being permanently removed before a window expires. Delete an email under a retention policy and a preserved copy is held where compliance tooling can find it. That is genuinely valuable for regulatory obligations and eDiscovery.
What it is for is preservation and disposition: keep this for seven years, then dispose of it. What it is not for is handing you an arbitrary earlier state of a mailbox or a SharePoint site on demand.
Why retention is not a backup
Four differences decide it. Same failure domain: retained data lives inside the tenant, under the same administrators — a compromised or malicious admin, or a tenant-level problem, reaches it. A backup in storage you own does not share that domain. No point-in-time restore: retention preserves items, it does not reconstruct how a location looked at 9:00 a.m. last Tuesday before a bad change. Granularity and control: backup lets you choose what and when to restore, and where it lands; retention is a preservation rule, not a restore engine. Survivability: lose the tenant, the licence or the account, and in-place retention goes with it; an external copy does not.
Where the two actually meet
This is not retention or backup. Retention answers “can I prove I kept — and then lawfully destroyed — this record?” Backup answers “can I get this data back, as it was, after it is lost or corrupted?” A mature Microsoft 365 posture runs both: native retention for in-place compliance, and an independent backup for recoverable, point-in-time restore.
The one trap to avoid is letting a retention policy stand in for a backup on the org chart. The day you need a clean point-in-time restore is the day you discover a retention policy was never built to give you one.
Setting the two windows
Decide them separately. Retention windows follow your legal and regulatory obligations — how long a record must be kept, and when it must be disposed of. Backup frequency follows your tolerance for data loss: a point-in-time restore returns one of the points you actually captured, so a few captures a day means a tighter recovery point than one. The two numbers are not the same decision, and conflating them under-protects on one axis or the other.