Disaster recovery and backups in Dynamics 365

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.