Disaster recovery and backups in Dynamics 365
How Microsoft handles backup and disaster recovery for Dynamics 365 — point-in-time restore, regional pairing, RPO/RTO, and what customers should do on top.
A common Dynamics 365 customer question — "what happens if Microsoft's data centre goes down" — has a well-defined answer. The platform's disaster recovery is built in, but several customer responsibilities sit on top, and several customer-side scenarios (logical corruption, accidental deletion) aren't covered by Microsoft's automatic measures.
Backups — what Microsoft does automatically.
-
Dataverse / Dynamics 365 CRM-side apps. Continuous backup with 28 days of point-in-time restore at the environment level. Production environments are protected; sandboxes have shorter retention.
-
Business Central. Backup retention of 28 days; point-in-time restore self-service from the BC admin centre to any moment in the past 28 days. Restores land as a new environment alongside the live one — manual cutover is the customer's choice.
-
Finance and Supply Chain. Production environments have database backup with restore through Microsoft support. Sandboxes can be point-in-time-refreshed from production via LCS.
Restore is restoration to a new environment — the live environment continues running. The customer chooses whether to switch over, copy data forward, or treat the restored environment as a side-by-side reference.
Regional disaster recovery.
- Microsoft pairs Azure regions (e.g. North Europe ↔ West Europe) for disaster recovery.
- In a regional outage, Microsoft fails Dynamics 365 services over to the paired region. Recovery Point Objective (RPO) is typically less than 15 minutes — data loss in a regional failure is bounded to the last 15 minutes of activity. Recovery Time Objective (RTO) is typically less than 12 hours for full restoration.
- These numbers are published in Microsoft's Service Level Agreements; specific products may vary.
- Customers don't need to do anything to trigger regional DR — Microsoft handles it.
What backups don't cover.
- User error — someone bulk-deletes a thousand records by accident. The records are gone from the live environment but recoverable from the 28-day point-in-time backup.
- Logical corruption — a bad import overwrites correct data with wrong data. Point-in-time backup lets you go back to before the import.
- Long-term archive. 28 days is enough for most operational mistakes, but if regulatory retention requires 7+ years, the customer must export data separately to an archive (Azure Data Lake, OneLake, on-prem archive). Microsoft's backup is not the regulatory retention solution.
- Cross-environment corruption. A poison message processed across many environments via integration. Each environment must be assessed and restored individually.
Customer responsibilities.
-
Solution and configuration backups. Solutions (managed export packages) should be version-controlled in source control. AL extensions, X++ code, Power Apps, flows — all stored in Git, deployable from CI/CD. Microsoft's backups protect the platform; your code is your responsibility.
-
Data exports for archive. Schedule periodic exports of Dataverse data to a customer-owned archive — Azure Data Lake, OneLake, or another store. Use Synapse Link for Dataverse for continuous near-real-time export.
-
Test the restore. Periodically — annually at minimum — actually run a restore drill on a sandbox to verify the process works and the team knows how to execute it.
-
Operational runbook. Document the steps for restore in different scenarios: bulk-deletion recovery, logical corruption recovery, regional DR drill response, full re-implementation worst-case.
-
Vendor-controlled environments. For BC SaaS and F&O, the customer doesn't own the infrastructure — Microsoft does. The customer's runbook focuses on what the customer can do (request a restore, copy environments, redirect integrations), not on what Microsoft owns.
Communication. During a Microsoft-side outage, monitor the Microsoft 365 Service Health page and the Tenant Admin Centre for status. Communicate to internal users; don't speculate on causes or timelines.
Practical advice. Most "disaster" scenarios are user error or logical corruption, not regional outages. Optimise your operational runbook for the common cases.
Related guides
- Backup strategy for Dynamics 365What Microsoft backs up automatically vs what customers need to plan for — Dataverse, F&O, third-party backup tools, and the difference between backup and disaster recovery.
- Capacity planning for Dynamics 365How to plan and monitor capacity in a Dynamics 365 tenant — Dataverse storage, API calls, AI Builder credits, environments, and the cost levers that matter.
- Data classification for Dynamics 365How to classify data in Dynamics 365 to drive security, retention, and compliance decisions — classification tiers, where to record them, and the integration with Microsoft Purview.
- Data residency and compliance in Dynamics 365Where Dynamics 365 data lives, how compliance certifications stack up, GDPR and country-specific rules, and the customer's responsibilities.
- Documentation strategies for Dynamics 365 implementationsWhat to document, who reads it, and how to keep documentation current — functional design, runbooks, training materials, and the layered documentation model that actually works.