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.
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.
Backup storage redundancy relies on Azure Storage redundancy:
While LRS and GRS are available in all regions, ZRS is available only in specified regions.
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”.
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
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 .
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
The copy database process is documented at Copy a database - Azure SQL Database | Microsoft Docs
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.