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. By default, storage is geo-replicated to a paired region using RA-GRS strategy. But many applications have regulatory, compliance, or other business requirements for data residency control, geo-redundancy may not be a good fit in such scenarios. To solve this, additional backup storage redundancy options are now enabled for Azure SQL Hyperscale. It allows customers to choose zone-redundancy (ZRS), or local-redundancy (LRS) replication strategies for their backup storages in addition to currently available geo-redundancy (RA-GRS) option.
Database and Backup storage
Hyperscale databases use snapshot backup technology, both backups and database file storage use the same storage account for a Hyperscale database. So the storage redundancy option chosen while creating a database will be applicable for life time of the database for both database storage as well as backup storage. Learn more about Hyperscale storage and backups redundancy.
Storage redundancy options:
Hyperscale storage redundancy relies on Azure Storage redundancy and following redundancy options are supported
- 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)
- 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.
Azure CLI
Az sql db create CLI command can be used to create a new Hyperscale database with desired storage redundancy option using -backup-storage-redundancy{Local, Zone, Geo} parameter. Here is a sample command to create a new Hyperscale database with Zone backup-storage-redundancy.
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
PowerShell
New-AzSqlDatabase Powershell command can be used to create a new Hyperscale database with desired storage redundancy option using -BakcupStorageRedundancy{Local, Zone, Geo} parameter. Here is a sample command to create a new Hyperscale database with Local backup-storage-redundancy.
$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, if it is critical to change storage redundancy of an existing Hyperscale database, users can use copy database process.
Azure CLI
Create a copy of existing Hyperscale database using az sql db copy CLI command and when creating a copy of an existing database, the desired –backup-storage-redundancy{Local, Zone, Geo} option can be selected as shown:
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
PowerShell
Create a copy of existing Hyperscale database using New-AzSqlDatabaseCopy Powershell command and when creating a copy of an existing database, the desired –BackupStorageRedundancy{Local, Zone, Geo} option can be selected as shown:
$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
Availability
Local(LRS) and Geo Redundancy(RA-GRS) storage and backup redundancy options for Hyperscale are available for all regions worldwide. Zone Redundancy option is available only in certain regions
For detailed information about the feature visit Hyperscale Backup and Storage redundancy documentation.
Posted at https://sl.advdat.com/3KrLWd5https://sl.advdat.com/3KrLWd5