M365 backup vendors and actual mass restore speeds
Posted by structured_triage@reddit | sysadmin | View on Reddit | 8 comments
Been evaluating a few M365 backup vendors lately and noticing a massive gap between sales pitches and incident reality. Everyone focuses heavily on per-GB storage pricing, but cheaper tools on shared infrastructure just stall against Microsoft's API limits during a full-tenant restore. A theoretical 4-hour RTO easily turns into a multi-day ordeal when you actually pull the trigger on a mass recovery. Beyond API throttling, tying the backup tool to the exact same Azure AD / Entra ID identity layer means a total tenant compromise locks you out of both production and the recovery console simultaneously. I’m starting to prioritize true architectural isolation and documented mass-restore speeds over raw storage limits. How are you guys validating actual recovery capabilities and tenant isolation before signing with a vendor?
Nakivo_official@reddit
The architectural isolation point you're raising is exactly right and often underweighted in vendor evaluations.
On tenant isolation, the critical question to ask any vendor is where the backup console authenticates. If it relies on the same Entra ID tenant you're trying to recover, a full tenant compromise becomes a single point of failure.
For mass restore speeds, ask every vendor what their documented restore throughput is under Microsoft API throttling conditions for a full Exchange Online or SharePoint tenant recovery.
Additionally, it is worth requesting a proof-of-concept restore of a full mailbox and a SharePoint site collection with documented timing, asking for SLA documentation that covers RTO and not just RPO, and confirming whether the vendor's infrastructure is shared across customers or dedicated to your tenant.
NAKIVO Backup & Replication can be deployed on your own infrastructure — on-premises, in your own cloud account, or on a NAS device — completely outside Microsoft's identity layer, with credentials managed independently. You can test it with the 15-day free trial.
Asleep_Spray274@reddit
I have always wondered in what situation a total tenant restore is required? In my 15 years working in azure and o365, I've never seen an org actually having to do a full tenant restore. Especially when all other protections are in place.
If you are scared of a bad actor getting high privilege credentials that might cause tenant wide destruction because you haven't thr other protections in place, then please spend as much time there ensuring that can't happen
theoriginalharbinger@reddit
The API limits do not directly correlate to the throughput. In any case, things like Sharepoint and OneDrive (which are both Sharepoint under the hood) have different API constraints, and things like mailbox recovery is going to look different depending on how your solution backed up and recovered pointers to OneDrive content.
Any good solution will have an API interface to trigger restores to an alternate location, from which you can measure speed. Avepoint is probably the best-architected MS365 recovery solution, but you'll pay for it.
Witty_Formal7305@reddit
If total time to restore is critical then I think your only option is going to be the M365 native backups with Microsoft. Every vendor is gonna have the same API limitations imposed by MS, when it comes to cloud to cloud backups we don't really commit / pitch a time to restore all of M365 because of exactly this, we can't commit to something we realistically have no control over, we just say we'll work as fast as we can and focus on critical information first, but time to restore will vary due to Microsoft limitations.
It still grinds my gears about this thing, they always had API limits but they conveniently clamped down on them like this conveniently at the same time as MS rolled out their own tool which in our testing (which admittedly was a while ago) seemed to not have the same restrictions, basically neutering competitors tools to push their own (which based on our math was 25% more expensive to boot)
MagicHair2@reddit
Veeam can use the ms apis (ie speed) with the premium offering
https://www.veeam.com/products/saas/backup-microsoft-office-365.html
RevolutionaryWorry87@reddit
Even more frustrating as their tool isn't immutable or off tenant.
Witty_Formal7305@reddit
yupp this too, it's the classic MS solution at this point, roll it out half baked and still somehow more expensive and then toot their own horn about "upgrades" that should have been standard from day one.
structured_triage@reddit (OP)
The timing of those API restrictions definitely highlights the conflict of interest when the infrastructure provider also sells the backup tool. And as RevolutionaryWorry87 pointed out, an "on-tenant" solution fundamentally breaks the core rule of architectural isolation. If your primary identity layer is compromised, relying on a native Microsoft tool means you lose access to both your production data and your recovery console simultaneously. Storing data completely outside the Microsoft ecosystem is the only way to ensure true immutability during a tenant-wide event. This is exactly why I'm leaning heavily toward vendors that support Bring Your Own Storage (BYOS) to guarantee that absolute separation.