Microsoft Azure

Demystifying Azure storage data redundancy options

  • LRS: Locally redundant storage
  • ZRS: Zone-redundant storage
  • GRS: Geo-redundant storage
  • GZRS: Geo-zone-redundant storage
  • RA-GRS: Read-access Geo-redundant storage
  • RA-GZRS: Read-access Geo-zone-redundant storage
  1. Design for failure: in alignment with Azure well-architected framework, especially on the Reliability pillar.
  2. While possible, switching redundancy configuration later on can be a troublesome for some scenarios.
  1. Regardless of which redundancy option you choose, Azure Storage never stores only one copy of your data. Even if you choose the least redundant option, your data is always replicated three times in the primary region, this is the minimum.
  2. Any option with a letter “G” (for Geo) in it indicates that you have your data geo-replicated across to the paired secondary region and by default, you cannot read from this replica in the secondary region unless you opt for the RA (Read Access) option.
LRS, GRS and RA-GRS
  • LRS (Locally Redundant Storage) means that your data is within 1 region, 1 datacentre. Microsoft makes 3 copies of your data, spreading them across different fault domains in 1 datacentre. This is the cheapest option but is also the most risky one in terms of redundancy because if the data centre fails (e.g. flooding, fire, prolonged power outage), then your data is lost.
  • GRS (Geo-Redundant Storage) means that you have another 3 copies (essentially another LRS) in a paired secondary region geo-replicated asynchronously. With GRS, you essentially have 6 copies of your data. This way, you are protected in case a region goes down, but you are still at the mercy of all 3 copies of your data stored within one datacentre within a region. With GRS, you cannot perform read on the secondary region. It purely serve for failover purpose.
  • RA-GRS (Read-Access Geo-Redundant storage) is essentially GRS that allows you to perform read on the secondary region. This is better for applications which requires high availability or one that requires many read requests.
ZRS, GZRS and RA-GZRS
  • ZRS (Zone-Redundant Storage) stores 3 copies of your data spreading them across 3 different availability zones within the primary region and it does so synchronously. This means you have 1 copy of your data in each datacentre with independent power, cooling and networking. This is much better than LRS because if 1 data centre fails, you still have the other 2 within the region. You also don’t run into the issue with asynchronous replication across regions.
  • GZRS (Geo-Zone Redundant Storage) is essentially ZRS, but your data is also geo-replicated across to the paired secondary region. In this secondary region, your data is replicated using LRS. As with GRS, the secondary region purely serve for failover. You cannot read from it unless you manually fail over.
  • RA-GZRS (Read-Access Geo-Zone Redundant Storage) is GZRS what enables you to read from the secondary region. Similar to RA-GRS, This is better for applications which requires high availability or one that requires many read requests.

--

--

--

I.T. Solutions Architecture, Cloud Architecture, Data Architecture

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Breaking down barriers for Slack app adoption

High Performance HTML Rendering

Why HPA failed to work on GKE, and how we fixed it

Six Rules for Good Git Hygiene

On Empathy & Pull Requests

Remove Cross-Team Dependencies

How I Landed Three Internships in Tech as a Second-Year College Student

How to Use PayPal to Integrate Card Payments to Your Website

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Adi Simon

Adi Simon

I.T. Solutions Architecture, Cloud Architecture, Data Architecture

More from Medium

Loading with Azure Storage

Azure Eventhub to GCP pubsub cross-clouds real-time migration

Snowflake Load Testing using Apache Jmeter

Release Pipelines for Azure Data factory