Microsoft Fabric has built-in disaster recovery, and that sentence has given a lot of architecture teams false comfort.
The capability is real. What it protects is considerably narrower than most teams assume, and the gap between “DR is enabled” and “we can actually recover” is where the risk lives. This article sets out exactly what Fabric disaster recovery replicates, what it does not, and what belongs in your runbook to cover the difference.
What Fabric disaster recovery actually does
Disaster recovery in Fabric is a capacity-level feature, toggled per capacity in the Fabric Admin portal. When enabled, OneLake data in that capacity is geo-replicated to the paired region, across hot, cool and cold tiers. That means the files and Delta tables underpinning your lakehouses and warehouses.
Three characteristics define its behaviour:
- Replication is asynchronous, so anything not yet copied when a region fails is lost
- The secondary region is the standard Azure paired region and cannot be chosen
- It syncs data. It does not create a running read-replica you can fail over to
That last point is the one that catches people out.
What Fabric disaster recovery does not protect
| Protected | Not protected |
| OneLake data (files, Delta tables) | Workspaces |
| Hot, cool and cold tiers | Pipelines |
| Semantic models | |
| Warehouse schemas and object definitions | |
| KQL database data (stored outside OneLake) |
Your data survives. Everything that makes the data usable does not.
After a regional failure the tables exist in the secondary region, but the workspace that organised them, the pipelines that populated them, the warehouse schema that structured them, and the semantic models the business actually consumes are all gone unless you have provided for them separately.
KQL databases deserve particular attention, because that data sits outside OneLake entirely and needs its own disaster recovery approach.
The operational constraints teams discover too late
Four practical limits shape any realistic recovery plan.
The toggle can only be changed once every 30 days. This is not a switch to flip during an incident. It is a decision made months ahead.
Initial synchronisation can take up to seven days, depending on volume. Enabling DR does not mean you are protected this afternoon.
The paired region is fixed. If you have data residency obligations that conflict with the Azure pairing, built-in DR may not be usable at all.
Asynchronous replication implies a real RPO. You need to quantify acceptable data loss rather than assume zero.
Recovery is manual, so write the runbook now
There is no failover button. Recovery is a sequence you perform under pressure:
- Create a new workspace on capacity in the secondary region
- Restore item definitions, notebooks, pipelines and warehouse objects from source control
- Re-point and re-load data from the replicated OneLake into the new workspace
- Rebuild and validate semantic models, then re-establish downstream connections
As a rough planning figure, in our engagements it takes 15 minutes to two hours to restore a git-controlled environment: the lakehouse, warehouse, data pipelines, notebooks, reports and semantic models. The spread is wide because it tracks data volume and how disciplined your source control is. Validate the range against your own volumes rather than adopting it as a commitment.
Closing the gap with Git integration
Because the platform replicates data but not definitions, source control is the missing half of your Fabric disaster recovery strategy.
With Fabric Git integration against Azure DevOps or GitHub, item definitions live in a repository rather than only inside a workspace. Recovery then becomes redeployment: pull the branch, deploy to the secondary-region workspace, re-load data. That converts an error-prone manual rebuild into a repeatable, testable process, and it is the single most effective step most teams can take.
In our Fabric migration for TMS International, every workspace went under Git integration for exactly this reason: when definitions live in a repository, a regional recovery becomes a redeployment rather than an error-prone rebuild.
Fabric’s newer selective branch-out and deployment pipeline capabilities make this materially easier to run properly.
A practical Fabric BCDR checklist
- Enable DR only on capacities whose data genuinely warrants it, given the 30-day toggle constraint
- Confirm the paired region satisfies your data residency requirements
- Put every workspace under Git integration, with definitions committed
- Document a separate DR approach for KQL databases
- Define RTO and RPO per workload rather than for the platform as a whole
- Rehearse a restore into a secondary-region workspace at least annually
- Measure actual restore time against your stated RTO, and correct the gap
The takeaway
Fabric’s built-in disaster recovery is a data durability feature, not a business continuity solution. Treat it as one layer, pair it with source control and a rehearsed runbook, and you have genuine continuity. Enable the toggle and assume you are covered, and you will discover the difference at the worst possible moment.
Veratas designs and operates enterprise Microsoft Fabric estates, including capacity design, governance and continuity planning. See how we handled a full Fabric migration for TMS International, or read more about our data consulting approach.
Not sure what your Fabric environment would actually lose in a regional outage? Talk to our team and we will map it with you.
Frequently asked questions
Does Microsoft Fabric have disaster recovery?
Yes, at capacity level. When enabled, OneLake data is asynchronously geo-replicated to the Azure paired region. It replicates data only, not workspaces, pipelines or semantic models.
Is Fabric disaster recovery automatic?
No. Replication is automatic, recovery is not. You must manually create a workspace in the secondary region, restore definitions from source control, and re-load the data.
Can I choose the Fabric secondary region?
No. It is determined by standard Azure region pairing and cannot be changed, which matters where data residency requirements apply.
Are semantic models and pipelines covered by Fabric disaster recovery?
No. Neither are workspaces or warehouse schemas. Keep them in Git so they can be redeployed.
How often can I change the DR setting?
Once every 30 days per capacity, and initial synchronisation can take up to seven days.
Azure and Business Intelligence Architect with 17+ years of experience delivering cloud data and analytics solutions. Focus areas include Azure data platforms, ETL and ELT architecture, and enterprise BI on Microsoft Azure.