Fabric disaster recovery is not one switch. A critical workload can include source systems, gateways, pipelines, notebooks, environments, lakehouses, warehouses, KQL databases, semantic models, reports, identities, secrets, workspace roles, capacities, APIs, embedded applications, alerts, and downstream consumers. These components do not share one recovery mechanism or one failure boundary.
Datrick builds recovery confidence from evidence. AI can accelerate inventory, dependency mapping, runbook comparison, log correlation, test-case generation, reconciliation analysis, and drill reporting. It cannot declare a workload recovered without deterministic data checks, security validation, application transactions, accountable business acceptance, and measured recovery time.
Is OneLake DR enabled but nobody can explain how the complete workload returns to service? Start with one critical domain and an item-by-item recovery contract.
Define business recovery objectives by workload
Start with business impact, not platform features. Identify critical decisions and processes, users, operating windows, data cutoff, maximum tolerable outage, maximum tolerable data loss, legal and contractual obligations, dependent services, communication owners, manual workarounds, and return-to-normal criteria. Set RPO and RTO for the complete service, then decompose them across each component.
Separate high availability, backup, deletion recovery, configuration reconstruction, regional disaster recovery, cyber recovery, and business continuity. A redundant service may survive hardware failure but not a bad deployment. Geo-replication may preserve recent data but copy logical corruption. Source control may recreate an item definition but not its data, permissions, secrets, or operational history.
Create an item-by-item recovery coverage matrix
| Recovery layer | Evidence required | Question to prove |
|---|---|---|
| OneLake data | Capacity DR setting, supported region pair, replication evidence, BCDR storage and operations, data scope, lag assumption, cost, and post-failover behavior. | Which data is geo-replicated, what can be lost, and how is integrity verified after failover? |
| Item definitions and code | Git repositories, deployment artifacts, export or API coverage, versions, environment parameters, dependencies, and reproducible deployment tests. | Can every critical definition be reconstructed without relying on the failed workspace? |
| External and non-OneLake data | Source recovery, KQL and item-specific behavior, shortcuts, mirrored sources, external storage, SaaS dependencies, and ownership. | Which data needs a separate protection and recovery path? |
| Identity and configuration | Groups, roles, service principals, managed identities, secrets, gateways, connections, credentials, tenant settings, labels, sharing, and endpoints. | Can access and connectivity be restored without weakening security? |
| Orchestration and operations | Schedules, triggers, monitoring, alerts, incident routing, capacity assignment, runbooks, contacts, vendor escalation, and freeze criteria. | Can processing resume in dependency order without duplicate or missing work? |
| Business validation | Record counts, checksums, balances, KPIs, freshness, security personas, API tests, reports, downstream exports, and owner sign-off. | Does restored service produce approved business outcomes, not only healthy infrastructure? |
Microsoft documents that capacity-level DR for supported OneLake scenarios uses asynchronous cross-region replication and a platform-selected Azure region pair. Data not replicated before a disaster can be lost, and coverage depends on Fabric availability in the paired region. Verify that replication has started and monitor BCDR storage and operations rather than assuming the setting is immediately effective.
Use multiple protection layers for different failures
OneLake file soft delete, workspace item recovery for supported types, source-system retention, warehouse or database-specific recovery, deployment artifacts, configuration backups, and regional DR address different risks. Item recovery can require tenant configuration and has item-specific limitations; recovered sharing permissions or dependent behavior may need reconstruction. Record preview status and product changes as operational assumptions that require periodic review.
Protect definitions and configuration independently from data. Keep supported items in source control or reproducible deployment packages, externalize environment configuration, document identities and connections, preserve schema and security expectations, and test rebuilding into a clean workspace. Never store the only usable recovery artifact inside the capacity or workspace it is intended to recover.
Test explicit failure scenarios
| Failure scenario | Recovery action | Acceptance evidence |
|---|---|---|
| Accidental file or item deletion | Stop dependent processing, identify deletion scope, recover through the supported retention path, rebuild missing configuration, and replay safely. | Restored objects, correct data version, permissions, lineage, downstream outputs, and documented recovery time. |
| Bad code or data deployment | Freeze release, identify affected versions and writes, roll back definitions, restore or repair data, and reconcile partial processing. | Matched business results, no duplicate effects, security intact, and monitored return to service. |
| Workspace or capacity loss | Provision approved target, deploy definitions, bind configuration and identities, restore or reconnect data, sequence workloads, and republish endpoints. | Complete inventory restored, users and integrations reconnected, and RPO/RTO measured. |
| Regional Fabric outage | Activate vendor and internal incident paths, assess platform failover state, control writes and dependent systems, validate secondary behavior, and communicate service status. | Known data cutoff, validated read/write behavior, reconciled recovery point, business acceptance, and failback plan. |
| Source or gateway outage | Use source-specific continuity, alternate connectivity, queued ingestion, or approved degraded mode; resume with controlled backfill. | No missed or duplicated periods, freshness communicated, downstream models reconciled, and backlog cleared. |
| Identity compromise or tenant event | Contain access, rotate credentials, deploy clean identities and configuration, review activity, validate data integrity, and restore least privilege. | Compromise removed, audit evidence retained, security tests passed, and approved access restored. |
Run a controlled recovery drill
- Approve scenario, scope, safety constraints, production impact, observers, escalation, abort conditions, and success criteria.
- Capture item inventory, versions, source state, data cutoff, identities, permissions, dependencies, schedules, endpoints, and business baselines.
- Execute a tabletop first, then a non-production technical recovery that uses the actual artifacts, roles, and documented sequence.
- Time detection, declaration, containment, provisioning, data availability, definition deployment, configuration, processing, technical validation, and business acceptance.
- Run record, aggregate, freshness, security-persona, report, API, downstream, and operational tests against approved expected results.
- Record every missing permission, undocumented dependency, manual decision, stale artifact, failed automation, vendor wait, and reconciliation exception.
- Prioritize remediation by business impact and recovery-objective risk, assign owners, then repeat the failed portions.
A drill is not successful because the team followed a document. It is successful when the target service returns within approved objectives, produces correct and authorized outcomes, and leaves sufficient evidence for owners to accept recovery. Preserve a versioned drill record and retest after material architecture, item, region, identity, deployment, or support changes.
Run a two-to-four-week Fabric BCDR assessment
- Define critical workloads, impact tiers, RPO, RTO, recovery owners, regulatory requirements, and approved failure scenarios.
- Inventory Fabric items, data locations, capacities, regions, sources, gateways, identities, code, configuration, endpoints, and downstream dependencies.
- Map current protection and recovery mechanisms to every component and failure scenario; verify settings and retained evidence.
- Identify unsupported, preview, external, manual, stale, or untested recovery paths and quantify their business consequence.
- Design the target recovery architecture, source and artifact protection, alternate environments, identity controls, sequencing, communication, and vendor escalation.
- Create deterministic recovery tests and run one tabletop or controlled technical drill for the highest-value bounded workload.
- Deliver the coverage matrix, risk register, architecture, runbooks, test suite, drill report, remediation roadmap, cost implications, and recurring exercise cadence.
Frequently asked questions
Does Microsoft Fabric have disaster recovery?
Microsoft Fabric provides reliability and recovery capabilities, including capacity-level disaster recovery for supported OneLake data, Power BI continuity behavior, file soft delete, and item recovery for supported item types. Coverage and behavior differ by region, capacity, item, data location, and failure mode. A workload still needs an item-by-item recovery design, dependencies, runbooks, RPO and RTO, and tested business validation.
What does OneLake disaster recovery protect?
When enabled on a supported capacity and region pair, OneLake disaster recovery geo-replicates eligible OneLake data to the paired region. Replication is asynchronous, so data not copied before a regional disaster can be lost. It does not automatically prove recovery of every Fabric item definition, external source, KQL workload, identity, permission, endpoint, orchestration, or dependent application.
Is OneLake soft delete the same as disaster recovery?
No. Soft delete helps recover deleted OneLake files for a retention period, while item recovery can protect supported workspace items when enabled. Regional disaster recovery addresses a different failure class. None of these alone replaces source recovery, deployment artifacts, configuration recovery, permission reconstruction, dependency sequencing, or end-to-end workload validation.
How do you test Microsoft Fabric disaster recovery?
Define approved failure scenarios and expected RPO and RTO, freeze the test scope, capture source and target state, execute a tabletop or controlled technical recovery, restore item definitions, data, configuration, identity, permissions, orchestration, gateways, endpoints, and dependent services in sequence, then validate reconciled data and business transactions. Record timings, gaps, manual steps, evidence, and remediation owners.
How long does a Microsoft Fabric disaster recovery assessment take?
A focused assessment of one critical Fabric workload can often be completed in two to four weeks when item inventory, architecture, source and deployment access, owners, business continuity requirements, and operational evidence are available. Remediation and a technical recovery drill take longer when definitions are not in source control, data exists outside OneLake, identities are manual, dependencies are undocumented, or no secondary environment exists.
Official implementation references
- Microsoft OneLake disaster recovery and data protection
- Microsoft Fabric reliability guidance
- Microsoft Fabric retention and item recovery guidance
- Microsoft Fabric Well-Architected reliability guidance
- Microsoft disaster recovery design guidance
Start with the Fabric workload whose loss would create the largest business interruption. Datrick can map protection gaps, build the recovery contract, run a controlled drill, and deliver an approval-ready remediation plan.