Microsoft Fabric disaster recovery: what's covered and what isn't

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, and OneLake is built on Azure storage with zone and region redundancy — configured at the capacity level, with cross-region continuity you enable per capacity. When you turn that on, your data survives a zone or region event. That part is real, and it is genuinely useful.

What it means in practice: the bytes are durable. If a region has an incident, the data you loaded is protected according to the redundancy you configured. This is the layer people mean when they say "Fabric has DR" — and taken narrowly, they're right.

What Fabric's native DR does not do

It does not restore your estate. Durable data is not a recovered environment. Your workspaces, your data pipelines, your semantic models, the connections and structure that turn stored bytes into a working system — none of that is brought back by native DR. After a serious incident you are rebuilding those by hand and reloading data into them.

Accidental deletion is a different case — and Fabric does cover it, within limits. The recycle bin can restore a deleted workspace (7–90 days) or a supported item like a data pipeline (3–90 days), in place, within a retention window. That's genuinely useful — but it doesn't survive a region loss, it expires, it only undeletes to the last state, and it doesn't cover every item type (Power BI semantic models aren't included). Neither DR nor the recycle bin gives you a versioned copy you hold.

That is why the community's summary is blunt and accurate: DR in Fabric means redeploy and rehydrate, not restore. Redeploy the workspaces and pipelines; rehydrate the data into them. For a real estate, that is measured in 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:

The point-in-time row is worth calling out. A Fabric warehouse gained restore points in 2026; a lakehouse did not. 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 — but there is no point-in-time restore of a lakehouse, and nothing that brings the estate structure back.

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 four things native DR doesn't give you:

• An independent, versioned copy you can restore — workspaces, tables, and pipeline definitions captured on a schedule, in storage you control, not just data left durable in place.
• Restore anywhere, not just in place — an entire backup into another capacity, or a single object or table back to its original location or a different one, so recovery fits the incident. 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.
• 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. 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 cannot sequence a recovery of an estate you can't see.

Join the waitlist

Disclosure: Fabric Control is my product, so this isn't a neutral comparison. It provides the backup and restore-sequencing described above; it is metadata-only, so your data never leaves your tenant — only operational metadata (counts, status, size, configuration) 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 by hand. Native DR keeps the data, but the workspaces, pipelines, and models are gone until someone recreates them. 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" is not 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 there's no version history behind it and it expires — after that the definition is gone unless you kept a copy, and Power BI items like semantic models aren't covered at all. 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. Recovery sequencing and pre-verified restores collapse that timeline from days of manual rebuilding to an ordered, tested restore.

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, sequencing, verified restores — 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