Azure Storage replication

The data in your Microsoft Azure storage account is always replicated to ensure durability and high availability. Replication copies your data so that it is protected from transient hardware failures, preserving your application up-time.

You can choose to replicate your data within the same data center, across data centers within the same region, or across regions. If your data is replicated across multiple data centers or across regions, it's also protected from a catastrophic failure in a single location.

Replication ensures that your storage account meets the Service-Level Agreement (SLA) for Storage even in the face of failures. See the SLA for information about Azure Storage guarantees for durability and availability.

When you create a storage account, you can select one of the following replication options:

Read-access geo-redundant storage (RA-GRS) is the default option when you create a storage account.

The following table provides a quick overview of the differences between LRS, ZRS, GRS, and RA-GRS. Subsequent sections of this article address each type of replication in more detail.

Replication strategy LRS ZRS GRS RA-GRS
Data is replicated across multiple datacenters. No Yes Yes Yes
Data can be read from a secondary location as well as the primary location. No No No Yes
Designed to provide _ durability of objects over a given year. at least 99.999999999% (11 9's) at least 99.9999999999% (12 9's) at least 99.99999999999999% (16 9's) at least 99.99999999999999% (16 9's)

See Azure Storage Pricing for pricing information for the different redundancy options.

Note

Premium Storage supports only locally redundant storage (LRS). For information about Premium Storage, see Premium Storage: High-Performance Storage for Azure Virtual Machine Workloads.

Locally redundant storage

