Change how a storage account is replicated

Azure Storage always stores multiple copies of your data to protect it in the face of both planned and unplanned events. These events include transient hardware failures, network or power outages, and massive natural disasters. Data redundancy ensures that your storage account meets the Service-Level Agreement (SLA) for Azure Storage, even in the face of failures.

This article describes the process of changing replication settings for an existing storage account.

Options for changing the replication type

When deciding which redundancy configuration is best for your scenario, consider the tradeoffs between lower costs and higher availability. The factors that help determine which redundancy configuration you should choose include:

• How your data is replicated within the primary region. Data in the primary region can be replicated locally using locally redundant storage (LRS), or across Azure availability zones using zone-redundant storage (ZRS).
• Whether your data is geo-replicated. Geo-replication provides protection against regional disasters by replicating your data to a second region that is geographically distant to the primary region. Geo-replicated configurations include geo-redundant storage (GRS) and geo-zone-redundant storage (GZRS).
• Whether your application requires read access to the replicated data in the secondary region. You can configure your storage account to allow read access to data replicated to the secondary region if the primary region becomes unavailable for any reason. Configurations that provide read access to data in the secondary region include read-access geo-redundant storage (RA-GRS) and read-access geo-zone-redundant storage (RA-GZRS).

For a detailed overview of all of the redundancy options, see Azure Storage redundancy.

You can change your storage account's redundancy configurations as needed, though some configurations are subject to limitations and downtime requirements. Reviewing these limitations and requirements before making any changes within your environment helps avoid conflicts with your own timeframe and uptime requirements.

There are two ways to change the replication settings:

• Add or remove geo-replication or read access to the secondary region.
• Perform a manual migration in scenarios where the first option aren't supported, or to ensure the change is completed within a specific timeframe.

Geo-redundancy and read-access can be changed at the same time. However, any change that also involves zone-redundancy requires a conversion and must be performed separately using a two-step process. These two steps can be performed in any order.

Change the replication setting

Change the redundancy configuration using Azure portal, PowerShell, or Azure CLI

In most cases you can use the Azure portal, PowerShell, or the Azure CLI to change the geo-redundant or read access (RA) replication setting for a storage account.

Changing how your storage account is replicated in the Azure portal doesn't result in down time for your applications, including changes that require a conversion.

Set-AzStorageAccount -ResourceGroupName <resource_group> `
    -Name <storage_account> `
    -SkuName <sku>

az storage account update \
    --name <storage-account> \
    --resource-group <resource_group> \
    --sku <sku>

Manual migration

A manual migration provides more flexibility and control than a conversion. You can use this option if you need your data moved by a certain date, or if conversion isn't supported for your scenario. Manual migration is also useful when moving a storage account to another region. For more detail, see Move an Azure Storage account to another region.

You must perform a manual migration if:

• You want to migrate your storage account to a different region.
• Your storage account is a block blob account.
• Your storage account includes data in the archive tier and rehydrating the data isn't desired.

With a manual migration, you copy the data from your existing storage account to a new storage account. To perform a manual migration, you can use one of the following options:

• Copy data by using an existing tool such as AzCopy, one of the Azure Storage client libraries, or a reliable non-Microsoft tool.
• If you're familiar with Hadoop or HDInsight, you can attach both the source storage account and destination storage account to your cluster. Then, parallelize the data copy process with a tool like DistCp.

For more detailed guidance on how to perform a manual migration, see Move an Azure Storage account to another region.

Limitations for changing replication types

Limitations apply to some replication change scenarios depending on:

• Region
• Feature conflicts
• Storage account type
• Access tier

Region

Make sure the region where your storage account is located supports all of the desired replication settings. For example, if you're converting your account to zone-redundant (ZRS, GZRS, or RA-GZRS), make sure your storage account is in a region that supports it. See the lists of supported regions for Zone-redundant storage and Geo-zone-redundant storage.

Feature conflicts

Some storage account features aren't compatible with other features or operations. For example, the ability to fail over to the secondary region is the key feature of geo-redundancy, but other features aren't compatible with failover. For more information about features and services not supported with failover, see Unsupported features and services. The conversion of an account to GRS, GZRS, or RA-GZRS might be blocked if a conflicting feature is enabled, or it might be necessary to disable the feature later before initiating a failover.

