Azure Data Lake Storage disaster recovery: failover, step by step

Yes, an Azure Data Lake Storage Gen2 account can fail over to another region. Accounts with a hierarchical namespace are supported for both kinds of customer-managed failover, planned and unplanned, as long as the account uses geo-redundant storage (GRS, RA-GRS, GZRS or RA-GZRS). The account keeps its endpoint names: Azure points the same dfs.core.windows.net address at the new region.

Many older answers say ADLS Gen2 cannot fail over, or only behind a preview flag. That is out of date. What has not changed is the hard part: deciding how much data you can afford to lose, and what replication does not protect you from.

What each redundancy option survives

Microsoft recommends ZRS in the primary region for Data Lake workloads, so for a lake that must survive a region, GZRS is the usual pick. The "RA" versions add read access to the secondary through a -secondary endpoint while the primary is still up.

Try itWhat your lake's redundancy survives

Redundancy

·LRS·ZRS·GRS·GZRS

Incident

·A rack fails·A datacenter burns·A zone goes down·The region goes down·Someone deletes a folder

Ingest (GB an hour)

200

Last Sync Time behind (minutes)

12

• A rack failssurvives
• A datacenter burnssurvives
• A zone goes downsurvives
• The region goes downafter failover
• Someone deletes a folderrestore

Survives after a failoverAbout 40 GB to replay

3 kinds of failover

• Planned (customer-managed). Both regions are healthy. Azure finishes copying everything, then swaps primary and secondary. No data is lost, geo-redundancy is kept, and you fail back the same way. Use it to test your plan, and when a disaster such as a hurricane is forecast for the primary region.
• Unplanned (customer-managed). The primary region's storage endpoints are down and you choose to move. Writes not yet copied are lost. The account becomes locally redundant (LRS) in the new region and the copy in the old region is deleted.
• Microsoft-managed. Microsoft fails over a whole region only after a severe disaster, and never for a single account. Microsoft's own advice is not to rely on it.

A failover typically finishes in under an hour.

How much an unplanned failover loses

Replication to the secondary region is asynchronous. The account's Last Sync Time says up to when every write is safely in the secondary; anything after it may be lost. For ADLS accounts, the same Last Sync Time covers the namespace's metadata, including ACLs.

az storage account show \
  --name lakeprod --resource-group data-rg \
  --expand geoReplicationStats \
  --query geoReplicationStats.lastSyncTime

A worked example: a lake ingesting 200 GB an hour, with a Last Sync Time 12 minutes behind when the primary goes down, has about 40 GB of recent files at risk. If your pipelines can replay those 12 minutes from their sources (Kafka retention, the source database, files still in a landing zone), the loss is a re-run, not lost data. Log what each pipeline wrote and when, so you can compare it with the Last Sync Time and know exactly what to replay. For block blobs, Azure also sells geo priority replication, which keeps that gap at 15 minutes or less; check that it covers your account before you count on it.

One ADLS-specific caveat: replication works file by file, so after an unplanned failover, the files inside one directory may not all be from the same moment. A Delta Lake or Iceberg table whose newest data files arrived but whose log commit did not (or the other way round) needs checking before jobs write to it again.

The steps

Before anything goes wrong

1. Put the lake on GZRS (or RA-GZRS).
2. Turn on blob soft delete and container soft delete.
3. Write down what each pipeline can replay, and for how long.
4. Run a planned failover in a test account once, end to end, and time it.

On the day

1. Check Azure's service health and any Azure Advisory about the outage.
2. Read the Last Sync Time and decide whether the loss is acceptable.
3. Fail over:

az storage account failover \
  --name lakeprod --resource-group data-rg \
  --failover-type unplanned

4. Stop writers, check the newest table versions, replay the gap, then restart jobs. The endpoints are the same, so connection strings, mount points and Unity Catalog external locations keep their URLs.

Afterwards

1. Turn geo-redundancy back on (the account is LRS now). That copies the whole lake to a secondary again, which takes time and costs network egress.
2. When the original region is back, check the Last Sync Time again; failing back early can lose the data you wrote during the outage.
3. Fail back with a planned failover.

What failover does not cover

• Mistakes and attacks. A deleted folder or a bad overwrite replicates like any other write. Soft delete is the protection here. Blob versioning, point-in-time restore and object replication are not available on accounts with a hierarchical namespace.
• Your compute. Failing over storage moves the data, not the Databricks workspace, Synapse, Fabric or Data Factory that reads it. They need their own plan in the secondary region, with network access to the account there.
• Some features. NFS 3.0 accounts cannot be geo-redundant, so they cannot fail over. Change feed and point-in-time restore are not supported in a planned failover.

What to do

Check the redundancy of your production lake today. Decide whether a region outage is a risk you must cover, move to GZRS if it is, and test a planned failover before you need an unplanned one. If you are also choosing where the lake's compute runs, Microsoft Fabric vs Databricks compares the 2 on Azure, and our data engineering course builds the pipelines that sit on top. The lake itself is explained in Data LakeData LakeCheap storage that holds data of any kind in its raw form, usually as files in cloud object storage, to be cleaned and structured later..