Applies toDatabricks on Azure, AWS and GCP with Unity Catalog
What Databricks does and doesn't replicate
A workspace lives in one region. Databricks does not fail it over to another region for you. Plan these pieces yourself:
| Asset | DR method |
|---|---|
| Notebooks, code, jobs, pipelines | Git + Databricks Asset Bundles (DABs) deployed to both workspaces |
| Cluster policies, pools, warehouses | Terraform / DABs |
| Unity Catalog metastore | One metastore per region; recreate catalogs, schemas, grants with Terraform |
| Managed and external table data | Deep clone, or storage replication, or re-ingest from source |
| Secrets | Recreate from the source vault (Key Vault / Secrets Manager) in the DR region |
| Users and groups | SCIM from your identity provider into the account (account-level, so not per region) |
| Streaming checkpoints | Not portable between regions; restart streams from source offsets |
1. Infrastructure as code for both regions
databricks bundle deploy -t prod-primary
databricks bundle deploy -t prod-dr # jobs deployed paused in DR
Keep DR jobs paused (pause_status: PAUSED) so they don't double-process.
2. Data replication options
| Option | RPO | Notes |
|---|---|---|
| Delta deep clone job, scheduled | The clone interval | Incremental after the first run; works for UC tables |
| Storage geo-replication (GRS/CRR) of external tables | Minutes | Delta log and files copy separately, so validate table consistency after failover |
| Delta Sharing to the DR metastore | Near-real-time reads | DR reads primary data; it doesn't help if the primary region's storage is down |
| Re-ingest from sources | Depends on source retention | Simplest when sources keep history |
CREATE OR REPLACE TABLE dr_catalog.sales.orders
DEEP CLONE prod_catalog.sales.orders;
Running this command again later copies only the new files.
3. Grants and catalogs
Manage databricks_catalog, databricks_schema and databricks_grants in Terraform, and apply the same modules to the DR metastore, so permissions match.
4. Failover runbook
- Declare DR. Stop primary jobs if the primary is still reachable.
- Confirm the DR data's freshness (last clone time). Run a catch-up ingest from sources if needed.
- Unpause DR jobs in dependency order.
- Repoint BI tools and apps to the DR SQL warehouse hostnames (keep these in DNS CNAMEs or config).
- Restart streaming from source offsets or timestamps.
- Communicate data freshness to consumers.
5. Failback
Clone or re-ingest back to the primary, pause DR jobs, and unpause the primary jobs.
Tip
Test DR by running one critical pipeline end to end in the DR workspace each quarter. Most DR failures are a missing secret, a missing grant, or a network rule to a source system, not the data copy.