Someone accidentally deletes a customer record with two years of transaction history attached, and IT's first instinct is confidence: "we're on SaaS, Microsoft backs everything up, we'll just restore it." Then the actual restore process gets explained, and it turns out the fix isn't nearly that surgical — restoring means rolling the entire environment back to a point in time, which would also undo every other transaction every other user posted since then. Suddenly the "simple" fix has a much bigger cost than anyone expected.
This gap between what people assume SaaS backup means and what it actually covers is common, and it's worth understanding clearly before an incident forces the conversation.
What Microsoft Genuinely Handles
Business Central Online runs on Azure SQL Database, and Microsoft automatically creates and maintains backups continuously — full, differential, and transaction log backups — with a retention window in roughly the 28-to-30-day range, covering both production and sandbox environments. For genuine business continuity against infrastructure failure, Microsoft also maintains geo-redundant replicas of production environments in a secondary Azure region, kept synchronized through continuous replication with typically only a few minutes of lag, specifically to protect against a region-wide Azure outage.
This is a genuinely strong foundation — it means the underlying infrastructure risk of data loss from hardware failure or even a full regional outage is handled automatically, without any action required from your team.
What This Backup Model Does Not Give You
The critical limitation, worth stating plainly: restoring from these automated backups means restoring an entire environment to a specific point in time. There is no native, granular, record-level restore capability — no way to say "just bring back this one deleted customer, exactly as it was, without touching anything else." A restore also creates the recovered environment as a separate sandbox, not an in-place fix to production, meaning any genuinely recovered data still has to be manually identified and re-entered or re-imported into the live environment afterward.
Administrators also cannot directly access or manage these backups themselves — only specific internal or delegated administrator roles can even initiate an environment restore through the admin center, and only within the retention window before the backup itself ages out.
Why This Matters More the Longer You Wait to Notice
The retention window is real and finite — roughly a month. A data problem that isn't noticed until after that window closes has no automated backup path back at all, regardless of severity. This is exactly why monitoring critical data changes and having a documented process for noticing problems quickly matters as much as the backup capability itself: Microsoft's automated protection is only useful within a window your team actually catches the problem inside.
Where Third-Party Tools Actually Add Value
Because native restore is whole-environment and time-boxed, a real market exists for Business Central-specific backup tools that provide genuinely granular, record-level restore, automated scheduled exports outside Microsoft's retention window, and cross-environment comparison capability. For companies with real regulatory retention requirements, or simply a lower tolerance for the "roll back everything" nature of native restore, evaluating one of these tools is a legitimate, worthwhile conversation — not a sign that Microsoft's native protection is somehow deficient, just narrower in scope than most people assume.
What a Realistic DR Conversation Actually Covers
A genuine disaster recovery conversation for Business Central needs to cover three distinct questions: what happens in a full regional Azure outage (Microsoft's geo-redundancy genuinely handles this), what happens if the environment needs restoring to a point in time due to widespread corruption or error (native restore handles this, at the cost of losing everything since that point), and what happens when a single record or small set of records needs recovery without touching anything else (native tools do not solve this — a third-party solution or a disciplined internal export process does).
Where to Start
If your current disaster recovery plan for Business Central is simply "Microsoft handles it," it's worth clarifying specifically which of the three scenarios above that assumption actually covers. For most companies, the gap that matters practically is the middle one — record-level recovery — and it's worth deciding deliberately whether a third-party backup tool or a documented internal process is the right answer, rather than discovering the gap during an actual incident.