Microsoft Fabric disaster recovery: what is replicated and what you rebuild

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.

The short answer, as Microsoft’s documentation stands on 2 November 2026: Fabric disaster recovery is a capacity setting that copies OneLake data, asynchronously, to the Azure region paired with the capacity’s region. Power BI semantic models, reports and dashboards have a separate disaster recovery of their own, on by default wherever the region’s pair supports Power BI, and stay readable but frozen after a failover. Almost everything else, from notebooks and pipelines to warehouse schemas, KQL databases and SQL databases, you rebuild yourself in a new capacity, from source control or from copies made beforehand. Some regions get no replica at all, and with the setting on, every OneLake write costs roughly twice the capacity units. Microsoft updated its item-by-item recovery guide on 27 October 2026, and this article has been checked against that version.

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. Where a region has no Azure pair, or its pair does not run Fabric, there is no replica at all
• It syncs data. After a failover the data is reachable through OneLake APIs and tools, but lakehouses and warehouses cannot be opened as items

That last point is the one that catches people out.

The switch sits on the capacity settings page, and Microsoft’s reliability guidance limits it to capacity admins or higher. It is offered only “where Azure regional pairings align with Fabric’s service presence”, which rules out more regions than most teams expect (see the region section below). Microsoft’s OneLake disaster recovery page also sharpens the first point above: replication “is asynchronous and occurs at the file level”, and “The secondary region might not contain a point-in-time-consistent copy of the data. For example, a newer file might be present while an older file that didn’t yet replicate is missing.” A Delta table is a set of data files plus a transaction log, so that caveat applies inside a single table. Microsoft’s lakehouse recovery script includes a step that deletes transaction log files written after a failover timestamp, which you obtain from Microsoft support.

What Fabric disaster recovery does not protect

Your data survives, and Power BI content stays readable. Most of what makes the data usable does not.

After a regional failure the tables exist in the secondary region, and Power BI semantic models, reports and dashboards stay available read-only, because Power BI’s own disaster recovery is always on whether or not the OneLake switch is, wherever the region is paired with one that supports Power BI. But nothing can be refreshed, published or changed, and the pipelines that populated the tables and the warehouse schema that structured them are unusable 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.

Item by item: what you rebuild after a failover

Microsoft’s experience-specific recovery guide now covers more than thirty item types and platform features. The item types most Fabric estates depend on are summarised below, with Microsoft’s documented route back for each. The guide applies only where the primary region has an Azure pair that supports Fabric.

Three things in that table are easy to miss. Warehouse data comes back through a lakehouse, not directly, and every application that connects to the warehouse needs a new connection string. Microsoft’s own answer for pipelines is not a restore at all but a standing copy in another region, and for warehouses that need “fully automated business continuity” it suggests two warehouses in separate regions, kept at parity by deploying and loading both. And a SQL database in Fabric comes back only as far as your last export, because its automatic backups stay in one region: “There are no geo-replicated backups.”

Power BI semantic models and reports after a failover

Power BI content is the part of a Fabric estate Microsoft protects without being asked, through a mechanism separate from the OneLake switch. Microsoft’s Power BI high availability and disaster recovery FAQ gives it its own numbers.

• On by default where the pair supports Power BI. In a region without a pair, “Data isn’t replicated to another region, and components don’t fail over to another region.” Sweden Central is a documented exception among paired regions: Microsoft lists Power BI disaster recovery as not available by default there, because its pair does not support Power BI.
• A 15-minute sync target. “There’s a 15-minute targeted point-in-time sync for any content uploaded or changed in Power BI.” Microsoft adds that it “can’t guarantee a timeframe”.
• A human decision, then about 15 minutes. “Power BI executive team members decide to fail over. The decision isn’t automated.” Once they have decided, Power BI takes approximately 15 minutes to become operational again; the time to reach the decision varies.
• Read-only afterwards. No refreshes, no publishing, no changes to dashboards or reports, not even a comment. Reports built on DirectQuery or Live Connect to on-premises sources stop working, because gateways do not function in failover mode.
• No export. “After a failover, export and backup operations don’t work because Power BI runs in read-only disaster recovery (DR) mode.” The REST APIs can still retrieve semantic model properties and model definitions, and Microsoft’s route back is to “redeploy the model definitions and refresh the models in a new tenant in the new region”.

Two consequences follow. With refresh unavailable, an import model keeps answering questions with whatever its last refresh loaded, which for a model refreshed overnight can be most of a day old. And the definitions you will redeploy should already exist outside the service: Fabric Git integration supports semantic models and reports, both still in preview, with exceptions that include push datasets, live connections to Analysis Services and model v1.

