As your RDS for MySQL backup history grows, retaining a full backup set every day for a year accumulates significant storage costs. Sparse backup lets you stack multiple backup policies with different schedules and retention periods, keeping only the minimum number of backup sets needed for your recovery requirements. This reduces recovery time and lowers backup storage costs compared to regular backup.
How it works
Sparse backup stacks multiple independent backup policies on a single instance. Each policy defines a schedule (weekly, monthly, or yearly) and a retention period. Together, the policies form a tiered strategy that keeps recent backups dense and historical backups sparse.
| Item | Regular backup | Sparse backup |
|---|---|---|
| Retention policy | Must retain 2–7 backup sets per week | Flexible — retain the minimum backup sets across weekly, monthly, and yearly cycles |
| Storage cost | Higher — backup sets accumulate over time | Lower — only the minimum required backup sets are kept |
Example: With regular backup, you might retain one backup set per day for 365 days. With sparse backup, you can retain daily backups for 7 days, Monday backups for 30 days, month-end backups for 365 days, and a yearly backup indefinitely — using far fewer backup sets in total.
Prerequisites
Before you begin, ensure that you have:
An RDS for MySQL instance that is not on the Basic Edition (5.7 Basic Edition instances do not support sparse backup)
An instance without Cold Archive enabled (Cold Archive instances do not support sparse backup)
Authorized the service-linked role for Data Disaster Recovery (AliyunServiceRoleForDBS) if this is your first time using the RDS backup service. See Authorize the service-linked role for Data Disaster Recovery
Switched to the advanced backup policy page (see Switch to the advanced backup policy below)
Switch to the advanced backup policy
Switching to the advanced backup policy is irreversible. You cannot switch back to the basic version.
If you have already switched, skip this section.
Go to the Instances page. In the top navigation bar, select the region where your instance resides, then click the instance ID.
In the left navigation pane, click Backup and Restoration.
On the Backup and Restoration page, click the Backup Strategy tab, then click Switch to Advanced Backup Policy.
ImportantIf the Switch to Advanced Backup Policy button is not visible, submit a ticket to request access. Refresh the page after your request is approved.
In the dialog box, select Understood and click OK.
The Backup Policy page now appears in the advanced layout, as shown below. You can configure sparse backup policies on this page.
Set a sparse backup policy
Go to the Instances page. In the top navigation bar, select the region where your instance resides, then click the instance ID.
In the left navigation pane, click Backup and Restoration.
On the Backup and Restoration page, click the Backup Strategy tab, then click the circled number between MySQL and Level-1 Backup.
In the dialog box, click Add Backup Policy, configure the policy, then click OK. For other parameter settings, see Automatic backup and Backup encryption.
RDS for MySQL 5.6 and 5.7 instances on the high-availability series with high-performance local disks support High-frequency Incremental Backup. When enabled, the system performs physical incremental backups at the configured frequency in addition to the scheduled full backups. The retention period for high-frequency incremental backup sets must be 7–30 days and cannot exceed the retention period of the backup policy. If a full backup set expires but its dependent incremental backup sets have not, the full backup set is retained until all its incremental backup sets expire. For more information, see Use the high-frequency physical backup feature.
Parameter Options Constraints Backup cycle Every Week — select one or more days of the week The first policy is fixed to Every Week, must cover at least two days, and cannot be deleted Every Month — select one or more days of the month, or Last Day Of Each Month Every Year — select a specific day (for example, January 1) Backup time The time window for performing the backup Retention period 7–7,300 days, or Long-term Retention Each policy can have a different retention period. If multiple policies overlap on the same day, the system creates one backup set and retains it for the longest period among those policies In the lower-left corner of the Backup Policy tab, click Save.
A sparse backup policy takes effect 10–15 minutes after you save it.
Configuration example
The following configuration implements a four-tier retention strategy that balances short-term recovery speed with long-term retention at minimal storage cost.
| Policy | Schedule | Retention |
|---|---|---|
| ① | Every day (Monday–Sunday) | 7 days |
| ② | Every Monday | 30 days |
| ③ | First and last day of each month | 365 days |
| ④ | January 1 of each year | Long-term |
On days when multiple policies overlap, the system creates one backup set and keeps it for the longest retention period. For example, on Monday January 1, policies ①, ②, and ④ all apply — the system creates one backup set and retains it long-term.
Limits
Deleting a backup policy does not delete already-generated backup sets. Those sets are retained until their original retention period expires.
If a backup fails within the backup window on a scheduled day (due to a failed backup, a locked instance, or a dump that is not completed before the level-1 backup expires), the system skips the backup for that day without creating an extra backup set.
Billing
Backup storage is free up to your free quota. If your total backup storage exceeds the free quota, you are charged for the excess. For pricing details, see Backup storage costs.
What's next
View backup policies
On the Backup Policy page, hover over the circled number between MySQL and Level-1 Backup to see all configured policies. The number in the circle indicates how many policies are configured.
Delete a backup policy
On the Level-1 Backup page, you can delete any backup policy except the first one (which is fixed to Every Week and cannot be deleted).