Locally redundant storage (LRS) is designed to provide at least 99.999999999% (11 9's) durability of objects over a given year by replicating your data within a storage scale unit, which is hosted in a datacenter in the region in which you created your storage account. A write request returns successfully only once it has been written to all replicas. These replicas each reside in separate fault domains and upgrade domains within one storage scale unit.

A storage scale unit is a collection of racks of storage nodes. A fault domain (FD) is a group of nodes that represent a physical unit of failure and can be considered as nodes belonging to the same physical rack. An upgrade domain (UD) is a group of nodes that are upgraded together during the process of a service upgrade (rollout). The replicas are spread across UDs and FDs within one storage scale unit to ensure that data is available even if hardware failure impacts a single rack or when nodes are upgraded during a rollout.

LRS is the lowest cost option and offers least durability compared to other options. In the event of a datacenter level disaster (fire, flooding etc.) all replicas might be lost or unrecoverable. To mitigate this risk, Geo Redundant Storage (GRS) is recommended for most applications.

Locally redundant storage may still be desirable in certain scenarios:

  • Provides highest maximum bandwidth of Azure Storage replication options.
  • If your application stores data that can be easily reconstructed, you may opt for LRS.
  • Some applications are restricted to replicating data only within a country due to data governance requirements. A paired region could be in another country. For more information on region pairs, see Azure regions.

Zone redundant storage

Zone redundant storage (ZRS) (preview) is designed to simplify the development of highly available applications. ZRS provides durability for storage objects of at least 99.9999999999% (12 9's) over a given year. ZRS replicates your data synchronously across multiple availability zones. Consider ZRS for scenarios like transactional applications where downtime is not acceptable.

ZRS enables customers to read and write data even if a single zone is unavailable or unrecoverable. Inserts and updates to data are made synchronously and are strongly consistent.

ZRS is currently available for preview in the following regions, with more regions coming soon:

ZRS Classic accounts

The existing ZRS capability is now referred to as ZRS Classic. ZRS Classic accounts are available only for block blobs in general-purpose V1 storage accounts.

ZRS Classic replicates data asynchronously across datacenters within one to two regions. A replica may not be available unless Microsoft initiates failover to the secondary.

ZRS Classic accounts cannot be converted to or from LRS, GRS, or RA-GRS. ZRS Classic accounts also do not support metrics or logging.

Once ZRS is generally available in a region, you will no longer be able to create a ZRS Classic account from the portal in that region, but you can create one through other means.
An automated migration process from ZRS Classic to ZRS will be provided in the future.

You can manually migrate ZRS account data to or from an LRS, ZRS Classic, GRS, or RAGRS account. You can perform this manual migration using AzCopy, Azure Storage Explorer, Azure PowerShell, Azure CLI, or one of the Azure Storage client libraries.

Note

ZRS Classic accounts are planned for deprecation and required migration on March 31, 2021. Microsoft will send more details to ZRS Classic customers prior to deprecation.

Additional questions are addressed in the Frequently asked questions section.

Geo-redundant storage

Geo-redundant storage (GRS) is designed to provide at least 99.99999999999999% (16 9's) durability of objects over a given year by replicating your data to a secondary region that is hundreds of miles away from the primary region. If your storage account has GRS enabled, then your data is durable even in the case of a complete regional outage or a disaster in which the primary region is not recoverable.

For a storage account with GRS enabled, an update is first committed to the primary region. Then the update is replicated asynchronously to the secondary region, where it is also replicated.

With GRS, both the primary and secondary regions manage replicas across separate fault domains and upgrade domains within a storage scale unit as described with LRS.

Considerations:

  • Since asynchronous replication involves a delay, in the event of a regional disaster it is possible that changes that have not yet been replicated to the secondary region will be lost if the data cannot be recovered from the primary region.
  • The replica is not available unless Microsoft initiates failover to the secondary region. If Microsoft does initiate a failover to the secondary region, you will have read and write access to that data after the failover has completed. For more information, please see Disaster Recovery Guidance.
  • If an application wants to read from the secondary region, the user should enable RA-GRS.

When you create a storage account, you select the primary region for the account. The secondary region is determined based on the primary region, and cannot be changed. The following table shows the primary and secondary region pairings.

Primary Secondary
North Central US South Central US
South Central US North Central US
East US West US
West US East US
US East 2 Central US
Central US US East 2
North Europe West Europe
West Europe North Europe
South East Asia East Asia
East Asia South East Asia
East China North China
North China East China
Japan East Japan West
Japan West Japan East
Brazil South South Central US
Australia East Australia Southeast
Australia Southeast Australia East
India South India Central
India Central India South
India West India South
US Gov Iowa US Gov Virginia
US Gov Virginia US Gov Texas
US Gov Texas US Gov Arizona
US Gov Arizona US Gov Texas
Canada Central Canada East
Canada East Canada Central
UK West UK South
UK South UK West
Germany Central Germany Northeast
Germany Northeast Germany Central
West US 2 West Central US
West Central US West US 2

For up-to-date information about regions supported by Azure, see Azure regions.

Note

US Gov Virginia secondary region is US Gov Texas. Previously, US Gov Virginia utilized US Gov Iowa as a secondary region. Storage accounts still leveraging US Gov Iowa as a secondary region are being migrated to US Gov Texas as a secondary region.

Read-access geo-redundant storage

Read-access geo-redundant storage (RA-GRS) maximizes availability for your storage account. RA-GRS provides read-only access to the data in the secondary location, in addition to geo-replication across two regions.

When you enable read-only access to your data in the secondary region, your data is available on a secondary endpoint as well as on the primary endpoint for your storage account. The secondary endpoint is similar to the primary endpoint, but appends the suffix –secondary to the account name. For example, if your primary endpoint for the Blob service is myaccount.blob.core.windows.net, then your secondary endpoint is myaccount-secondary.blob.core.windows.net. The access keys for your storage account are the same for both the primary and secondary endpoints.

Some considerations to keep in mind when using RA-GRS:

  • Your application has to manage which endpoint it is interacting with when using RA-GRS.
  • Since asynchronous replication involves a delay, changes that have not yet been replicated to the secondary region may be lost if data cannot be recovered from the primary region, for example in the event of a regional disaster.
  • If Microsoft initiates failover to the secondary region, you will have read and write access to that data after the failover has completed. For more information, see Disaster Recovery Guidance.
  • RA-GRS is intended for high-availability purposes. For scalability guidance, review the performance checklist.

Frequently asked questions

1. How can I change the geo-replication type of my storage account?

You can change the geo-replication type of your storage account by using the Azure portal, Azure Powershell, or one of the Azure Storage client libraries.

Note

ZRS accounts cannot be converted LRS or GRS. Similarly, an existing LRS or GRS account cannot be converted to a ZRS account.

2. Does changing the replication type of my storage account result in down time?

No, changing the replication type of your storage account does not result in down time.

3. Are there additional costs to changing the replication type of my storage account?

Yes. If you change from LRS to GRS (or RA-GRS) for your storage account, you incur an additional charge for egress involved in copying existing data from primary location to the secondary location. After the initial data is copied, there are no further additional egress charges for geo-replication from the primary to secondary location. For details on bandwidth charges, see Azure Storage Pricing page.

If you change from GRS to LRS, there is no additional cost, but your data is deleted from the secondary location.

4. How can RA-GRS help me?

GRS storage provides replication of your data from a primary to a secondary region that is hundreds of miles away from the primary region. With GRS, your data is durable even in the event of a complete regional outage or a disaster in which the primary region is not recoverable. RA-GRS storage offers GRS replication and adds the ability to read the data from the secondary location. For suggestions on how to design for high availability, see Designing Highly Available Applications using RA-GRS storage.

5. Is there a way to figure out how long it takes to replicate my data from the primary to the secondary region?

If you are using RA-GRS storage, you can check the Last Sync Time of your storage account. Last Sync Time is a GMT date/time value. All primary writes before the Last Sync Time have been successfully written to the secondary location, meaning that they are available to be read from the secondary location. Primary writes after the Last Sync Time may or may not be available for reads yet. You can query this value using the Azure portal, Azure PowerShell, or from one of the Azure Storage client libraries.

6. If there is an outage in the primary region, how do I switch to the secondary region?

For more information, see What to do if an Azure Storage outage occurs.

7. What is the RPO and RTO with GRS?

Recover Point Objective (RPO): In GRS and RA-GRS, the storage service asynchronously geo-replicates the data from the primary to the secondary location. In the event of a major regional disaster in the primary region, Microsoft performs a failover to the secondary region. If a failover happens, recent changes that have not yet been geo-replicated may be lost. The number of minutes of potential data lost is referred to as the RPO, and it indicates the point in time to which data can be recovered. Azure Storage typically has an RPO of less than 15 minutes, although there is currently no SLA on how long geo-replication takes.

Recovery Time Objective (RTO): The RTO is a measure of how long it takes to perform the failover and get the storage account back online. The time to perform the failover includes the following actions:

  • The time Microsoft requires to determine whether the data can be recovered at the primary location, or if a failover is necessary.
  • The time to perform the failover of the storage account by changing the primary DNS entries to point to the secondary location.

    Microsoft takes the responsibility of preserving your data seriously. If there is any chance of recovering the data in the primary region, Microsoft will delay the failover and focus on recovering your data. A future version of the service will allow you to trigger a failover at an account level so that you can control the RTO yourself.

8. What Azure Storage objects does ZRS support?

Block blobs, page blobs (except for those backing VM disks), tables, files, and queues.

9. Does ZRS also include geo-replication?

Currently ZRS does not support geo-replication. If your scenario requires cross-region replication for the purposes of disaster recovery, use a GRS or RA-GRS storage account instead.

10. What happens when one or more ZRS zones go down?

When the first zone goes down, ZRS continues to write replicas of your data across the two remaining zones in the region. If a second zone goes down, read and write access is unavailable until at least two zones are available again.

Next steps