After watching a mid-sized finance organisation lose three months of SharePoint data despite Microsoft's “retention” features, I'm uncompromising about third-party backup for Microsoft 365. Native capabilities are retention tools with dangerous gaps — not true backups. Here's where they break and what a real backup architecture looks like at enterprise scale.
Microsoft 365 E5 includes 1 TB of OneDrive per user (expandable to 5 TB, and up to 25 TB for archives), plus SharePoint tenant storage starting at 1 TB + 10 GB per licensed user. For a 200-person organisation that's a minimum of 200 TB of critical data in Microsoft's cloud — visible, but not automatically protected.
I learned this supporting a law-firm emergency recovery: a departing admin “cleaned up” SharePoint sites. After 93 days those sites aged out of the recycle bin, retention labels hadn't been applied, and the firm's cyber-insurance carrier ruled that native retention alone wasn't “reasonable data protection.” One admin error, no off-tenant copy, no recourse.
Microsoft's shared-responsibility model is explicit: they safeguard infrastructure, customers safeguard data. The Microsoft Services Agreement (§ 6b) literally advises backing up content with third-party services. The gaps that matter:
Multiple studies — most famously an Aberdeen paper (2020) — show 70%+ of SaaS data-loss incidents stem from user error, not platform failure. Microsoft protects against their outages, not your mistakes.
Protecting hundreds of E5 users surfaces problems consumer-grade tools can't address.
One pharmaceutical org's “100 GB” site ballooned to 1.4 TB in backups because automated workflows saved hourly Excel versions. Without granular version control, storage costs explode.
A Teams channel spans Exchange, SharePoint, and OneDrive. Protecting a “Team” means protecting each workload in lock-step.
Regulated sectors juggle retention policies against legal holds; native tools leave grey areas that purpose-built platforms resolve more cleanly.
After comparing Datto, Druva, Metallic, and others, Veeam Backup for Microsoft 365 stands out for large tenants — not because it's perfect, but because its architecture matches real constraints: it separates compute (proxies) from repositories.
One 400-user environment generating 2 TB of daily change finished backups in under four hours using six proxies across two sites. Version 8 added object-storage immutability, which enables cost-tiering by recovery objective:
| Storage tier | Use case | Cost / TB / mo | Recovery SLA |
|---|---|---|---|
| Local SSD | Last 7 days | $40–60 | <1 hour |
| S3 Standard | Days 8–30 | $23 | 2–4 hours |
| S3 Glacier Instant | Long-term retention | $4 | 4–8 hours |
Tiering by recovery objective let one organisation cut backup spend by ~70% while still meeting a seven-year retention mandate.
S3 Object-Lock plus Veeam's immutable flags prevent deletion even with breached credentials — a common policy is 30-day immutability for dailies, one year for monthlies, compliance mode where required. Encryption runs end-to-end: TLS 1.3 in transit, AES-256 at rest, with customer-managed keys or HSM integration.
Third-party Microsoft 365 backup earns its keep above roughly 100 users, where the infrastructure overhead amortises quickly; where an external-backup mandate requires immutability and long-term retention; and where there are Windows skills in-house, since proxies and repositories run on Windows. Below that, the calculus shifts — but “retention is not backup” holds at any size. The real question isn't whether to adopt third-party backup but how fast you can deploy it before the first data-loss incident.
