Change how Azure Files data is replicated
Azure 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 natural disasters. Data redundancy ensures that your storage account meets the Service-Level Agreement (SLA) for Microsoft Online Services.
This article describes the process of changing replication settings for an existing storage account that hosts Azure file shares.
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 requires geo-redundancy. Geo-redundancy provides protection against regional disasters by replicating your data to a second region that is geographically distant to the primary region. Azure Files supports both geo-redundant storage (GRS) and geo-zone-redundant storage (GZRS).
Important
Azure Files doesn't support read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS). If a storage account is configured to use RA-GRS or RA-GZRS, the file shares will be configured and billed as GRS or GZRS.
For a detailed overview of all of the redundancy options for Azure Files, see Azure Files 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 three ways to change the replication settings:
- Add or remove geo-redundancy or read access to the secondary region.
- Add or remove zone-redundancy by performing a conversion.
- Perform a manual migration in scenarios where the first two options 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.
Changing redundancy configuration
The following table provides an overview of how to switch between replication types.
Note
Manual migration is an option for any scenario in which you want to change the replication setting within the limitations for changing replication types. The manual migration option is excluded from the following table for simplification.
| Switching | …to LRS | …to GRS 6 | …to ZRS | …to GZRS 2,6 |
|---|---|---|---|---|
| …from LRS | N/A | Use Azure portal, PowerShell, or CLI 1,2 | Perform a conversion2,3,4,5 | First, use the Portal, PowerShell, or CLI to switch to GRS 1, then perform a conversion to GZRS 3,4,5 |
| …from GRS | Use Azure portal, PowerShell, or CLI | N/A | First, use the Portal, PowerShell, or CLI to switch to LRS, then perform a conversion to ZRS 3,5 | Perform a conversion3,5 |
| …from ZRS | Perform a conversion3 | First, use the Portal, PowerShell, or CLI to switch to GZRS, then perform a conversion to GRS3 | N/A | Use Azure portal, PowerShell, or CLI 1 |
| …from GZRS | First, use the Portal, PowerShell, or CLI to switch to ZRS, then perform a conversion to LRS 3 | Perform a conversion3 | Use Azure portal, PowerShell, or CLI | N/A |
1 Adding geo-redundancy incurs a one-time egress charge.
2 If your storage account contains blobs in the archive tier, review the access tier limitations before changing the redundancy type to geo- or zone-redundant.
3 The type of conversion supported depends on the storage account type. For more information, see the storage account table.
4 Conversion to ZRS or GZRS for an LRS account resulting from a failover isn't supported. For more information, see Failover and failback.
5 Converting from LRS to ZRS isn't supported if the NFSv3 protocol support is enabled for Azure Blob Storage or if the storage account contains Azure Files NFSv4.1 shares with public endpoints enabled.
6 Even though enabling geo-redundancy appears to occur instantaneously, failover to the secondary region can't be initiated until data synchronization between the two regions is complete.
Change the replication setting
Depending on your scenario from the changing redundancy configuration section, use one of the following methods to change your replication settings.
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.
To change the redundancy option for your storage account in the Azure portal, follow these steps:
Navigate to your storage account in the Azure portal.
Under Data management select Redundancy.
Update the Redundancy setting.
Select Save.
Perform a conversion
A redundancy "conversion" is the process of changing the zone-redundancy aspect of a storage account.
During a conversion, there's no data loss or application downtime required.
There are two ways to initiate a conversion:
Tip
Microsoft recommends using a customer-initiated conversion instead of support-initiated conversion whenever possible. A customer-initiated conversion allows you to initiate the conversion and monitor its progress directly from within the Azure portal. Because the conversion is initiated by the customer, there is no need to create and manage a support request.
Customer-initiated conversion
Instead of opening a support request, customers in most regions can start a conversion and monitor its progress. This option eliminates potential delays related to creating and managing support requests. For help determining the regions in which customer-initiated conversion is supported, see the region limitations article.
For standard file shares, customer-initiated conversion can be completed in supported regions using the Azure portal, PowerShell, or the Azure CLI.
For premium file shares, customer-initiated conversion is available through PowerShell and Azure CLI. Or you can request a support-initiated conversion.
After initiation, the conversion could still take up to 72 hours to begin.
Important
There is no SLA for completion of a conversion.
If you need more control over when a conversion begins and finishes, consider a Manual migration. Generally, the more data you have in your account, the longer it takes to replicate that data to other zones or regions.
For more information about the timing of a customer-initiated conversion, see Timing and frequency.
To add or modify a storage account's zonal-redundancy within the Azure portal, perform these steps:
Navigate to your storage account in the Azure portal.
Under Data management select Redundancy.
Update the Redundancy setting.
Select Save.
Monitoring customer-initiated conversion progress
As the conversion request is evaluated and processed, the status should progress through the list shown in the following table:
| Status | Explanation |
|---|---|
| Submitted for conversion | The conversion request was successfully submitted for processing. |
| In Progress1 | The conversion is in progress. |
| Completed - or - Failed2 |
The conversion is completed successfully. - or - The conversion failed. |
1 Once initiated, the conversion could take up to 72 hours to begin. If the conversion doesn't enter the "In Progress" status within 96 hours of initiating the request, submit a support request to Microsoft to determine why. For more information about the timing of a customer-initiated conversion, see Timing and frequency.
2 If the conversion fails, submit a support request to Microsoft to determine the reason for the failure.
Note
While Microsoft handles your request for a conversion promptly, there's no guarantee as to when it will complete. If you need your data converted by a certain date, Microsoft recommends that you perform a manual migration instead.
Generally, the more data you have in your account, the longer it takes to replicate that data to other zones in the region.
The status of your customer-initiated conversion is displayed on the Redundancy page of the storage account:
Support-initiated conversion
Customers can request a conversion by opening a support request with Microsoft.
Tip
If you need to convert more than one storage account, create a single support ticket and specify the names of the accounts to convert on the Additional details tab.
Follow these steps to request a conversion from Microsoft:
In the Azure portal, navigate to a storage account that you want to convert.
Under Support + troubleshooting, select New Support Request.
Complete the Problem description tab based on your account information:
- Summary: (some descriptive text).
- Issue type: Select Technical.
- Subscription: Select your subscription from the drop-down.
- Service: Select My Services, then Storage Account Management for the Service type.
- Resource: Select a storage account to convert. If you need to specify multiple storage accounts, you can do so on the Additional details tab.
- Problem type: Choose Data Migration.
- Problem subtype: Choose Migrate to ZRS, GZRS, or RA-GZRS.
Select Next. The Recommended solution tab might be displayed briefly before it switches to the Solutions page. On the Solutions page, you can check the eligibility of your storage account(s) for conversion:
- Target replication type: (choose the desired option from the drop-down)
- Storage accounts from: (enter a single storage account name or a list of accounts separated by semicolons)
- Select Submit.
Take the appropriate action if the results indicate your storage account isn't eligible for conversion. Otherwise, select Return to support request.
Select Next. If you have more than one storage account to migrate, on the Details tab, specify the name for each account, separated by a semicolon.
Provide the required information on the Additional details tab, then select Review + create to review and submit your support ticket. An Azure support agent reviews your case and contacts you to provide assistance.
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.
Important
A manual migration can result in application downtime. If your application requires high availability, Microsoft also provides a conversion option. A conversion is an in-place migration with no downtime.
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
Important
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).
Limitations apply to some replication change scenarios depending on:
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 or 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.
Important
Customer-initiated conversion from LRS to ZRS is available in all public regions that support ZRS except for the following:
- (North America) Mexico Central
Customer-initiated conversion from existing ZRS accounts to LRS is available in all public regions.
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 or GZRS might be blocked if a conflicting feature is enabled, or it might be necessary to disable the feature later before initiating a failover.
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 lists the redundancy options available for storage account types and whether conversion and manual migration are supported:
| Storage account type | Supports LRS | Supports ZRS | Supports conversion (from the Azure portal) |
Supports conversion (by support request) |
Supports manual migration |
|---|---|---|---|---|---|
| Standard general purpose v2 | ✅ | ✅ | ✅ | ✅ | ✅ |
| Premium file shares | ✅ | ✅ | ✅ | ✅ 1 | ✅ |
1 Customer-initiated conversion can be undertaken using Azure Portal, PowerShell or the Azure CLI. You can also open a support request.
Protocol support
You can't convert storage accounts to zone-redundancy (ZRS or GZRS) if either of the following cases are true:
- NFSv3 protocol support is enabled for Azure Blob Storage
- The storage account contains Azure Files NFSv4.1 shares with public endpoint access enabled
Converting NFSv4.1 shares with public endpoints enabled isn't supported. To change redundancy for NFS shares with public endpoints, follow these steps in order:
- Disable access to the storage account's public endpoint.
- Submit the conversion request to change redundancy of the given storage account.
- Once the storage account is migrated, configure private or public endpoints as required.
Failover and failback
After an account failover to the secondary region, it's possible to initiate a failback from the new primary back to the new secondary with PowerShell or Azure CLI (version 2.30.0 or later). Initiate the failover.
If you performed a customer-managed account failover to recover from an outage for your GRS account, the account becomes locally redundant (LRS) in the new primary region after the failover. Conversion to ZRS or GZRS for an LRS account resulting from a failover isn't supported, even for so-called failback operations. For example, if you perform an account failover from GRS to LRS in the secondary region, and then configure it again as GRS, it remains LRS in the new secondary region (the original primary). If you then perform another account failover to failback to the original primary region, it remains LRS again in the original primary. In this case, you can't perform a conversion to ZRS or GZRS in the primary region. Instead, perform a manual migration to add zone-redundancy.
Downtime requirements
During a conversion, you can access data in your storage account with no loss of durability or availability. The Azure Storage SLA is maintained during the migration process and no data is lost during a conversion. Service endpoints, access keys, shared access signatures, and other account options remain unchanged after the migration.
If you choose to perform a manual migration, downtime is required but you have more control over the timing of the migration process.
Timing and frequency
The customer-initiated zone-redundancy conversion process could take up to 72 hours to begin after initiation, but can take longer due to resource availability, data volume, and other factors. It could take longer to start if you request a conversion by opening a support request. To monitor the progress of a customer-initiated conversion, see Monitoring customer-initiated conversion progress.
Important
There is no SLA for completion of a conversion. If you need more control over when a conversion begins and finishes, consider a Manual migration. Generally, the more data you have in your account, the longer it takes to replicate that data to other zones or regions.
After a zone-redundancy conversion, you must wait at least 72 hours before changing the redundancy setting of the storage account again. The temporary hold allows background processes to complete before making another change, ensuring the consistency and integrity of the account. For example, going from LRS to GZRS is a two-step process. You must add zone redundancy in one operation, then add geo-redundancy in a second. After going from LRS to ZRS, you must wait at least 72 hours before going from ZRS to GZRS.
Costs associated with changing how data is replicated
Azure Files offers several options for configuring replication. These options, ordered by least- to most-expensive, include:
- LRS
- ZRS
- GRS
- 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 Files Pricing page.
If you add zone-redundancy in the primary region, there's no initial cost associated with making that conversion, but the ongoing data storage cost is higher due to the increased replication and storage space required.
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.