The short answer
Designing enterprise disaster recovery (DR) for Azure Synapse Dedicated SQL Pool requires understanding the recovery mechanisms provided by Azure Storage and compute provisioning.
Primary Region (East US) Secondary Region (West US)
+------------------------+ +------------------------+
| Synapse Dedicated Pool | | Azure Storage |
| Active Production DW | | Geo-replicated backup |
+------------------------+ +------------------------+
| |
v automated 8-hour geo-backup v RESTORE DATABASE
+------------------------+ +------------------------+
| Storage Snapshots | --------------> | Restored DW Pool |
| Daily primary snaps | Azure Backbone | Secondary DR Cluster |
+------------------------+ +------------------------+Geo-backups and Geo-Restore (Cold Standby)
By default, Azure Synapse takes automated snapshots of your dedicated SQL pool throughout the day. In addition, it creates an automated geo-backup roughly once every 8 hours and replicates it to the paired Azure region (for example, East US replicates to West US) via geo-redundant storage (RA-GRS).
If a catastrophic regional outage occurs:
- The data engineering team initiates a Geo-Restore in the secondary region using PowerShell or Azure CLI.
- Synapse provisions a new Dedicated SQL Pool in the target region and restores the database from the replicated geo-backup.
This approach is highly cost-effective because you do not pay for idle compute in the secondary region. However, the Recovery Point Objective (RPO) is up to 8 hours (the geo-backup frequency), and the Recovery Time Objective (RTO) is 2 to 4 hours to provision hardware and hydrate storage.
Warm Standby Architecture
For organizations with an RTO under 30 minutes:
- Maintain an existing Dedicated SQL Pool in the secondary region at a minimal compute level (DW100c).
- Use Azure Data Factory pipelines to write incoming curated Parquet files to dual ADLS Gen2 storage accounts in both regions simultaneously.
- Run parallel automated ingestion into both warehouses.