Direct Lake models are the open question. Microsoft’s FAQ does not say how they behave after a regional failover. It says only that when a Premium capacity is unavailable, “In DirectQuery mode and in Direct Lake mode, the semantic model requires the data sources to be available”, and Microsoft’s reliability page says that after a failover the lakehouses and warehouses behind them cannot be opened. Do not plan on Direct Lake reports behaving like import models until Microsoft documents it.

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.

Replication does not start instantly. Microsoft notes that after the setting is enabled, replication “might take some time to start”, and the capacity settings page shows each workspace’s geo-replication status. Enabling DR does not mean you are protected this afternoon. Microsoft’s OneLake page adds that enabling it “might take an extended period of time depending on current resource demands in the region, data size, and other factors.”

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. Microsoft’s reliability and OneLake pages, as checked on 2 November 2026, publish no recovery point objective for OneLake replication. The only recovery point figure Microsoft gives is Power BI’s 15-minute sync target, and it covers Power BI content, not OneLake.

Which regions get no replica

Microsoft’s rule is short: where a region has no Azure pair, or its pair does not support Fabric, “data replication isn’t available.” None of the Microsoft pages checked for this article lists which regions that means. Reading Microsoft’s Azure region pairs list against its Fabric region availability table, both checked on 2 November 2026, gives three groups of regions where Fabric runs but the OneLake switch has nowhere to replicate to.

That table is our reading of two Microsoft pages, not a Microsoft list, and both pages change. The last row is the least certain: neither Sweden South nor West Central US appears in the Fabric region table, but Microsoft flags Power BI disaster recovery as unavailable by default only for Sweden Central, so that table may not be a full list of where Fabric can hold a replica. For any one capacity, the capacity settings page is the authority: if a capacity admin cannot see the disaster recovery switch, the region pairing is the likely reason. For regions without a pair, Microsoft is explicit that customers who need cross-region recovery “must implement and manage their own recovery solution in a supported secondary region”, and its recovery guide applies only where the pair supports Fabric.

Two further region checks belong in the plan. A pair can sit outside your geography: “Brazil South is paired with South Central US, which is outside of the Brazil geography”, and because OneLake uses the standard Azure pairing and the secondary cannot be changed, a Brazil South capacity with the switch on needs a residency review first. And the tenant’s home region is a dependency of its own. Microsoft’s recovery guide “assumes that the tenant home region remains operational”; if it does not, every step waits on Microsoft recovering the home region first. Its reliability page adds that where the home region has no pair, capacities in any Multi-Geo region “might face operational problems if the home region encounters a disaster, as the core service functionality is tethered to the home region.”

What the disaster recovery setting costs

The setting has two costs, and Microsoft bills both separately from ordinary OneLake use.

Storage. With the switch on, “the storage is billed as Business Continuity and Disaster Recovery (BCDR) Storage”, priced per GB per month by region and tier on the Fabric pricing page. On 2 November 2026 the East US rate for BCDR hot storage was $0.0468 per GB a month, against $0.026 for standard OneLake hot storage.

Capacity. “When disaster recovery is enabled for a given capacity, write operations consume higher capacity units.” Microsoft’s OneLake consumption page gives the rates:

Iterative writes rise from 1,300 to 2,730 CU seconds per 100. Reads cost the same, so the extra load lands on ingestion-heavy capacities, and it comes out of the same capacity units as every other workload. On a capacity already sized close to its limit, turning the switch on is a capacity planning decision as well as a continuity one. Both costs show as separate line items, BCDR Storage and BCDR Operations, in the Capacity Metrics app. One thing the switch never covers: OneLake cache storage for KQL and Data Activator retained data is not “included in Business Continuity and Disaster Recovery (BCDR) coverage”.

In our view, production capacities should have disaster recovery switched on, and development and support capacities should be left out to save the additional cost.

Recovery is manual, so write the runbook now

Microsoft initiates the regional failover itself, typically in under an hour, and afterwards the Fabric portal and Power BI are read-only: nothing can be refreshed, published or changed. Getting back to normal operation is a sequence you perform under pressure:

1. Create a new Fabric capacity, and new workspaces on it. Microsoft’s guidance on where differs by page: its reliability page says any region, preferably outside your primary geography because demand will be high, while its item-by-item recovery guide works the example in the paired region, where the replicated data lives. Check data residency before going outside your geography
2. Restore item definitions, notebooks, pipelines and warehouse objects from source control
3. Re-point and re-load data from the replicated OneLake into the new workspace
4. 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.

