Configuring backup storage redundancy in Azure SQL Hyperscale
Published Aug 04 2021 08:00 AM 5,023 Views

Database backups are an essential part of any business continuity and disaster recovery strategy, because they protect your data from corruption or accidental deletes. Azure SQL Hyperscale, allows Short-term backups used for point-in-time restores (PITR) or geo-restores, keeping backup data available for up to a user configurable backup retention period.


To protect backup data from planned and unplanned events, including transient hardware failures, network or power outages, and massive natural disasters, backup storage is replicated to another storage. By default, storage is geo-replicated to a paired region using RA-GRS strategy. As many applications have regulatory, compliance, or other business requirements for data residency control, geo-redundancy may not a good fit for some customers. To overcome this, the option for configuring backup storage redundancy is now enabled (in preview) for Azure SQL Hyperscale. It allows customers to choose replication strategy for their backup storages and define if geo-redundancy (RA-GRS), zone-redundancy (ZRS), or local-redundancy (LRS) will be used.


Database and Backup storage


Since backups for Azure SQL Hyperscale are file-snapshot based, both backups and database file storage use the same storage account for a Hyperscale database. Creating a Hyperscale database with LRS or ZRS backup storage redundancy also means that the database storage will use the same storage redundancy option.


What are the differences in storage redundancy?


Backup storage redundancy relies on Azure Storage redundancy:

  • Locally redundant storage (LRS)
    • Design characteristics: replicates your data three times within a single physical location in the primary region. LRS provides at least 99.999999999% (11 9’s) durability of objects over a given year. LRS protects your data against server rack and drive failures. However, if a disaster such as fire or flooding occurs within the data center, all replicas of a storage account using LRS may be lost or unrecoverable.
    • Best for: LRS keeps your data in the same region and provides capability of data residency and helping you to stay compliant with regulatory requirements. In addition, LRS is the lowest-cost redundancy option (but offering the least durability compared to other options) which is good fit for dev/test scenarios.
  • Zone-redundant storage (ZRS)
    • Design characteristics: replicates your Azure Storage data synchronously across three Azure availability zones in the primary region. Each availability zone is a separate physical location with independent power, cooling, and networking. ZRS offers durability for Azure Storage data objects of at least 99.9999999999% (12 9's) over a given year.
    • Best for: ZRS also provides capability of data residency but offers higher durability due to data replicated across availability zones. It is good fit for production scenarios that are cost sensitive.
  • Geo-redundant storage (RA-GRS) - RECOMMENDED (DEFAULT)
    • Design characteristics: replicates your data synchronously three times within a single physical location in the primary region using LRS. It then copies your data asynchronously to a single physical location in a secondary region that is hundreds of miles away from the primary region. RA-GRS offers durability for Azure Storage data objects of at least 99.99999999999999% (16 9's) over a given year.
    • Best for: RA-GRS is best disaster recovery option which gives highest durability. In addition, geo-redundant backup storage enables Geo-restore capability – a cheap and economically efficient disaster recovery option. This is default configuration value and if there is no need for data residency compliance, it is recommended to use RA-GRS backup storage for all production workloads.

While LRS and GRS are available in all regions, ZRS is available only in specified regions.


How can I configure backup storage redundancy?


Backup storage redundancy can be configured during hyperscale database creation when request is submitted using REST API, PowerShell, Azure CLI, ARM template or Azure Portal. The code samples and the Azure Portal snippet included below show the creation of a Hyperscale database with backup storage redundancy set to “Zone Redundant Storage”.


Azure CLI



az sql db create --subscription "MySubscriptionName" --resource-group "MyResourceGroup" --server "MySQLDBServer" --name "MyHSDatabase" --sample-name AdventureWorksLT --edition Hyperscale --compute-model Provisioned --family Gen5 --capacity 4 --backup-storage-redundancy Zone






$database = New-AzSqlDatabase -ResourceGroupName "MyResourceGroup" -ServerName "MySQLDBServer" -DatabaseName "sourabhHSDb5" -SampleName "AdventureWorksLT" -Edition Hyperscale -Vcore 4 -ComputeGeneration "Gen5" -ComputeModel Provisioned -BackupStorageRedundancy Local



Azure Portal




How can I change backup storage redundancy for existing databases?


It is not possible to update backup storage redundancy for existing hyperscale databases. However, there is workaround which relies on the database copy process. When creating a copy of an existing database, the backup storage redundancy option can be selected as shown .


Azure CLI



az sql db copy --resource-group "MyResourceGroup" --server "MySQLDBServer" --name "MyHSSourceDB" --dest-resource-group "MyDestResourceGroup" --dest-server "MySQLDBDestServer" --dest-name "MyHSDestDB" --service-objective HS_Gen5_2 --read-replicas 0 --backup-storage-redundancy Zone






$databasecp = New-AzSqlDatabaseCopy -ResourceGroupName "MyResourceGroup" -ServerName "MySQLDBServer" -DatabaseName "MyHSSourceDB" -CopyResourceGroupName "MyDestResourceGroup" -CopyServerName "MySQLDBDestServer" -CopyDatabaseName "MyHSDestDB" -Vcore 4 -ComputeGeneration "Gen5" -ComputeModel Provisioned -BackupStorageRedundancy Zone



Azure Portal





The copy database process is documented at Copy a database - Azure SQL Database | Microsoft Docs


Version history
Last update:
‎Aug 02 2021 12:18 AM
Updated by: