Microsoft Fabric does not back up a lakehouse for you. Its native protection is real but narrow: a deleted lakehouse can be restored from the recycle bin within a retention window (item recovery, 3–90 days), OneLake soft-delete holds deleted files for 7 days, Delta time-travel covers overwrites within retained history, and region redundancy keeps data durable. What none of that gives you is a scheduled, versioned, point-in-time backup you hold independently — one that survives the retention window and a region loss, restores to an earlier point, and can be restored into another capacity or a single table at a time. That's an everyday operational capability, not just disaster recovery: recovering from a bad deploy, an accidental delete, or a corrupted table; migrating or standing up dev/test; proving recoverability to an auditor. For it, your two options are to script the copy yourself or add a managed tier. Either way, start with visibility: Fabric Control's governance tier is free for one Azure tenant and shows you the estate you'd be protecting; scheduled backup is a paid tier you add when you need it.
If you run a Fabric lakehouse, the question "what happens if this gets deleted or corrupted?" has an uncomfortable answer, and most teams don't find it until they need it. So it's worth being precise about what Fabric protects and what it leaves to you.
Does Microsoft Fabric back up a lakehouse for you?
No — not as a managed, scheduled backup. It's worth being exact, because the native protection is real but narrow. As of late 2026, a Fabric warehouse has restore points — an in-place rewind with roughly an 8-hour recovery point and retention up to 120 days. A lakehouse has no restore points and no managed backup. What it does have: the lakehouse item itself can be restored from the workspace recycle bin within the item-retention window (3–90 days, on by default), OneLake soft delete keeps deleted files for seven days, Delta time-travel lets you roll back an overwrite within retained history, and you can pull specific files or tables back with Azure Storage Explorer. Every one of those is in-place and time-boxed — none is a versioned copy you hold, none restores to an earlier point, and none can land in a different capacity.
Fabric's built-in disaster recovery adds region redundancy for the data in OneLake. That's a separate mechanism from the recycle bin: DR keeps data durable across a region event but doesn't rebuild your estate, and the recycle bin undeletes within a window but doesn't survive a region loss. So the native safety net is time-boxed and in-place — a recycle-bin window for a deleted item, seven days for a deleted file, Delta history for an overwrite. Anything past the retention window, an earlier point in time you didn't catch, an unsupported item like a Power BI semantic model, or a region loss is on you.
Option 1 — Copy the Delta tables yourself
A lakehouse's tables are Delta/Parquet files in OneLake, which means you can copy them out. On a schedule — a Spark notebook or a Data pipeline — you write the table files to storage you control: another lakehouse, or Azure Data Lake / blob storage outside the workspace. An open-source project, fabric-lakehouse-backup (github.com/mjtpena/fabric-lakehouse-backup), automates this pattern, and it's free.
What you get is a second copy of the table files. For a small estate with an engineer who has time, that can be enough. What it costs you is worth stating plainly:
- The maintenance is yours. Every Fabric change is a change you keep the script working through.
- Non-Delta tables aren't free. For those, you maintain and re-run the DDL scripts yourself.
- No verified restore. A copy you've never restored is a hope, not a backup — and the first real test is the worst time to learn that.
- No dependency-aware sequencing. Restoring a real estate in the right order, under incident pressure, is a different problem from copying files.
- Same-subscription blast radius. If the copy lives in the same subscription, one compromise or one wrong click can take the source and the backup.
Option 2 — A managed backup tier
The reason managed backup exists for every other platform is that "a copy of the files" and "a recovery you can count on" are not the same thing. Over the DIY copy, a managed tier adds:
- Scheduled, versioned backups of workspaces, tables, and pipeline definitions — a history you can restore to a point in time, not a single in-place window like the recycle bin.
- Point-in-time recovery with restore-dependency sequencing — the estate comes back in the right order, restored to an earlier point, not just undeleted to its last state.
- Restore anywhere, not just in place — recover an entire backup into another capacity, or restore individual objects or tables back to their original location or a different one. The recycle bin only undeletes in place — this is what makes backup useful for migration and dev/test, not only recovery.
- A verified test restore and integrity catalog — so "it's backed up" is something you've watched work, not assumed.
- Isolation you don't engineer — backup content in your own storage, under your own keys — a copy that outlives the retention window and survives a region loss.
Disclosure: Fabric Control does this, and it's my product, so this isn't a neutral comparison. Its design is metadata-only — your data never leaves your tenant; only operational metadata (counts, status, size, configuration) crosses the boundary. Backup is a paid tier, and you start from the free governance tier. The DIY route is real, and nothing on this page depends on the paid tier.
What Fabric admins run into — and where this helps
A lakehouse table gets dropped past the seven-day window. OneLake soft delete recovers a deleted file for seven days; after that, a dropped or truncated table is gone unless you kept a copy. Scheduled, versioned backup with real retention turns that into a recoverable event rather than a loss.
An entire workspace is deleted. Fabric's recycle bin can restore a deleted workspace and its supported items within a retention window (workspaces 7–90 days, items 3–90) — but not after it expires, not for unsupported items like Power BI semantic models, and only in place, to its last state. A versioned backup restores the workspace and its pipeline definitions to an earlier point, in dependency order, into the capacity you choose.
A bad overwrite outlives your Delta history. Delta time-travel can return a table to a prior version while that history is retained; once it's vacuumed or retention passes, the good state is gone. Point-in-time recovery from an independent backup covers what Delta history no longer does.
You have a copy, but nobody has ever restored it. A copy you've never restored is a hope, not a backup. A verified test restore and an integrity catalog make "it's backed up" something you've seen work.
An auditor asks you to prove you can recover. Showing current state, retention, and a successful restore is hard to assemble by hand. The free governance tier gives you the estate-wide picture; managed backup adds the verified-restore evidence.
You have Git integration, so you assume you're covered. Git and deployment pipelines version your item definitions — and Microsoft's own docs note that an item recreated from Git carries the definition only, not the data. Git protects the shape of your estate; it isn't a backup of what's inside it. Real backup captures both.
Where to start
Start with visibility, then add backup when you need it. Fabric Control's governance tier is free for one Azure tenant and shows you the estate you'd be protecting — every workspace, lakehouse, and pipeline, and how they depend on each other. You register a service principal you create and control; it reads operational metadata only, so your data never leaves your tenant. Backup and point-in-time restore are a paid tier you add on top when the gap above is one you can't carry — you don't decide on backup blind.
How to choose
The honest decision isn't "free vs. paid" — it's how much a failed recovery costs you, and who is accountable when it happens at 2 a.m. Map your situation to the three real paths:
| Do nothing | DIY copy | Managed tier | |
|---|---|---|---|
| Setup effort | None | Moderate | Low |
| Ongoing maintenance | — | Yours, forever | Handled |
| Verified restore | No | Not built in | Yes |
| Dependency sequencing | No | No | Yes |
| Isolation from source | No | If you build it | By design |
| Someone accountable | No | You | Yes |
If you have one lakehouse, an engineer with time, and low regulatory pressure, the DIY copy is a reasonable place to start. If a failed recovery threatens reporting a board or an auditor depends on — or if nobody on your team wants to own the restore at 2 a.m. — that's where a managed tier earns its cost.
Frequently asked questions
Does Microsoft Fabric back up lakehouses automatically?
No. There is no scheduled, versioned backup for a lakehouse and no point-in-time restore feature (warehouses gained restore points in 2026; lakehouses did not). Fabric does give narrow native protection: a deleted lakehouse can be restored from the recycle bin within a retention window (item recovery, 3–90 days), OneLake soft delete keeps deleted files for seven days, Delta time-travel covers overwrites within retained history, and region redundancy protects data durability. But every one of those is in-place and time-boxed — none is a managed, versioned backup you hold, none restores to an earlier point or into another capacity, and unsupported items like Power BI semantic models aren't covered at all.
What is the difference between a restore point and a backup?
A restore point (warehouse only) is an in-place rewind: it overwrites the current state, references data still in OneLake, and expires (retention caps at 120 days). It is not an independent copy. A backup is a separate copy, kept in storage you control, that you can restore even if the original is gone. A lakehouse has neither natively.
Can I recover a dropped lakehouse table in Fabric?
Sometimes, within a window. OneLake soft delete retains a deleted file for seven days, so a recently dropped table's files may be recoverable; Delta time-travel can roll back an overwrite while that history is retained; Azure Storage Explorer can pull specific files or tables back; and a deleted lakehouse item itself can be restored from the recycle bin within the item-retention window (3–90 days). Past those windows, or to reach an earlier point in time you didn't catch, recovery depends on a copy you made yourself or a managed backup that captured it.
Is copying Delta files to blob storage a real backup?
It is a copy. It becomes a backup when it is scheduled, versioned, kept in storage isolated from the source, and — most importantly — you have verified that it actually restores. A copy you have never restored is a hope, not a backup.
How often should I back up a Fabric lakehouse?
As often as your recovery point objective (RPO) demands: how much data you can afford to lose. For reporting refreshed daily, a daily backup is usually enough; for operational data, hourly or better. The honest test is the interval you would be comfortable explaining after an incident.