Microsoft’s terse Roadmap description says the feature allows “longer term retention periods to restore beyond one year.” The more useful operational detail appeared in Message Center notice MC1419799, archived by Merill and republished by several Microsoft 365 administration sites: policies can be set from three months to two years, the existing one-year setting remains the default, and existing policies are not changed automatically.
That last point is easy to overlook. Tenants that do nothing remain on the same 365-day recovery window they had before, even though the Roadmap now describes the capability as launched.
The recovery window is a policy setting, not an automatic upgrade
The new control is applied at the Microsoft 365 Backup policy level. Administrators must select a policy in the Microsoft 365 admin center, use Update recovery window, select the desired period, and save the change. MC1419799 says the setting is available when creating a policy or editing an existing one.
This gives organizations a more realistic choice than the original all-or-nothing one-year model. A tenant protecting short-lived collaboration spaces may choose three or six months, while a finance, healthcare, legal, engineering, or public-sector organization may decide that a longer recovery horizon is warranted. Two years is still far short of the multi-year retention offered by many specialist SaaS backup vendors, but it removes a hard ceiling that made Microsoft 365 Backup unsuitable for some recovery plans.
The Roadmap lists both Preview and General Availability, with Preview availability dated March 2026 and general availability dated August 2026. The Message Center notice described worldwide rollout beginning in late July and completing in early August. In practice, the reliable test is whether the Update recovery window control appears in the tenant’s Microsoft 365 Backup policy interface—not whether the public Roadmap badge says “Launched.”
Microsoft has not published a tenant-by-tenant rollout map, nor has it identified exceptions beyond its Roadmap scope of Worldwide standard multi-tenant environments. Organizations in sovereign clouds should not assume the feature is present simply because they see the global announcement.
Shortening a policy can destroy older backup history
The most important administration consequence is not extending a policy to two years; it is reducing one.
According to the archived MC1419799 notice, lowering an existing recovery window causes backup data older than the newly selected period to be permanently deleted after a grace period. Microsoft has not publicly specified the length or mechanics of that grace period in its general Microsoft Learn documentation. That omission matters because it leaves administrators without a published basis for treating the setting as a reversible cost-control experiment.
A recovery-window reduction should therefore be handled like a data-lifecycle change, with an approval trail and a record of the oldest restore point that may be needed. Before changing a policy from one year to three or six months, backup owners should confirm that no legal, regulatory, investigation, HR, ransomware-recovery, or business-continuity requirement depends on older restore points.
The feature also creates an awkward but necessary split in ownership. Backup administrators may see a shorter recovery window as a way to reduce consumption, while records-management and legal teams may view the same decision as a potential loss of recovery capability. Those teams do not necessarily own the same controls in Microsoft 365.
Microsoft’s existing documentation describes Microsoft 365 Backup retention as governed by the backup policy, rather than by the retention and deletion rules applied to live Microsoft 365 data. That means a Purview retention label, eDiscovery workflow, or legal hold should not be casually treated as a substitute for a Microsoft 365 Backup recovery point—and the new backup policy window should not be mistaken for a records-retention schedule.
Two-year retention does not mean two years of dense restore points
The expanded window changes how far back an administrator can restore. It does not establish that all supported workloads will have the same restore-point frequency over the newly available second year.
Microsoft’s current Restore data in Microsoft 365 Backup documentation still describes the historical schedule only through 365 days. For OneDrive and SharePoint full-account or full-site restores, Microsoft documents restore points every 10 minutes for the prior 14 days, then weekly points from day 15 through day 365. Exchange Online is documented as having 10-minute points for the prior year. Granular file and folder restoration in OneDrive and SharePoint is described as roughly daily in the newest period and weekly further back.
Those published tables stop at the original 365-day boundary. Microsoft has not yet publicly documented whether the second year uses weekly, monthly, or another restore-point cadence for each workload. It also has not clarified whether granular SharePoint and OneDrive recovery will have the same depth of history beyond one year as full site or account restoration.
That documentation gap is more than cosmetic. A policy allowing a two-year recovery window may satisfy a requirement to retain an older recoverable state, while still failing a recovery objective that requires a specific point in time. An administrator seeking a SharePoint version from 17 months ago could have materially fewer choices than one restoring content from 17 days ago, even though both fall inside the policy window.
For now, organizations should verify the actual restore-point picker in a non-production test policy before revising a recovery-point objective or ransomware playbook. The existence of a 24-month policy setting does not prove that a desired date, file version, or mailbox item will be recoverable at the precision the business expects.
Microsoft’s published pricing documentation still reflects the one-year model
The feature arrives with another unresolved issue: Microsoft’s pricing guidance has not caught up.
Microsoft Learn currently lists Microsoft 365 Backup at a $0.15-per-GB-per-month list price for protected content. The billing model counts both the live protected content and certain deleted or versioned content that Backup retains for recovery. The current pricing page uses a 365-day expiration example, explaining that deleted content still contributes to backup consumption until its one-year backup retention period ends.
That old example is directly relevant to the new feature. Retaining deleted and versioned data for up to two years could change the consumption profile for tenants with high document churn, frequent mailbox deletions, large recycle bins, or intensive versioning. But Microsoft has not yet published an updated pricing model, worked examples, or calculator that quantify the effect of a 24-month recovery window.
Administrators should not assume that doubling the recovery window doubles the bill. Protected live data is already billed while it remains in policy, and the cost impact will depend on how much deleted or versioned material must remain recoverable. But neither should they assume that two-year recovery is cost-neutral merely because the current list price is still expressed as GB per month.
The sensible next step is to capture current backup usage and billing, identify workload churn, and test a longer period on a deliberately selected policy before expanding it across the tenant. The Microsoft 365 admin center’s newer pay-as-you-go controls and budget alerts can help monitor that decision, but alerts do not replace a forecast.
The service remains a recovery product, not a long-term archive
Microsoft’s own product positioning separates Microsoft 365 Backup from Microsoft 365 Archive. Backup is designed for protection and restoration of Exchange Online, SharePoint, and OneDrive content; Archive is Microsoft’s separate pay-as-you-go offering for long-term storage and compliance use cases.
The distinction should govern how IT teams use the new control. A two-year Backup recovery window is useful for restoring from accidental deletion, destructive automation, compromised accounts, or ransomware discovered long after the event. It does not turn Backup into a seven-year records repository, preserve every Microsoft 365 workload, or eliminate the need for Purview retention policies, eDiscovery, legal holds, or a third-party backup platform where those are required.
Microsoft 365 Backup also retains workload-specific restore constraints. Microsoft’s current restore guidance says Exchange mailbox content can be restored only to the current mailbox, while OneDrive and SharePoint restores can target original or new URLs depending on the scenario. Tenant renames, tenant moves, and site URL changes are among the OneDrive and SharePoint changes Microsoft says cannot be undone through Backup restore.
The immediate action for Microsoft 365 Backup customers is therefore modest but specific: inventory existing backup policies, confirm which ones remain at the default one-year window, decide whether a longer window has a defined recovery purpose, and treat any reduction as a potential permanent deletion event. Until Microsoft updates its restore-frequency and pricing documentation for the second year, a test restore—not the Roadmap status—is the only reliable proof that the new setting meets an organization’s recovery plan.
