/azure-reliability

Configure Storage Redundancy

Overview

Storage accounts must match or exceed the redundancy level of the compute they support. Zone-redundant compute requires at minimum ZRS storage.

Upgrade Paths

In-Place Upgrade (LRS → GRS/GZRS)

GRS and GZRS upgrades can be done in-place immediately:

# Upgrade to GZRS (zone + region redundant — recommended)
az storage account update \
  --name <account-name> \
  --resource-group <rg> \
  --sku Standard_GZRS

# Upgrade to GRS (region redundant only — NOT zone redundant)
az storage account update \
  --name <account-name> \
  --resource-group <rg> \
  --sku Standard_GRS

Live Migration (LRS → ZRS)

ZRS conversion uses the storage account migration API (not --sku update):

# Check if account supports live migration
# Requirements: Standard general-purpose v2, in a supported region
az storage account show \
  --name <account-name> \
  --resource-group <rg> \
  --query "{name:name, sku:sku.name, kind:kind}"

# Start live migration to ZRS
az storage account migration start \
  --account-name <account-name> \
  -g <rg> \
  --sku Standard_ZRS \
  --name default \
  --no-wait

# Monitor migration status (can take hours to days)
az storage account migration show \
  --account-name <account-name> \
  -g <rg> \
  --migration-name default \
  --query "migrationStatus"

⛔ HARD GATE: Do NOT proceed to enable zone-redundant compute until migration status is Succeeded and az storage account show --query sku.name returns Standard_ZRS.

⚠️ Live migration limitations:

• Only supported for Standard general-purpose v2 accounts
• Premium storage accounts require manual migration
• BlobStorage and Storage (classic) kinds require manual migration
• Migration can take hours to days depending on data volume
• Account remains accessible during migration

Manual Migration (When Live Migration Not Available)

For Premium_LRS or unsupported account types:

# 1. Create new ZRS storage account
az storage account create \
  --name <new-account-name> \
  --resource-group <rg> \
  --location <location> \
  --sku Standard_ZRS \
  --kind StorageV2

For Function Apps (special handling required)

Function App host storage uses blobs, queues, tables, and potentially files. A simple blob-only copy is NOT sufficient.

⛔ Full Function App storage migration workflow:

# 1. Stop the function app to quiesce triggers and drain orchestrations
az functionapp stop --name <app-name> --resource-group <rg>

# 2. If using Durable Functions, wait for all orchestrations to complete
#    or terminate them before proceeding

# 3. Copy ALL storage services (blobs, queues, tables) using AzCopy
#    Authenticate first:
azcopy login

#    Copy blobs:
azcopy copy \
  "https://<old-account>.blob.core.windows.net/*" \
  "https://<new-account>.blob.core.windows.net/" \
  --recursive

#    Note: AzCopy does not support table/queue copy directly.
#    Use Azure Data Factory or Storage Explorer for tables/queues if needed.

# 4. Get new storage connection string
az storage account show-connection-string \
  --name <new-account-name> \
  --resource-group <rg> \
  --query connectionString -o tsv

# 5. Update app settings to point to new storage
az functionapp config appsettings set \
  --name <app-name> \
  --resource-group <rg> \
  --settings "AzureWebJobsStorage=<new-connection-string>"

# 6. Start the function app
az functionapp start --name <app-name> --resource-group <rg>

# 7. Verify app works — check logs, test triggers
az functionapp show --name <app-name> --resource-group <rg> --query "state"

# 8. Only delete old storage after confirming everything works

⚠️ Warn user: This involves app downtime. For zero-downtime migration, use live migration (Standard_ZRS) instead.

For non-Function App workloads (simpler)

# Copy blobs
azcopy login
azcopy copy \
  "https://<old-account>.blob.core.windows.net/*" \
  "https://<new-account>.blob.core.windows.net/" \
  --recursive

# Update app connection strings as needed
# Delete old account after verification

Function App Storage Considerations

Function Apps have a host storage account used for:

• Function code storage
• Timer trigger leases
• Event Hub checkpoints
• Durable Functions state

Critical: When upgrading Function App storage:

• The AzureWebJobsStorage connection string must point to the upgraded/new account
• If using a separate deployment storage account, upgrade that too
• Durable Functions state is stored in the host storage — ensure no active orchestrations during manual migration

# Check current storage connection
az functionapp config appsettings list \
  --name <app-name> \
  --resource-group <rg> \
  --query "[?name=='AzureWebJobsStorage'].value" -o tsv

Verification

az graph query -q "
Resources
| where resourceGroup =~ '<rg>'
| where type =~ 'microsoft.storage/storageaccounts'
| project name, replication=sku.name, kind
" -o table

Expected: All accounts show Standard_ZRS, Standard_GZRS, or Premium_ZRS.