Microsoft’s current guide adds dependencies worth writing into the runbook in order. The lakehouse script needs a failover timestamp that you have to request from Microsoft support. Lakehouses come back before the items that point at them: notebooks with a default lakehouse, materialized lake views, Spark job definitions and GraphQL APIs. Warehouses need new connection strings in the applications that use them. Refresh schedules, run history and workspace monitoring data start again from nothing in the new region. And the replicated data itself is not frozen: after failover, Microsoft says, “you can use the OneLake APIs through the global endpoint to read and write data in the secondary region.”

When we rehearse a recovery, the first thing that breaks is the ownership sequence. Beyond the runbook itself, a lot of permissions and ownership have to be defined for a streamlined recovery, and who has the rights to create objects decides whether the runbook can be followed at all.

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

Microsoft’s own recovery guide now leans the same way. For notebooks, user data functions, GraphQL, Copy job, Apache Airflow jobs, Activator, maps, ontologies, variable libraries, deployment plans and event schema sets, the route back it describes first, or only, is Fabric Git integration. Two limits apply. Git holds definitions, not data or state: in Microsoft’s words, “Git integration recovers only source code and project assets”, and history does not come back. And items Git does not support “are ignored” in a connected workspace, so the list of what is not in the repository is the part of the plan to write down.

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
• Check that the disaster recovery switch is offered on each capacity; where it is not, assume the region has no replica and the recovery plan is entirely yours
• Price BCDR storage and the extra write capacity units before enabling, then watch both in the Capacity Metrics app
• Put every workspace under Git integration, with definitions committed
• Keep semantic model and report definitions outside the service, because a failed-over Power BI cannot export them
• Document a separate DR approach for KQL databases
• Export SQL databases in Fabric to another region on a schedule, and copy any other data held outside OneLake
• Record in the runbook that lakehouse recovery needs a failover timestamp from Microsoft support
• Define RTO and RPO per workload rather than for the platform as a whole
• Rehearse a restore into a recovery workspace in another region at least annually
• Measure actual restore time against your stated RTO, and correct the gap

A rehearsal is a restore, not a failover. Microsoft’s Well-Architected guidance for Fabric tells teams to “Practice restores in non-production environments” and is plain that “Direct chaos testing inside Fabric isn’t possible”, so the test is rebuilding a workspace elsewhere from source control and a copy of the data, and timing it. Do not plan on reading the replica for a rehearsal: Microsoft documents access to the secondary region only after a failover.

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. Disaster recovery is also only one part of running Fabric once it is live. What the rest involves, and what Microsoft’s SLA covers, is set out in Fabric managed services: what a 24/7 SLA actually covers.

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 OneLake data only. Power BI semantic models, reports and dashboards are protected separately by Power BI’s built-in disaster recovery and stay readable, but pipelines, notebooks and warehouse schemas are not covered. The setting can be changed once every 30 days per capacity, and regions without a pair that runs Fabric get no replica.

Is Fabric disaster recovery automatic? Partly. Replication is automatic, and Microsoft initiates the regional failover, after which the portal and Power BI are read-only. Restoring normal service is manual: you create a new capacity, restore definitions from source control, and re-load the data.

Can I choose the Fabric secondary region? Not for replication. Replicated data goes to the Azure paired region, which matters where data residency requirements apply. Where you recover is less settled. Microsoft’s reliability page says any region, preferably outside your primary geography, while its item-by-item recovery guide works the example in the paired region. Where a region has no pair that runs Fabric, there is no replica to recover from. Some pairs also cross a border: Brazil South is paired with South Central US.

Are semantic models and pipelines covered by Fabric disaster recovery? Semantic models are, through Power BI’s own disaster recovery, which is on by default wherever the region is paired with one that supports Power BI: they stay readable after a failover but cannot be refreshed or changed. Pipelines and warehouse schemas are not covered. Keep their definitions in Git so they can be redeployed. Semantic models cannot be exported during a failover, and Microsoft’s guidance for critical pipelines is to build them in workspaces in more than one region.

What does Fabric disaster recovery cost? Two things. Replicated data is billed as BCDR storage, priced per GB per month by region on Microsoft’s Fabric pricing page: in East US on 2 November 2026, $0.0468 for BCDR hot storage against $0.026 for standard hot storage. And OneLake write operations consume roughly twice the capacity units while the setting is on; reads cost the same. Both appear as separate line items in the Capacity Metrics app.

Divya Pal Singh

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.