LRS : Locally redundant storage. Data is replicated 3 times in same datacentre. Most cost effective but a single datacentre failure can cause outages. Write request to storage account is only successful after it is written to all 3 replicas.
Can be used for scenarios where data can be reconstructed in case of data loss. Also if the local laws require data in specific region, opt for LRS.
ZRS – Zone redundant storage replicates data synchronously across 3 availability zones in the primary region. Provides high availability for the data and keeps the data within the geographic boundaries. With ZRS data is available for read and write even if a zone becomes unavailable. No DNS changes are required as Azure takes care of updating them. Application should have support for retries so that it is unaffected during zonal outages.
Storage to ZRS happens synchronously. Write operation would return successful only if the data is written to all replicas.
GRS – Geo redundant storage replicates the data synchronously within the primary availability zone using LRS. It then replicates the data asynchronously in the secondary region. In the secondary region, the data is replicated 3 times synchronously using LRS.
GZRS – Geo-Zone redundant storage replicates the data synchronously within the primary region in 3 availability zone using ZRS. It then replicates the data asynchronously in the secondary region. In the secondary region, the data is replicated 3 times synchronously using LRS.
Primary difference between GRS and GZRS is how the data is replicated in the primary region. With both these options, data in secondary region is not available for read/write unless there is failover to secondary region.
Because data is replicated to the secondary region asynchronously, a failure that affects the primary region may result in data loss if the primary region cannot be recovered. The interval between the most recent writes to the primary region and the last write to the secondary region is known as the recovery point objective (RPO). The RPO indicates the point in time to which data can be recovered. Azure Storage typically has an RPO of less than 15 minutes, although there’s currently no SLA on how long it takes to replicate data to the secondary region.
For example, if your primary endpoint for Blob storage is myaccount.blob.core.windows.net, then the secondary endpoint is myaccount-secondary.blob.core.windows.net. The account access keys for your storage account are the same for both the primary and secondary endpoints.
For read access to the secondary region, enable read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS).
Because data is replicated to the secondary region asynchronously, the secondary region is often behind the primary region. If a failure happens in the primary region, it’s likely that all writes to the primary will not yet have been replicated to the secondary.
To determine which write operations have been replicated to the secondary region, your application can check the Last Sync Time property for your storage account.