Microsoft 365 Backup: What's Covered, Retention Limits, and Setup
Why This Is Happening
Here's a scenario I've watched play out at more organizations than I can count: someone on the team accidentally deletes a SharePoint document library. Not one file , the whole library. Or a disgruntled employee wipes their OneDrive before their last day. Or ransomware crawls through your tenant and encrypts two years of Exchange email in a weekend. And then the IT admin starts asking a question they really should have answered six months ago: "Wait, does Microsoft 365 actually back up our data?"
The honest answer is: sort of, but not in the way you think. Microsoft's built-in versioning and Recycle Bin features are not the same thing as a proper Microsoft 365 Backup solution. They have hard limits, they don't protect against all deletion scenarios, and they won't save you from a coordinated attack. That's exactly why Microsoft released Microsoft 365 Backup as a dedicated product, a paid, policy-driven backup service built natively into the Microsoft 365 admin center.
The confusion I see most often comes from three places. First, admins assume the default 93-day Recycle Bin retention in SharePoint is "good enough." It's not, for enterprise continuity scenarios. Second, people conflate OneDrive file versioning with an actual backup, versions help, but they don't give you a point-in-time rollback of an entire account. Third, the Microsoft 365 Backup product itself is relatively new, and its pricing model ($0.15 per GB per month for protected data) surprises people who've never seen the billing section in the admin center.
Setup problems also trip people up. Common issues include backup policies that look activated but haven't finished processing, restore points that aren't yet visible in the restore tool even though they're being created, and organizations that discover mid-setup that they're in a Government Community Cloud (GCC) tenant, where Microsoft 365 Backup is currently not available.
If you're setting up Microsoft 365 Backup for the first time, trying to understand what the retention limits actually are, or troubleshooting a backup policy configuration error, this guide covers everything grounded in what the product actually does. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If you're specifically here because your backup policy shows as "activated" but you can't see any restore points yet, breathe. This is expected behavior, not a bug.
When you submit a new Microsoft 365 Backup protection policy in the admin center, there are two separate delays you need to account for. First, it takes up to 60 minutes just to process and activate the policy. Then, on top of that, it takes another 60 minutes before actual restore points start appearing in the restore tool. So you're potentially looking at two hours before anything shows up, even though Microsoft's documentation confirms that restore points are being physically created in the service from the moment the policy is confirmed as activated.
For organizations with large numbers of protection units, say, thousands of SharePoint sites or OneDrive accounts, the initial backup processing runs at approximately 15 minutes per 1,000 units. Add that to your wait time estimate accordingly.
Here's the fastest way to verify your policy is genuinely active and not stuck:
- Sign in to the Microsoft 365 admin center at
admin.microsoft.com. - Navigate to Settings > Microsoft 365 Backup in the left sidebar.
- Open your backup policy and check the status column, it should read Active, not Pending or Processing.
- If it reads Active but restore points still aren't showing: wait the full two-hour window before concluding something is wrong.
- If status has been stuck on Pending for more than 90 minutes, that's a real issue, jump to the Advanced Troubleshooting section below.
One more quick check: if you're getting an error that Microsoft 365 Backup simply isn't available in your admin center at all, confirm your tenant type. GCC (Government Community Cloud) tenants are currently excluded from the product entirely, this isn't a licensing gap you can fix, it's a platform availability limitation.
Before you touch the backup policy configuration, confirm you have two things: the right admin role and an active billing relationship for Microsoft 365 Backup. I've seen organizations spend 30 minutes troubleshooting a setup wizard that simply won't proceed, only to find out the account doesn't have Global Admin or Backup Admin privileges assigned.
To check your role assignment, go to Microsoft 365 admin center > Users > Active users, find your account, click it, and look at the Roles tab. You need either Global Administrator or the dedicated Microsoft 365 Backup Administrator role. If neither is present, contact your Global Admin to assign the Backup Administrator role specifically, it's a least-privilege option that doesn't require handing out Global Admin access.
Next, check billing eligibility. Microsoft 365 Backup bills at $0.15 per GB per month for all data actively protected under a backup policy. Restores themselves are free, you only pay for what you're protecting, not for pulling it back. To make sure billing is connected:
# Verify billing account in admin center:
# Settings > Org settings > Services > Microsoft 365 Backup
# OR
# Billing > Products & services > Microsoft 365 BackupIf your tenant is a Government Community Cloud (GCC) organization, stop here, Microsoft 365 Backup is not currently available for GCC tenants regardless of licensing. You'll need to evaluate third-party backup solutions that integrate with Microsoft 365 APIs for now.
When this step is done correctly, you'll be able to navigate to Settings > Microsoft 365 Backup and see the three service tiles: SharePoint, OneDrive, and Exchange. If you see an access-denied error instead, the role assignment hasn't fully propagated yet, wait 15 minutes and try again.
Getting your Microsoft 365 Backup retention policy right starts with understanding exactly what the product protects and, just as importantly, what it doesn't. I want to be direct here because the Microsoft 365 Backup coverage scope surprises a lot of people coming from traditional backup tools.
Microsoft 365 Backup covers three services at the following granularity levels:
- OneDrive: Entire OneDrive accounts (per user). You protect a user's full OneDrive, not individual files or folders.
- SharePoint: Entire SharePoint sites. Again, site-level granularity, not library-level or folder-level.
- Exchange Online: Full user mailboxes, including Mail, Contacts, Calendar, and Tasks items.
Retention period is 1 year across all three services. Recovery points for OneDrive and SharePoint go back 10 minutes at a time for the prior two weeks, then switch to weekly snapshots for weeks 2 through 52. Exchange is more granular: 10-minute recovery points extend for the full prior 52 weeks, giving you a much tighter restoration window for email data all the way back to a year ago.
What Microsoft 365 Backup does not cover, at least as of this writing: Teams chat history (separate Microsoft Teams backup considerations apply), taxonomy managed outside a SharePoint site scope, or data in services outside OneDrive/SharePoint/Exchange. Don't assume your entire Microsoft 365 tenant is automatically covered just because you have an active backup policy, you need to explicitly add each OneDrive account, SharePoint site, and Exchange mailbox to the policy scope.
When you understand the scope correctly, the policy creation screen in the admin center becomes a lot less confusing. Each service tile is configured separately, and you can choose to protect all resources in a given service or select specific ones.
Now let's actually set up the backup. Navigate to Microsoft 365 admin center > Settings > Microsoft 365 Backup. You'll see three tiles, SharePoint, OneDrive, and Exchange. Each one has its own setup flow and its own backup policy.
Click on the service you want to configure first. I usually recommend starting with Exchange because the 10-minute recovery point granularity running across 52 full weeks is the most valuable thing in the product for most organizations. On the Exchange tile, click Set up (or Edit policy if one already exists).
In the policy wizard, you'll choose between All Exchange mailboxes or Selected mailboxes. For smaller organizations, "All" is usually the right call. For large enterprises with tens of thousands of mailboxes, you may want to scope selectively to manage costs, remember, you're billed per GB of protected data, so protecting mailboxes that contain massive archives of unimportant mail adds up.
After selecting your scope, confirm the policy. You'll get a summary screen showing how many protection units you've selected. Click Activate policy. At this point, the policy enters a processing state.
For SharePoint and OneDrive, repeat the same flow from their respective tiles. The key difference is that for SharePoint, you're selecting sites, and the restore capability brings the entire site back to a prior state, overwriting all content and metadata since that restore point. That's a full rollback, not a granular file-level restore (though file version restore capability for individual files is coming). Make sure your team understands what a site-level rollback means before you initiate one in production.
# To check policy status via PowerShell (Microsoft 365 Backup PowerShell cmdlets):
# Reference the Microsoft 365 Backup Storage Graph APIs PowerShell guide
# for full cmdlet reference, admin center UI is sufficient for most setupsConfirmation that it worked: after the two-hour activation window, navigate to the Restore section of the Microsoft 365 Backup tool and select a protected resource. You should see restore points listed with timestamps. If you see at least one restore point, the policy is working correctly.
Setting up a backup policy and never testing a restore is one of the most common and dangerous mistakes in IT. I've seen organizations confidently point to an "active" backup policy, then discover during an actual incident that the restore process takes far longer than expected, or that the restore target URL conflicts with an existing site, or that key metadata wasn't captured correctly. Test restores before you need them. This is non-negotiable.
To run a test restore, go to Settings > Microsoft 365 Backup > Restore within the admin center. Select the service (OneDrive, SharePoint, or Exchange), then find a specific resource you want to test with, ideally a non-critical mailbox or a test SharePoint site rather than a production resource.
Select a restore point from the available timestamps. For OneDrive and SharePoint, you can restore to the same URL (full overwrite rollback) or to a new URL (creates a copy at a different address). For Exchange, you can restore the full mailbox or do a granular item-level restore to the same folder or a new folder within the user's mailbox.
Restoration performance targets are well-defined: up to 1,000 average-sized OneDrive accounts, SharePoint sites, or Exchange mailboxes can be restored at a rate of up to 1–3 TB per hour. For a single test mailbox or a small SharePoint site, you should see results within minutes. Watch for:
- Restore job status in the admin center (should progress from In progress to Completed)
- Content appearing at the target URL or target folder
- Audit log entries confirming the restore action, all backup and restore actions are fully auditable
If the restore completes but content looks wrong or incomplete, check whether the restore point you selected predates when those resources were added to the backup policy. Items that weren't protected at the time of the selected restore point won't appear in the restored output.
Once your Microsoft 365 Backup policy is active and your test restore is confirmed working, there are three operational hygiene steps you should do before calling this setup complete.
Billing review: Navigate to Billing > Your products in the admin center and find the Microsoft 365 Backup line item. The billing model charges $0.15 per GB per month for all data actively protected under your backup policies. Restores are always free. Keep an eye on this number as your tenant grows, if your organization onboards 500 new employees and each has a 10 GB OneDrive, that's 1.5 TB of new protected data added at $225/month incremental cost. Set up a billing alert in Azure Cost Management if your tenant is connected to an Azure subscription for billing.
Audit log verification: Open the Microsoft Purview compliance portal and check the audit log for Microsoft 365 Backup activities. Every backup policy creation, modification, and restore operation is fully auditable. Search for activity types like BackupPolicyCreated, BackupRestoreInitiated, and BackupPolicyModified. If you're in a regulated industry, this audit trail is part of your compliance documentation, make sure your security team knows where to find it.
Data residency confirmation: Microsoft 365 Backup keeps your data within the Microsoft 365 data trust boundary and honors your tenant's geographic residency requirements. The only exception is limited metadata, things like tenant ID and site IDs, which is sent to Azure for billing processing purposes. Your actual content never leaves the geographic boundary you've configured for your Microsoft 365 tenant. Confirm your tenant's residency settings under Settings > Org settings > Organization profile > Data location. Physical redundancy is built in: OneDrive, SharePoint, and Exchange maintain multiple physically redundant copies of your data to mitigate the impact of physical disasters.
# Audit log search (Microsoft Purview compliance portal):
# Solutions > Audit > New Search
# Activities: Filter by "Microsoft 365 Backup" activities
# Date range: last 7 days for initial validationAdvanced Troubleshooting
If the standard setup steps above didn't resolve your issue, here's what to look at for the harder edge cases.
Policy stuck in "Pending" for over 90 minutes: In the admin center, check whether there's a service health advisory affecting SharePoint, OneDrive, or Exchange Online. Go to Health > Service health and filter by those workloads. A backend service disruption can stall policy activation without surfacing a meaningful error message in the Backup tool UI. If there's no active advisory, try removing and re-adding a small subset of resources to the policy to force a re-evaluation. If that doesn't unstick it, this is an escalation scenario.
Restore points exist but are missing for specific sites or mailboxes: This usually means those resources were added to the policy after the restore point timestamp you're looking at. Check when the resource was added to the backup scope by reviewing the audit log. Resources only start accumulating restore points from the moment they're added to an active policy, there's no retroactive backup of historical data.
Exchange item-level restore returns empty results: When using the granular Exchange restore and searching for specific items, confirm that the items existed at the selected restore point and that they were either modified or deleted since that point. Microsoft 365 Backup's Exchange restore specifically targets items that were modified or fully deleted from the prior point in time, items that existed unchanged at both the restore point and the present won't show up as needing restoration.
PowerShell-based policy management for large tenants: For enterprise environments managing thousands of sites and mailboxes, the admin center UI can get unwieldy fast. Microsoft 365 Backup supports PowerShell cmdlets, full reference is in the Microsoft 365 Backup Storage Graph APIs reference guide. Using PowerShell, you can script bulk additions to backup policy scope, automate restore job monitoring, and pipe output into your existing monitoring tools. This is particularly valuable for organizations that provision new SharePoint sites or employee OneDrives frequently and need those resources added to backup policy scope without manual admin center clicks each time.
Immutability and offboarding considerations: Microsoft 365 Backup backups are immutable, they cannot be modified or deleted by anyone except a Backup tool admin explicitly initiating product offboarding. This is a security feature, not a limitation. The append-only storage architecture means that even a compromised admin account can't silently corrupt your backups. If you're planning to offboard the service, understand that this action removes the immutability protection on stored backups, and the offboarding process is documented separately in the admin center.
Prevention & Best Practices
Microsoft 365 Backup is a recovery tool, but the real goal is to never need it in anger. Here's how to get the most out of the product as an ongoing part of your data protection strategy, not a panic button you reach for once a year.
Automate new resource onboarding to backup scope: Every time your organization provisions a new SharePoint site or a new employee's OneDrive/Exchange mailbox goes live, that resource needs to be added to your backup policy, it doesn't happen automatically unless you've set the policy scope to "All." If you're in a large or growing org, rely on PowerShell automation or a lifecycle management workflow to ensure new resources enter backup scope within a defined SLA, say 24 hours of provisioning.
Document your recovery time objectives before an incident: Microsoft 365 Backup can restore up to 1,000 average-sized OneDrive accounts, SharePoint sites, or Exchange mailboxes at 1–3 TB per hour. That's the capacity ceiling, but your actual recovery time depends on how much data needs to be restored and which restore point you select. Map your business-critical sites and mailboxes before something goes wrong so you're not figuring out restoration priority during a crisis.
Run quarterly test restores: Don't just set up the policy and assume it works forever. Product updates, tenant configuration changes, and new resource additions can all affect your backup coverage in ways that aren't immediately obvious. A quarterly test restore to a non-production target takes less than 30 minutes and gives you confidence that the system will deliver when you genuinely need it.
Review backup coverage alongside access reviews: When you do periodic access reviews of SharePoint sites and mailboxes, include a check to confirm those resources are still in your backup policy scope. Decommissioned sites that are removed from the policy stop accumulating restore points, but if a site you thought was decommissioned is still active, it may be unprotected.
- Set your Exchange backup policy scope to "All mailboxes" rather than manually maintaining a list, new hires are covered automatically, leavers included until deprovisioning.
- Use the 10-minute recovery points for Exchange to handle accidental deletion incidents quickly, granular item-level restores are available for the full 52-week retention window.
- Create a dedicated Microsoft 365 Backup Administrator role assignment for your IT team rather than using Global Admin accounts, principle of least privilege applies here too.
- Set up billing alerts so unexpected growth in protected data doesn't cause budget surprises at the $0.15/GB/month rate.
Frequently Asked Questions
Does Microsoft 365 Backup automatically back up all my data, or do I have to set it up manually?
It's not automatic, you have to explicitly create backup policies for each service you want to protect: SharePoint, OneDrive, and Exchange each have their own policy. Within each policy, you can choose to protect all resources in that service (which does cover new resources going forward) or select specific sites, accounts, or mailboxes. Nothing is protected until a policy is created and activated in the Microsoft 365 admin center.
How far back can I restore data with Microsoft 365 Backup?
The retention window is 1 year across SharePoint, OneDrive, and Exchange. For OneDrive and SharePoint, you get 10-minute recovery points for the prior two weeks, then weekly snapshots going back 52 weeks. Exchange gives you 10-minute granularity for the entire prior 52-week period, which is the most detailed recovery option in the product. You can't restore data from before a resource was added to a backup policy, though.
How much does Microsoft 365 Backup cost, and is there a charge to restore data?
The billing model is $0.15 per GB per month for all data actively protected under a backup policy. The cost scales directly with how much data you're protecting across your selected SharePoint sites, OneDrive accounts, and Exchange mailboxes. The genuinely good news here is that restores are completely free, you only pay for the protected storage, not for pulling the data back when you need it.
Can Microsoft 365 Backup protect us from a ransomware attack?
Yes, this is one of the core scenarios Microsoft 365 Backup is specifically designed for. The backup storage uses an append-only architecture, meaning old content blobs can't be changed or overwritten, only new ones can be added. Exchange backups are stored in a way that client processes like Outlook or OWA can't touch them. Even if ransomware compromises your tenant and encrypts active data, the backup copies remain intact and restorable from a pre-attack restore point.
My organization is a GCC tenant. Can we use Microsoft 365 Backup?
Unfortunately, no. Microsoft 365 Backup is currently not available for Government Community Cloud (GCC) organizations. This is a platform availability limitation, not a licensing or configuration issue, so there's no workaround within the Microsoft ecosystem at this time. GCC tenants should evaluate third-party backup solutions that operate through the Microsoft 365 APIs to fill this gap.
Does Microsoft 365 Backup keep my data in my country, or does it go somewhere else?
Your actual data never leaves the Microsoft 365 data trust boundary and fully honors your tenant's configured geographic residency requirements. The only data that moves is limited metadata, things like your tenant ID and site IDs, which goes to Azure purely for billing processing. Physical redundancy is built in: Microsoft maintains physically redundant, geographically replicated copies of your backup data to protect against hardware failures and regional disasters. Your compliance and data sovereignty requirements are preserved.