Home / Azure

AzureRunbookIntermediate

Azure Storage DR: GRS/GZRS, Last Sync Time and customer-managed failover

How geo-redundant storage replicates, how to read from the secondary, how to check Last Sync Time and run a customer-managed failover, and what to do afterwards.

Deepak Bhardwaj2 min read

Applies toAzure Storage accounts (StorageV2) with GRS, RA-GRS, GZRS or RA-GZRS

How it works

  • Data is written synchronously in the primary region (3 copies LRS or ZRS), then copied asynchronously to the paired secondary region.
  • RA- SKUs let you read from the secondary endpoint at any time: https://<account>-secondary.blob.core.windows.net.
  • Last Sync Time is the point up to which all writes are guaranteed to be in the secondary. Writes after it may be lost on failover.

1. Check replication status

az storage account show -g rg-data -n stcustdataprodcin --expand geoReplicationStats \
  --query "{sku:sku.name, status:geoReplicationStats.status, lastSync:geoReplicationStats.lastSyncTime, canFailover:geoReplicationStats.canFailover}"

Alert if Last Sync Time is older than your RPO (for example 15 minutes).

2. Read-only DR mode (no failover)

With RA-GRS/RA-GZRS, applications can switch to reading from the secondary endpoint during a primary outage. Many SDKs support a secondary host for reads (for example GeoRedundantSecondaryUri in the .NET Blob client options). Writes stay unavailable until the primary recovers or you fail over.

3. Customer-managed failover

az storage account failover -g rg-data -n stcustdataprodcin --yes
  • Unplanned failover: the secondary becomes primary; data after Last Sync Time can be lost. The account becomes LRS in the new primary region afterwards.
  • Planned failover (where available) keeps geo-redundancy and avoids data loss, for drills and planned moves. Check current availability for your account type and region.
  • Takes typically up to an hour. DNS for the account endpoints is updated to the new region.

4. After an unplanned failover

  1. Verify applications (endpoints are the same names, now pointing to the new region).
  2. Reconfigure geo-redundancy (back to GRS/GZRS) so the data is protected again. This starts a full copy to the new secondary.
  3. Check private endpoints: create private endpoints in the DR region VNet if the apps run there.
  4. Plan failback later (another failover) if required.

What failover doesn't cover

Scenario Protection needed
Accidental delete / overwrite Soft delete, versioning, point-in-time restore (deletes replicate to the secondary too)
Ransomware encryption Immutability policies, versioning, backups to a separate account/vault
Need for a different region than the pair Object replication to another account 
az storage account or-policy create -g rg-data --account-name stsrc --destination-account stdst \
  --source-container docs --destination-container docs --min-creation-time '2026-10-01T00:00:00Z'

Warning

Geo-replication is not a backup. A deleted container is deleted in both regions within minutes. Keep soft delete and versioning on, whatever the redundancy.

Related fixes