On behalf of our engineering and product management teams, we are excited to announce the general availability of long-term backup retention (LTR) in the Hyperscale tier of Azure SQL Database.
Many applications have regulatory, compliance, or other business requirements that require the database backups to be stored beyond the 1-35 days provided by short-term (or PITR) backups. Long-term backup retention helps users meet these requirements by storing database backups for up to 10 years.
Hyperscale backup overview
Unlike other service tiers in Azure SQL Database, Hyperscale databases use a unique architecture with highly scalable storage and compute performance tiers. This separation of storage and compute enables Hyperscale to push down backup and restore operations to the storage layer and eliminates any resource consumption on compute replicas due to backup operations. Backups on Hyperscale are snapshot-based and nearly instantaneous. Restore operations within the same Azure region typically finish in minutes. Since backups are snapshot based, database and backup flies share the same storage account and the chosen backup storage redundancy is applicable for data as well as backups. You can get more details at Automated backups for Hyperscale databases.
Long-term retention on Hyperscale databases leverages the snapshots taken to enable point-in-time-restore (PITR) and copies the snapshots to different blobs for long-term storage. The copy operation happens at a storage level, so it doesn’t utilize resources from compute and won't impact any ongoing write or read operations.
How to configure LTR on Hyperscale databases
On Hyperscale, though the underlying backup architecture differs, the experience of configuring LTR is the same as the other service tiers. Users can define LTR policy using combination of four parameters: weekly backup retention (W), monthly backup retention (M), yearly backup retention (Y), and week of year (WeekOfYear).
LTR leverages the full database backups that are automatically created to enable PITR.
If you specify W, one backup every week will be copied to the long-term storage.
If you specify M, the first backup of each month will be copied to the long-term storage.
If you specify Y, one backup during the week specified by WeekOfYear will be copied to the long-term storage. If the specified WeekOfYear is in the past when the policy is configured, the first LTR backup will be created in the following year.
The timing of individual LTR backups is controlled by Azure. You cannot manually create an LTR backup or control the timing of the backup creation.
After configuring an LTR policy, it may take up to 7 days before the first LTR backup will show up on the list of available backups.
If you're using active geo-replication or failover groups as your business continuity solution, you should prepare for eventual failovers and configure the same LTR policy on the secondary database. Your LTR storage cost won't increase, as backups aren't generated from the secondaries. The backups are only created when the secondary becomes primary. It ensures non-interrupted generation of the LTR backups when the failover is triggered and the primary moves to the secondary region.
Deleted servers, deleted databases, and LTR
You can only recover from deleting a logical SQL server or database if you have LTR backups configured.
If you delete a logical SQL server, all databases on that server are also deleted and can't be recovered. You can't restore a deleted server. However, if you had configured LTR for a database, LTR backups are not deleted, and they can be used to restore databases on a different server in the same subscription, to a point in time when an LTR backup was taken.
Similarly, if you delete a database, LTR backups are not deleted and are retained for the configured retention period. These backups can be restored to the same server or a different server in the same subscription.