J
jes_schultz
On behalf of our engineering and product management teams, we are excited to announce the general availability of short-term backup retention up to 35 days in the Hyperscale tier of Azure SQL Database. Before this improvement, Hyperscale supported backup retention up to 7 days. With this feature, you can configure backup retention from 1-35 days and perform a point-in-time restore to any time within the configured retention.
Hyperscale Backup Overview
The SQL Database Hyperscale tier does not use traditional full, differential, and transaction log-based backup architecture. Instead, regular storage snapshots of data files are taken and are nearly instantaneous. The generated transaction log is retained as-is for the configured retention period. At restore time, relevant transaction log records are applied to the restored storage snapshots, resulting in a transactionally consistent database without any data loss as of the specified point in time within the retention period.
Get started with point-in-time backup and restore:
Monitor Hyperscale backup storage consumption
In Hyperscale, Data storage size, Data backup storage (snapshot backup size), and Log backup storage (transaction log backup size) are reported via Azure Monitor metrics. Here are the instructions to view backup, data storage, and log backup size metrics in Azure Portal:
Hyperscale backup storage costs
Backup storage cost of a Hyperscale database depends on the choice of region, backup storage redundancy, and workload type. Write-heavy workloads are more likely to change data pages frequently, which results in larger data backup storage size as backups in Hyperscale are taken with snapshots of storage. Such workloads also generate more transaction log, contributing to the overall backup costs. Backup storage is charged per GB/month consumed, for pricing details see Azure SQL Database pricing.
For Hyperscale database, billable backup storage is calculated as follows:
Total billable backup storage size = (Data backup storage size + Log backup storage size)
Data storage size is not included in the billable backup as it is already billed as allocated database storage.
Please note: data backup storage size is indicative of modified data and is not a full or differential backup.
Optimize Backup Storage Consumption
Consider some of the following tuning techniques to reduce your backup storage consumption:
For more details on Azure SQL Database Hyperscale short-term backup retention please refer to Hyperscale backup documentation.
Continue reading...
Hyperscale Backup Overview
The SQL Database Hyperscale tier does not use traditional full, differential, and transaction log-based backup architecture. Instead, regular storage snapshots of data files are taken and are nearly instantaneous. The generated transaction log is retained as-is for the configured retention period. At restore time, relevant transaction log records are applied to the restored storage snapshots, resulting in a transactionally consistent database without any data loss as of the specified point in time within the retention period.
Get started with point-in-time backup and restore:
- Change automated backup settings for Azure SQL Database
- Restore a database from a backup in Azure SQL Database
Monitor Hyperscale backup storage consumption
In Hyperscale, Data storage size, Data backup storage (snapshot backup size), and Log backup storage (transaction log backup size) are reported via Azure Monitor metrics. Here are the instructions to view backup, data storage, and log backup size metrics in Azure Portal:
- Navigate to the Hyperscale database for which you’d like to monitor backup and data storage metric.
- Navigate to Metrics page in the Monitoring section
- From the Metric drop down list select Data backup storage size , Data storage size, and Log backup storage size with appropriate aggregation rule
Hyperscale backup storage costs
Backup storage cost of a Hyperscale database depends on the choice of region, backup storage redundancy, and workload type. Write-heavy workloads are more likely to change data pages frequently, which results in larger data backup storage size as backups in Hyperscale are taken with snapshots of storage. Such workloads also generate more transaction log, contributing to the overall backup costs. Backup storage is charged per GB/month consumed, for pricing details see Azure SQL Database pricing.
For Hyperscale database, billable backup storage is calculated as follows:
Total billable backup storage size = (Data backup storage size + Log backup storage size)
Data storage size is not included in the billable backup as it is already billed as allocated database storage.
Please note: data backup storage size is indicative of modified data and is not a full or differential backup.
Optimize Backup Storage Consumption
Consider some of the following tuning techniques to reduce your backup storage consumption:
- Reduce the backup retention period to the minimum possible for your needs.
- Avoid doing large write operations, such as index maintenance, more frequently than needed. For index maintenance recommendations, see Optimize index maintenance to improve query performance and reduce resource consumption.
- For large data load operations, consider using data compression when appropriate.
- Use the `tempdb` database instead of permanent tables in your application logic for storing temporary results and/or transient data.
- Use locally redundant or zone redundant backup storage when geo-restore capability is unnecessary (for example: dev/test environments).
For more details on Azure SQL Database Hyperscale short-term backup retention please refer to Hyperscale backup documentation.
Continue reading...