Boot diagnostics doesn't support premium storage accounts or zone-redundant storage accounts. When either premium or zone-redundant storage accounts are used for boot diagnostics, users receive a StorageAccountTypeNotSupported error upon starting their virtual machine (VM).

Storage account type

When planning to change your replication settings, consider the following limitations related to the storage account type.

Some storage account types only support certain redundancy configurations, which affect whether they can be converted or migrated and, if so, how. For more information on Azure storage account types and the supported redundancy options, see the storage account overview.

The following table provides an overview of redundancy options available for storage account types and whether manual migration is supported:

¹ Managed disks are available for LRS and ZRS, though ZRS disks have some limitations. If an LRS disk is regional (no zone specified), it can be converted by changing the SKU. If an LRS disk is zonal, then it can only be manually migrated by following the process in Migrate your managed disks. You can store snapshots and images for standard SSD managed disks on standard HDD storage and choose between LRS and ZRS options. For information about integration with availability sets, see Introduction to Azure managed disks.
² ZRS Classic storage accounts are deprecated. For information about converting ZRS Classic accounts, see Converting ZRS Classic accounts.

Converting ZRS Classic accounts

ZRS Classic was available only for block blobs in general-purpose V1 (GPv1) storage accounts. For more information about storage accounts, see Azure storage account overview.

ZRS Classic accounts asynchronously replicated data across data centers within one to two regions. Replicated data wasn't available unless Microsoft initiated a failover to the secondary. A ZRS Classic account can't be converted to or from LRS, GRS, or RA-GRS. ZRS Classic accounts also don't support metrics or logging.

To change ZRS Classic to another replication type, use one of the following methods:

• Upgrade it to ZRS first
• Manually migrate the data directly to another replication type

To upgrade your ZRS Classic storage account to ZRS, use the Azure portal, PowerShell, or Azure CLI in regions where ZRS is available:

Set-AzStorageAccount -ResourceGroupName <resource_group> -AccountName <storage_account> -UpgradeToStorageV2

az storage account update -g <resource_group> -n <storage_account> --set kind=StorageV2

To manually migrate your ZRS Classic account data to another type of replication, follow the steps to perform a manual migration.

If you want to migrate your data into a zone-redundant storage account located in a region different from the source account, you must perform a manual migration. For more information, see Move an Azure Storage account to another region.

Access tier

Make sure the desired redundancy option supports the access tiers currently used in the storage account. For example, ZRS, GZRS and RA-GZRS storage accounts don't support the archive tier. For more information, see Hot, Cool, and Archive access tiers for blob data. To convert an LRS, GRS or RA-GRS account to one that supports zone-redundancy, first move the archived blobs to a storage account that supports blobs in the archive tier. Then convert the source account to ZRS, GZRS, and RA-GZRS.

An LRS storage account containing blobs in the archive tier can be switched to GRS or RA-GRS after rehydrating all archived blobs to the Hot or Cool tier. You can also perform a manual migration.

Downtime requirements

If you choose to perform a manual migration, downtime is required but you have more control over the timing of the migration process.

Costs associated with changing how data is replicated

Azure Storage offers several options for configuring replication. These options, ordered by least- to most-expensive, include:

• LRS
• ZRS
• GRS
• RA-GRS
• GZRS
• RA-GZRS

The costs associated with changing how data is replicated in your storage account depend on which aspects of your redundancy configuration you change. A combination of data storage and egress bandwidth pricing determines the cost of making a change. For details on pricing, see Azure Storage Pricing page.

Geo-redundancy incurs an egress bandwidth charge at the time of the change because your entire storage account is being replicated to the secondary region. All subsequent writes to the primary region also incur egress bandwidth charges to replicate the write to the secondary region.

If you remove geo-redundancy (change from GRS to LRS), there's no cost for making the change, but your replicated data is deleted from the secondary location.

See also

• Azure Storage redundancy
• Use geo-redundancy to design highly available applications
• Move an Azure Storage account to another region
• Check the Last Sync Time property for a storage account