Home / Data Platform / Data Factory

Data PlatformRunbookIntermediate

Azure Data Factory disaster recovery: Git, redeploy to a second region, and the moving parts

Prepare a secondary Data Factory in another region from Git and CI/CD, cover linked services, secrets, integration runtimes and triggers, and run failover without duplicate pipeline runs.

Deepak Bhardwaj2 min read

Applies toAzure Data Factory (and Synapse pipelines) with Git integration

What ADF gives you

ADF's metadata is stored in its region. Microsoft does not offer customer-controlled failover of a data factory to another region, so you keep a deployable copy.

1. Git is the source of truth

  • Development factory connected to Azure Repos or GitHub.
  • Publishing generates ARM templates (or use the @microsoft/azure-data-factory-utilities npm package in CI).
  • One release pipeline deploys the same template to adf-prod-cin (primary) and adf-prod-sin (DR) with different parameter files.
- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    resourceGroupName: rg-data-dr
    location: South India
    csmFile: ARMTemplateForFactory.json
    csmParametersFile: params/dr.json
    overrideParameters: -factoryName adf-prod-sin

2. Parameterise what differs

Item Primary DR
Key Vault URL kv-data-cin kv-data-sin
Storage / lake endpoints primary account GRS secondary, or a DR account
SQL endpoints the failover group listener (same name for both) same listener
Integration runtime shir-cin shir-sin

Use a failover group listener or DNS names that move in DR, so most linked services don't change.

3. Triggers off in DR

Deploy the DR factory with triggers stopped (a CI step that stops triggers after deployment). Otherwise both factories run the same loads.

Get-AzDataFactoryV2Trigger -ResourceGroupName rg-data-dr -DataFactoryName adf-prod-sin |
  ForEach-Object { Stop-AzDataFactoryV2Trigger -ResourceGroupName rg-data-dr -DataFactoryName adf-prod-sin -Name $_.Name -Force }

4. Integration runtimes

  • Azure IR: auto-resolve or region-specific IRs. Check that the DR region has them.
  • Self-hosted IR: install nodes registered to the DR factory in the DR site (see the SHIR HA post), or share one SHIR from a third factory.
  • Managed VNet / private endpoints: recreate them in DR, and approve them on the target resources ahead of time.

5. Failover runbook

  1. Confirm the primary region issue, and stop triggers in the primary if it's reachable.
  2. Fail over dependent data stores (SQL failover group, storage account failover) as needed.
  3. Find the last successful watermark for incremental loads (from a control table in the database, not from ADF run history).
  4. Start triggers in the DR factory, or run catch-up pipelines manually.
  5. Monitor the first runs. Check SHIR nodes are online and private endpoints are approved.

6. Failback

Stop DR triggers, fail data stores back, then start primary triggers with the current watermarks.

Tip

Keep incremental-load watermarks in a database table that fails over with your data, not in pipeline variables or run history. Then DR runs resume from the right point automatically.

Related fixes