Disaster recovery guidance
Experience-Specific Recovery Procedures for Planning in Fabric IQ
Overview
This guide provides disaster recovery (DR) guidance specific to Plan items in Fabric IQ.
Plan Architecture in Fabric
Understanding which components belong to which Fabric layer is essential for DR planning. The diagram illustrates the full component map and which elements are replicated automatically versus those requiring manual backup strategies.
The key components and their DR characteristics are:
Plan templates & app definitions - stored as Fabric items. Not automatically replicated to the secondary region.
Plan writeback data - stored in a Fabric SQL database. Requires regular SqlPackage.bacpac exports to geo-redundant storage.
Source/Actuals Data - typically in a lakehouse or via OneLake shortcuts. Lakehouse data is async-replicated when DR is enabled; shortcuts must be recreated manually.
Semantic models - Power BI datasets. Recoverable via Git(.pbip) or PBIX backup.
Approval workflows & cell-Level comments - stored as item metadata. Not replicated, must be recreated manually.
Refresh schedules & execution history - workspace-level configuration. Not replicated.
Sample Scenario
You have a Fabric capacity C1 in Region A with a workspace W1. Disaster Recovery is enabled for C1, so OneLake data is asynchronously replicated to Region B. If Region A becomes unavailable, the Fabric service fails over to Region B.
The general recovery plan is:
1. Create a new Fabric capacity C2 in a new healthy region.
2. Create a new workspace W2 in C2 with the same name as W1.
3. Restore the Fabric SQL database holding plan writeback data.
4. Restore plan item definitions from Git (recommended) or manually recreate them.
5. Reconnect semantic models and lakehouse references to restored items.
6. Validate plan data, re-establish approval workflows, and republish to users.
Note: This recovery guidance assumes the tenant home region remains operational. If the tenant home region is also affected, these steps are contingent on Microsoft restoring it first.
RTO / RPO Summary
The table below summarizes the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for each plan component, depending on the DR strategy used. Color coding indicates relative risk level.
Tip: The fastest path to low RTO and RPO is to combine Fabric Git integration (for item definitions) with a regular SqlPackage export schedule (for writeback data) stored in a geo-redundant location.
Plan items
Plan templates and app definitions
Plan item definitions, including planning templates, input forms, driver models, and app configurations, are stored as Fabric items in the workspace. These items are NOT automatically replicated to the secondary region. To recover them, use Fabric Git integration.
Approach 1: Git integration (Recommended)
The preferred approach is to synchronize all plan items with an Azure DevOps (ADO) or GitHub repository using Fabric Git integration. After failover, the repository is used to rebuild items in the new workspace. The diagram illustrates this workflow.
Pre-disaster(proactive steps):
1. In workspace W1, go to Workspace Settings and configure Git integration.
2. Select Connect and Sync with your ADO or GitHub repository.
3. Confirm that all Lumel Plan items appear as synced in the Source Control panel.
4. Establish a commit discipline - commit after every significant change to a plan definition so the repo always reflects the latest state.
Post-disaster (recovery steps):
1. Create a new workspace W2 inside capacity C2 in the healthy region.
2. In W2, go to Workspace Settings and reconnect to the same ADO/GitHub repository.
3. Select the relevant branch and select Update All. All Lumel Plan items are downloaded to W2.
4. After items are restored, reconnect each plan to its Fabric SQL writeback database (see Writeback Data section) and to the recovered semantic model.
5. Recreate any scheduled refreshes and notification rules manually in W2, as these are not stored in Git.
Tip: Use the same workspace name (W1) in the new region whenever possible. Many plan configurations reference workspace names, and reusing the name minimises the number of reconnection steps.
Approach 2: Manual Recreation
If Git integration was not configured before the disaster, plan item definitions must be recreated manually.
1. In new workspace W2, create each plan item (budget template, forecast model, etc.) with the same names and configurations as the originals.
2. Re-enter driver assumptions, calculation rules, dimension hierarchies, and approval stages based on documentation or knowledge held by finance/planning administrators.
3. Reconnect each item to the restored Fabric SQL database and semantic model.
Note: Manual recreation is time-consuming and error-prone. Adopting Git integration before a disaster occurs is strongly recommended.
Plan writeback data (SQL Database)
All plan inputs, such as budget entries, forecast adjustments, scenario values, and approvals, are written back to a Fabric SQL database in the workspace. This database is the source of truth for all plan data. Recovering it is the highest-priority step in any DR scenario. The diagram illustrates the full backup and restore workflow.
Proactive backup with SqlPackage
Schedule regular exports of the Fabric SQL writeback database to a .bacpac file. Store the file in a geo-redundant location outside the primary region.
1. Install the SqlPackage CLI.
2. Export the writeback database on a schedule that matches your RPO target (for example, daily or after each planning cycle close):
sqlpackage /Action:Export /SourceConnectionString:"<your-fabric-sql-connection-string>" /TargetFile:"lumel_plan_backup_YYYYMMDD.bacpac"
3. Store the .bacpac file in one of the following geo-redundant locations:
A lakehouse in a different Fabric region.
An Azure Blob Storage account with geo-redundant storage (GRS) enabled.
Another secure cloud storage location outside the primary region.
Note: The exported .bacpac file reflects the state of plan data at the time of export. Any plan entries made after the last export will need to be re-entered manually or sourced from audit logs if available.
Restoring the Writeback database
1. In new workspace W2 (in capacity C2, healthy region), create a new Fabric SQL database with the same name as the original writeback database.
2. Use SqlPackage to import from the latest .bacpac file:
sqlpackage /Action:Import /TargetConnectionString:"<new-fabric-sql-connection-string>" /SourceFile:"lumel_plan_backup_YYYYMMDD.bacpac"
3. Validate row counts and key plan tables (budget entries, forecast lines, scenario snapshots, approval status) against pre-disaster records.
4. Reconnect the restored plan items in W2 to this new Fabric SQL database via the plan connection settings.
Note: The restored database is independent of the original. Any data entered after the last backup export will not be present. If the primary region recovers, a manual reconciliation step between the recovered original and the restored copy is required before failing back.
Approval workflows and cell-level comments
Approval workflows and cell-level comments are stored as metadata within plan items. This metadata is notreplicated to the secondary region and cannot be automatically restored.
To minimize data loss:
• Export or screenshot pending approvals and open comments before a planned maintenance window or when DR risk is elevated.
• After recovery, manually recreate active approval workflows by re-assigning reviewers and contributors in the restored plan items.
• Completed approval history captured in the writeback database (if your configuration writes approval status to SQL) will be recovered with the .bacpac restore.
Scheduled refreshes and execution history
Plan refresh schedules including on-change triggers and scheduled downstream plan updates are configured at the workspace level and are not replicated to the secondary region. Execution history is also not recoverable.
After recovery:
1. Manually recreate all plan refresh schedules in workspace W2.
2. Re-enable on-change cascade triggers between linked plans (e.g. revenue plan driving headcount plan).
3. Accept that historical execution logs and metrics will start fresh from the recovery date. Set a new baseline for monitoring thresholds.
Tip: Document your schedule configuration (refresh times, cascade dependencies, notification recipients) in a shared location outside Fabric such as a SharePoint page or a committed file in the Git repository so it can be quickly referenced during recovery.
Source data and semantic models
OneLake Source Data (Lakehouse)
Plan reads actuals and reference data directly from lakehouse tables via semantic models. Lakehouse data in OneLake enabled capacities is asynchronously replicated to the paired region when DR is enabled.
To recover lakehouse source data, see the Lakehouse section.
After lakehouse recovery, reconnect the recovered lakehouse to the semantic model and verify that plan can read actuals data correctly before re-opening plans for input.
External data via OneLake shortcuts
Plan supports reading data from external platforms such as Snowflake, Databricks, Google BigQuery, SAP, Oracle via OneLake shortcuts and mirroring. These connections are not replicated.
After recovery:
1. Recreate OneLake shortcuts in W2, pointing to the same external data sources.
2. If the external source systems are also affected by the regional disaster, follow the respective vendor DR procedures before attempting to reconnect.
3. Validate that semantic models resolve correctly after shortcuts are restored.
Power BI Semantic Models
Plan builds planning grids and input forms directly on top of Power BI semantic models. These models must be restored before plan items can function correctly in the recovered workspace.
Semantic model recovery options:
Git Integration: If the semantic model's .pbip files are committed to the same ADO/GitHub repository used for plan items, they are restored automatically during the Git sync step.
PBIX/PBIP backup: Maintain a regularly updated copy of each semantic model in a version-controlled or geo-redundant location. Import into W2 after recovery.
After restoring the semantic model in W2, open each plan item and confirm that the semantic model binding is pointing to the newly restored model (not the unavailable original in W1).
Recovery checklist & flow
The diagram shows the recommended execution sequence for recovering a plan deployment. Estimated times are indicative and will vary with data volume and environment complexity.
Use the checklist below when executing disaster recovery for a plan deployment.
Phase 1 - Infrastructure
Create new Fabric capacity C2 in a healthy region.
Create new workspace W2 in C2 (use same name as W1 if possible).
Phase 2 - Data restoration
Recover Lakehouse source data (ABFS script or Azure Storage Explorer).
Restore Fabric SQL writeback database using SqlPackage and latest .bacpac.
Validate row counts and key plan data tables.
Phase 3 - Item recovery
Connect W2 to the Git repository and sync to restore plan items and semantic models.
Re-enter or import semantic model PBIX/PBIP if not in Git.
Recreate OneLake shortcuts to external sources (Snowflake, SAP, etc.).
Phase 4 - Reconnection and validation
Reconnect each plan item to the restored Fabric SQL database.
Confirm semantic model bindings in each plan item.
Validate that actuals data flows correctly from Lakehouse into plan grids.
Reconcile any plan data entered after the last .bacpac backup export.
Phase 5 - Configuration and Go-Live
Recreate approval workflows and re-assign contributors and reviewers.
Recreate scheduled refreshes and cascade triggers.
Update application connection strings and URLs distributed to end users.
Notify planning team of recovery completion and any data gaps to address.
Establish new monitoring baseline for refresh metrics and error alerts.
Proactive best practices
The following practices, when implemented before a disaster, significantly reduce recovery time and data loss.
Enable Fabric DR at the capacity level to trigger async OneLake replication to the paired Azure region.
Commit all plan items, semantic models(.pbip), and workspace configuration to a Git repository. Set up automated commits or enforce a commit-on-save policy.
Schedule SqlPackage exports of the Fabric SQL writeback database on a cadence aligned to your RPO at minimum daily during active planning cycles. Store exports in a geo-redundant Azure Storage account or a lakehouse in a different region.
Document all plan configuration outside Fabric: refresh schedules, approval role assignments, cascade dependencies, and data source connection strings.
For critical planning cycles (annual budget, quarterly reforecast), take a manual SqlPackage export immediately before and after the cycle closes.
Test recovery procedures at least annually in a non-production environment to confirm that .bacpac restores and Git syncs complete within target RTO.
If operating in a region that does not have an Azure-paired secondary region, implement a secondary Lumel Plan deployment in a separate region as a warm standby.
Related Documentation
Last updated
Was this helpful?