Microsoft Fabric's native disaster recovery protects the data in OneLake and keeps Power BI readable, but not the working shape of your estate. Zone redundancy and, where you turn it on, cross-region replication keep your data durable. After a failover, lakehouses, warehouses, pipelines and notebooks can't be opened until you re-create them in a new capacity and restore their data, which is what Microsoft's own recovery steps describe. The community shorthand: redeploy and rehydrate. You rebuild the estate around the data the platform kept. Knowing that gap is the first step; closing it's the next.
Most teams learn where Fabric's disaster recovery stops on the day they need it, which is the worst day to find out. So let's be precise about what the platform protects for you, and what it quietly leaves to you.
What does Microsoft Fabric's native disaster recovery actually protect?
The data. Fabric stores your tables and files in OneLake, which uses zone-redundant storage where the region supports it and locally redundant storage elsewhere. Cross-region replication is a disaster recovery setting you turn on per capacity; with it on, OneLake data is replicated to the Azure-paired region, asynchronously, so data not yet copied when a disaster hits is lost. Power BI's own disaster recovery is on by default. That part is real, and it's genuinely useful.
What it means in practice: the bytes are durable and reachable. After a regional failover, the Fabric portal and Power BI work read-only, and you can reach OneLake data through its APIs and tools. This is the layer people mean when they say "Fabric has DR", and they're right.
What Fabric's native DR doesn't do
It doesn't put your estate back into normal operation for you. Durable data isn't a recovered environment. After a failover, lakehouses, warehouses, pipelines and notebooks can't be opened, and notebook code isn't saved unless you kept it in Git. Microsoft's recovery steps are yours to run: create a new capacity, re-create the workspaces and items, and restore each one, experience by experience.
Accidental deletion is a different case, and Fabric does cover it, within limits. Fabric can restore a deleted workspace (7–90 days) or, from the recycle bin, a supported item like a data pipeline (3–90 days), in place, within a retention window. That's genuinely useful, but it expires, it only undeletes to the last state, and it doesn't cover every item type (Power BI semantic models aren't on item recovery's list). Neither DR nor the recycle bin gives you a versioned copy you hold.
That is why the community shorthand is redeploy and rehydrate: re-create the workspaces and pipelines, then restore the data into them. For a real estate, that can take days, not minutes, and every hour of it is on you, under incident pressure, from whatever definitions you happened to keep.
Fabric native DR: what's covered and what isn't
Laid out plainly, the line between what the platform recovers and what you own looks like this:
| Native Fabric DR | Managed continuity layer | |
|---|---|---|
| Data durability in OneLake | Covered | Covered |
| Restore a deleted workspace or item | Workspace retention and the recycle bin: retention window, in place | From a versioned backup, any point |
| Semantic model / report recovery | Not in item recovery; read-only after a regional failover | Yes |
| Point-in-time lakehouse restore | Not native | Yes |
| Restore into another capacity / relocate an object | After a regional failover only, by copying data into a new capacity yourself; otherwise in place (a warehouse table can be cloned within the warehouse) | Yes |
| Independent copy you hold (outlives retention windows) | No | Yes |
| Recovery orchestration / sequencing | Not native | In development |
| Verified restore | No | Yes |
The point-in-time row is worth calling out. A Fabric warehouse has restore points; a lakehouse doesn't. A lakehouse's native safety net is narrower and shorter: OneLake soft delete keeps a deleted file for seven days, and Delta time-travel covers an overwrite within retained history. There's no point-in-time restore of a lakehouse, and the estate's structure comes back only from what you keep in Git or deployment pipelines.
What real BCDR needs beyond native DR
Business continuity and disaster recovery is more than durable storage. To actually recover an estate, and to prove you can, you need five things native DR doesn't give you:
- An independent, versioned copy you can restore: workspaces, tables, semantic-model definitions, and pipeline definitions captured on a schedule, in storage you control, not just data kept durable inside Fabric.
- Restore on demand, into the capacity you choose: an entire backup into another capacity, or a single object or table back to its original location or a different one, without waiting for a regional failover or copying the data back by hand. The same backups drive migration and dev/test, which is why this is operational continuity, not disaster recovery alone.
- Recovery sequencing: the estate brought back in dependency order, so pipelines and models come up against the data they expect instead of failing in a pile. In development, not yet part of the beta.
- Verified restores: recovery you have actually watched work, so "we're covered" is a thing you have tested, not a thing you assume.
- Someone accountable: a clear owner for the restore, so it isn't improvised at 2 a.m. from whatever definitions happened to be saved.
A managed continuity layer provides these on top of the platform's data durability, with sequencing still in development. The starting move, though, is cheaper than that and worth doing first: know your estate (what exists, what depends on what, and what has drifted), because you can't sequence a recovery of an estate you can't see.
Disclosure: Fabric Control is my product, so this isn't a neutral comparison. It provides the backup and verified restores described above, with restore sequencing in development and not yet part of the beta; it's metadata-only, so your data never leaves your tenant. Only operational metadata crosses the boundary. Backup and continuity are a paid tier, and you start from the free governance tier. I'm naming it so you can weigh it, not to talk you past the parts native DR already handles.
What Fabric admins run into, and where this helps
The DR plan is a wiki page nobody has tested. A runbook that has never been executed is a guess about how recovery will go. A managed continuity layer with verified restores turns that page into something you've watched work, on a schedule, before the incident.
A region incident means rebuilding workspaces. Native DR keeps the data reachable and Power BI readable, but workspaces, pipelines and notebooks have to be re-created before anything runs again. Versioned backups of those definitions let you redeploy the structure instead of reconstructing it from memory.
You can't prove an RTO or RPO to an auditor. "The data is redundant" isn't an answer to "how fast do you recover, and how much do you lose?" A tested restore with a recorded recovery point and recovery time is the evidence, on demand.
A pipeline is deleted, and the recycle-bin window passes. Fabric's recycle bin can restore a deleted data pipeline within the item-retention window (3–90 days), but the recycle bin keeps no version history and it expires; after that the definition is gone unless you kept a copy (in Git, for example), and semantic models aren't on item recovery's list. Scheduled, versioned backups make a deleted pipeline something you restore to any point, into the capacity you choose.
You discover after an incident that "redeploy and rehydrate" means days. The cost of the gap is only visible when you're inside it. Pre-verified restores shorten that timeline from days of manual rebuilding to a tested restore; recovery sequencing, which orders it, is in development and not yet part of the beta.
Where to start
Start with visibility. It's free. Fabric Control's governance tier gives you a live view of your estate: what workspaces and capacities exist, how they depend on each other, and what has drifted. That map is the prerequisite for any real recovery plan, because you can't sequence the restore of an estate you can't fully see. It's free for one Azure tenant, for as long as you use it.
When you're ready to close the recovery gap itself (independent backups and verified restores, with sequencing in development), backup and continuity are the paid tier you add on top. But the honest first step is knowing your estate, and that costs nothing.
Frequently asked questions
Does Microsoft Fabric have built-in disaster recovery?
Yes. OneLake uses zone-redundant storage where the region supports it, capacity-level disaster recovery replicates OneLake data to the paired region when you turn it on, and Power BI disaster recovery is on by default. After a failover, data stays accessible and Power BI items are read-only; getting the rest of the estate back into normal operation means re-creating workspaces and items and restoring each one.
Does Fabric's native DR restore my workspaces and pipelines?
Not automatically. After a failover you can browse workspaces and read Power BI items, but lakehouses, warehouses, pipelines and notebooks can't be opened. Microsoft's recovery steps are to create a new capacity, re-create the workspaces and items, and restore each one following its experience-specific guidance; for item definitions such as notebooks, that guidance relies on Git integration.
Can I do a point-in-time restore of a Fabric lakehouse?
No. A Fabric warehouse has restore points; a lakehouse has no point-in-time restore. Its native recovery is narrower: OneLake soft delete keeps a deleted file for seven days, and Delta time-travel can roll back an overwrite within retained history. Restoring a lakehouse to an arbitrary earlier point depends on an independent copy you made or a managed backup that captured it.
What does redeploy and rehydrate mean for Fabric recovery?
It's the community's shorthand for Fabric DR, and Microsoft's own recovery steps bear it out: after a failover you re-create the workspaces and items in a new capacity and restore their data, experience by experience. The platform keeps the data accessible; for a real estate, that rebuild can take days rather than minutes.
What does Fabric Control add for Fabric disaster recovery?
It provides the parts native DR leaves out: an independent, versioned backup you can restore, and verified restores so recovery is something you have watched work. Recovery sequencing, which brings the estate back in the right order, is in development and not yet part of the beta. It's a paid tier, it's metadata-only so your data never leaves your tenant, and you start from the free governance tier.