Quick answer
Microsoft 365 does not back up your data the way most people assume. Microsoft is responsible for the infrastructure — uptime, redundancy, datacenter availability — but you are responsible for your data. If a user deletes a folder of important files, an attacker encrypts your SharePoint site, or a malicious insider wipes a mailbox, Microsoft's native protections will recover some of it for a limited window — and then it's gone.
This isn't a trick or a gotcha. It's right in Microsoft's Services Agreement, and it's standard for every major SaaS provider: they protect the platform, you protect the data. The fix is to add a real backup, either via Microsoft's own native backup product (launched in 2024) or a third-party solution.
The high-level options:
| Option | Typical cost | Best for |
|---|---|---|
| Microsoft 365 Backup (native) | ~$0.15/GB/month | Tightly Microsoft-aligned shops; large data volumes |
| Third-party SaaS backup (Veeam, Datto, Druva, Acronis, etc.) | $3–$8/user/month | Most SMBs; better cross-platform options; mature restore UX |
| No third-party backup | $0 | Nobody. This is not a real option. |
The rest of this guide explains what Microsoft actually retains, what's at risk, what each backup option does and doesn't do, and how to choose.
Does Microsoft 365 back up your data?
Short answer: not in the way you need it to.
Microsoft's native protections in M365 include:
- Geo-redundancy — your data is replicated across multiple datacenters, so a single regional failure doesn't lose it
- Recycle Bin in OneDrive and SharePoint — deleted items recoverable for 93 days by default
- Deleted Items in Exchange — emails recoverable from the Deleted Items folder until they're emptied or aged out
- Recoverable Items in Exchange — emails recoverable for 14 days (default; configurable up to 30) after they leave Deleted Items
- Version history — file versions retained for limited time in OneDrive/SharePoint
- Retention policies — if configured, can extend retention for compliance reasons
What those protections do not cover:
- Long-term retention. 93 days in the SharePoint recycle bin sounds like a lot until someone notices a missing folder 4 months later.
- Granular point-in-time recovery. "Restore everything to how it was on Tuesday at 2 PM" isn't something native protections support cleanly.
- Ransomware on cloud-stored files. If ransomware encrypts files synced through OneDrive, the encrypted versions sync to the cloud. Native version history can sometimes recover, but only if the malware doesn't roll through enough versions to exceed the limit (and modern ransomware specifically targets this).
- Departed employee data. When a license is removed and the account is deleted, the mailbox and OneDrive content are typically purged within 30 days. If you didn't preserve it before deletion, it's gone.
- Malicious insider scenarios. An admin or privileged user with intent to destroy can systematically delete content faster than recycle bins can compensate.
- Compliance and legal hold scenarios beyond defaults. If you need to prove what an inbox looked like 18 months ago for litigation, native protections won't get you there.
The shared responsibility model
Every major SaaS provider — Microsoft, Google, Salesforce, ServiceNow — operates on a shared responsibility model. Understanding the split is foundational.
| Microsoft's responsibility | Your responsibility |
|---|---|
| Datacenter physical security | User access controls (MFA, conditional access) |
| Service uptime and redundancy | Account lifecycle management (offboarding) |
| Network infrastructure | Data classification and protection |
| Hardware failure recovery | Data backup and recovery |
| Platform security patches | Endpoint security on devices accessing M365 |
| Service-level continuity | Business-level continuity and DR planning |
| Geo-redundant data replication | Protection against accidental and malicious data loss |
Microsoft's own published shared responsibility documentation explicitly puts data backup in the customer column. This isn't ambiguous — it's the design.
What's actually at risk without a real backup
Six concrete loss scenarios that native M365 protections don't reliably cover:
1. Accidental deletion past the recovery window
The most common scenario. Someone deletes a folder, doesn't realize it for 100+ days, by which time it's permanently purged. Project files, client documents, financial records — all gone with no recovery path.
2. Ransomware on synced files
OneDrive and SharePoint sync compromised files to the cloud. Some ransomware variants are now sophisticated enough to first delete version history, then encrypt the latest version. Native protections can't always recover from this.
3. Departed employee data loss
Standard offboarding: license removed, account deleted, mailbox and OneDrive purged. Without a backup or proactive preservation step, anything that wasn't migrated to a shared location before offboarding is unrecoverable.
4. Malicious insider
An admin or disgruntled employee systematically deletes files, mailboxes, or SharePoint sites. Recycle bins fill or get manually emptied. Without independent backups, recovery is partial at best.
5. Compliance and legal hold gaps
Litigation hold or regulatory request requires proving the state of data at a specific historical point. Native retention may or may not cover the specific time and scope needed.
6. Compromised account
Attacker gains access via phishing, sets up forwarding rules, deletes evidence, exfiltrates data. After remediation, you need to know what they did and what they took. Native logs help, but full data restoration usually requires a backup.
Real-world example: A 40-employee firm we worked with discovered a compromised executive account 6 weeks after the fact. The attacker had deleted about 200 emails containing transaction details and routing information related to ongoing fraud. The firm's IT person assumed Microsoft "had backups." None of those emails were recoverable from native protections. With a third-party backup in place, all 200 emails would have been restored from a pre-compromise snapshot.
Microsoft's native backup product (launched 2024)
Microsoft launched a first-party product called Microsoft 365 Backup in 2024 that addresses many of these gaps — but it's not the same as having a real third-party backup, and it has specific tradeoffs to understand.
What it is
Microsoft 365 Backup is a Microsoft-operated service that creates point-in-time backups of Exchange Online mailboxes, OneDrive accounts, and SharePoint sites. Backups are stored within Microsoft's infrastructure (not exported elsewhere), with up to 365 days of retention. Recovery is fast (minutes vs. hours) because the data never leaves the Microsoft cloud.
How it's priced
~$0.15 per GB per month of protected data. For a 50-user company with 50GB of average data per user (mailbox + OneDrive + SharePoint share), that's roughly $375/month — about $7.50/user/month. Pricing scales linearly with data volume.
What it's good at
- Speed of recovery. Bulk restore operations measured in minutes, not days. This matters for ransomware response.
- Microsoft-native integration. No separate vendor relationship, no separate console for IT to learn.
- Service-level support. Microsoft's own engineers handle the backup infrastructure.
What it isn't
- It's not a 3-2-1 backup. The data stays in Microsoft's cloud. If your concern is "what if Microsoft has a major outage or data integrity issue," this doesn't address that.
- It only covers Exchange, OneDrive, and SharePoint. Teams chats, Planner, Lists, and other M365 surfaces aren't currently in scope.
- Pricing scales with data, not users. For data-heavy organizations, this can get expensive quickly compared to per-user third-party pricing.
- No export option. You can't take your backups elsewhere if you switch backup providers or want offline copies.
Microsoft 365 Backup is a reasonable fit for shops that are tightly aligned with the Microsoft ecosystem and prioritize speed of recovery. It's not the right answer for organizations that want true third-party redundancy or need broader workload coverage.
Third-party M365 backup solutions
The third-party backup market is mature — vendors have been offering M365 backup for over a decade. The major players each take a slightly different approach:
| Vendor | Strengths | Typical pricing |
|---|---|---|
| Veeam Backup for M365 | Mature platform, granular restore, strong MSP partner program | $3–$5/user/month |
| Datto SaaS Protection | MSP-focused, simple deployment, good restore UX | $4–$6/user/month |
| Druva | SaaS-delivered (no infrastructure), broad workload coverage | $5–$8/user/month |
| Acronis Cyber Protect | Backup + security in one platform; good for smaller shops | $4–$7/user/month |
| Barracuda Cloud-to-Cloud Backup | Strong Exchange focus, simple admin | $3–$5/user/month |
| SkyKick / NinjaOne | MSP-managed, integrated with PSA tools | $3–$5/user/month |
The differences between these vendors at a feature level are smaller than the marketing suggests. The bigger differences are operational: how easy is the admin console, how granular are the restores, what's the MSP support like, and how does pricing scale as you grow.
Native vs third-party: how to choose
The honest decision framework for SMBs:
Choose Microsoft 365 Backup (native) if…
- You're a Microsoft-first organization with no plans to diversify
- Your data volume per user is modest (under ~30GB average) so per-GB pricing works in your favor
- Recovery speed for bulk restore scenarios is critical
- You don't have a strong MSP relationship managing backup separately
Choose a third-party solution if…
- You want true independence from Microsoft (different vendor, different infrastructure)
- Your data volume is high and per-user pricing is more predictable than per-GB
- You need broader workload coverage (Teams chat, Planner, OneNote, etc.)
- You want the option to export backups for compliance, audit, or migration
- Your MSP already standardizes on a specific vendor for SMB clients (most do)
Most SMBs end up choosing third-party. The data independence and per-user pricing predictability matter more in practice than the marginal recovery speed advantage of native.
What to look for in any M365 backup solution
Twelve evaluation criteria. The best vendors check most or all of these.
- Coverage: Exchange Online, OneDrive, SharePoint, Teams (chat and channels), Public Folders, Planner
- Backup frequency: Multiple times per day, ideally every 4 hours or better
- Retention: Configurable, with at minimum 7-year option for regulated industries
- Granular restore: Single email, single file, single SharePoint item — not just "restore the whole mailbox"
- Point-in-time restore: "Restore everything to how it looked at this exact moment" capability
- Cross-user restore: Restore a departed employee's data into a different active user's account
- Restore verification: Tests that confirm backup integrity, with documented test results
- Search across backups: Find emails or files across all backed-up data without restoring everything first
- Export options: PST, ZIP, or other portable formats for legal hold or migration
- Encryption: Data encrypted in transit and at rest, with documented key management
- Compliance certifications: SOC 2, ISO 27001 minimum; HIPAA, PCI as applicable
- SLA and support: Documented support response, with phone access for restore emergencies
Pricing reality for SMBs
Realistic monthly costs for M365 backup at different business sizes (third-party, mid-market vendors):
| Users | Monthly cost (low end) | Monthly cost (high end) |
|---|---|---|
| 10 users | $30 | $80 |
| 25 users | $75 | $200 |
| 50 users | $150 | $400 |
| 100 users | $300 | $800 |
| 250 users | $750 | $2,000 |
Annual cost ranges from a few hundred dollars for a small shop to mid-five-figures for mid-market — meaningful, but trivial compared to the cost of permanent data loss. Most managed services contracts include M365 backup as part of a broader package, which can reduce the marginal cost.
Implementation considerations
Six things to think through before signing with a backup vendor:
1. Initial backup window
The first full backup of a 100-user environment with significant historical data can take days or weeks. Plan accordingly — the protection window doesn't start until the initial backup completes.
2. Permission and access setup
Backup vendors need read access to your M365 tenant. Most use modern OAuth-based authentication. Validate that the vendor's permission scope is appropriate (least-privilege) and audited.
3. Departed user handling
Decide your policy for departed user data: how long to retain after license removal, who has access to restore from departed accounts, and what your data retention requirements are.
4. Test restoration
Run a documented test restore quarterly. Treat it like a fire drill — the actual recovery scenario shouldn't be the first time you've used the restore function.
5. Documentation and runbooks
Document the restore procedure with screenshots and exact steps. During a real incident, the person doing the restore may not be the person who set up the backup.
6. Coverage gaps
Most backup tools don't cover Teams chat by default (some require additional licensing). If Teams chat history is operationally important, verify coverage explicitly.
Common mistakes
Five failure patterns we see regularly:
- Assuming Microsoft handles it. The most common mistake. Reading this article fixes it.
- Buying backup but never testing restoration. A backup that hasn't been tested is just an expensive hope. Quarterly test restores are the minimum.
- Setting retention too short. 30 or 90 days feels reasonable until someone needs to recover something from 2 years ago. Default to 1+ year, longer for regulated industries.
- Excluding admin or shared mailboxes from backup. Frequently the most important data lives in shared mailboxes, distribution lists, and admin accounts. Don't license-cap your backup to "active users only."
- Using a backup that's tied to a single admin's credentials. If that admin leaves and the credentials lapse, backups silently fail. Use service accounts or modern OAuth-based authentication.
Getting started
If you don't have a real M365 backup today, the steps to fix that:
- Audit what you have. What native retention is configured? What's the gap between current state and "real backup"?
- Decide native vs third-party using the framework above.
- Shortlist 2–3 vendors and request demos. Focus on restore UX more than feature lists — the restore experience is what you'll actually use under pressure.
- Pilot with a small subset (10–20 users) for 30 days before rolling out broadly.
- Document your restore procedure and run a test restore in the first 60 days.
- Set a quarterly test cadence as part of your ongoing operations.
If you'd like help evaluating M365 backup options for your environment — including a real comparison of native versus third-party pricing for your specific user count and data volume — that's the kind of conversation Datastrive has with our Microsoft 365 and cybersecurity clients regularly. Setting up a backup is straightforward; choosing the right one for the long term takes a real conversation.
Get on a call with one of the partners if you'd like to talk it through. No pitch deck, no obligation. Just a real conversation about what's at risk in your environment and the realistic options to fix it.
