Configuring Same-Region Backup Policies

Scenarios

When you create an RDS instance, an automated backup policy is enabled by default. For security purposes, the automated backup policy cannot be disabled after the DB instance is created. You can customize the automated backup policy as required, and RDS backs up the database according to the policy you configure.

RDS backs up data at the DB instance level, rather than the database level. If a database is faulty or data is damaged, you can restore it from backups. Backups are saved as packages in OBS buckets to ensure data confidentiality and durability. Since backing up data affects database read and write performance, the automated backup time window should be set to off-peak hours.

After an automated backup policy is configured, full backups are created based on the time window and backup cycle specified in the policy. The time required for creating a backup depends on how much data there is in the instance. Backups are stored for as long as you specified in the backup policy.

You do not need to set an interval for incremental backup because RDS automatically backs up incremental data every 5 minutes or when a certain amount of incremental data is generated. Incremental backups can be used to restore data to a specific point in time.

Video Tutorial

Differences Between Standard Backups and Sparse Backups

**Table 1** Backup functions
Item	Standard Backup	Sparse Backup
Function description	RDS for MySQL uses standard backups by default. A standard backup saves all data of an instance based on your chosen schedule and backup cycle. Each time a backup task finishes, the system creates a backup and stores it for the duration you specify.	If you want to retain backups for a long time, you can enable sparse backups to reduce expenses. Compared with the default backup policy, sparse backup policies reduce the backup frequency while maintaining the same retention period for the backups. To enable sparse backups, submit a service ticket to request required permissions. After sparse backups are enabled, the standard backup policy continues to be displayed by default, but you can add sparse backup policies.
Number of backup policies	An instance has only one backup policy, which cannot be deleted. The default policy is weekly backup. Select at least one day in a week. The backups can be retained for 1 to 732 days.	The default policy cannot be deleted, but sparse backup policies can be deleted. After enabling sparse backups, you can add sparse backup policies alongside the default backup policy. The default policy backs up data weekly and cannot be deleted. Select at least one day in a week. You can set the backup retention period to 1 to 732 days. Backups can be kept for 1 to 732 days. There are three types of sparse backup policies. Weekly: Select at least one day in a week. Monthly: Select at least one day in a month. Yearly: Select a specific day in a year.
Time window	Set it to a one-hour period within the 24-hour day during which the backup task may start, such as 01:00-02:00 or 12:00-13:00.	Set it to a one-hour period within the 24-hour day during which the backup task may start, such as 01:00-02:00 or 12:00-13:00.
Snapshot backups	Supported	Supported

Constraints and Billing

**Table 2** Constraints
Category	Constraints	Billing
Snapshot backups not enabled	For a primary/standby instance, if the standby node is faulty or the replication delay of the standby node exceeds one day, backups will be performed on the primary node. When a DB instance is deleted, you can configure the retention policies for its automated and manual backups. For details, see Deleting Pay-per-Use DB Instances or Read Replicas and Unsubscribing from a Yearly/Monthly Instance. Rebooting the instance is not allowed during full backup. Exercise caution when selecting a backup time window. When starting a full backup task, the system first tests connectivity to your instance. If either of the following conditions is met, the verification fails and the system retries the verification: If the retry fails, the backup will fail. The system is performing DDL operations on this instance. The system fails to obtain the backup lock from this instance. Performing a full backup may decrease instance throughput and increase replication delay because it occupies node resources, especially disk bandwidth. Performing backups consumes memory resources. If there are many tables in your instance but the available memory is not enough, your backup task may fail. When this happens, reduce the number of tables or upgrade the instance specifications. Metadata locks will be generated while a backup is being created, which may cause DDL blocking or a replication delay.	Backups are saved as packages in OBS buckets. For billing details, see How Are RDS Backups Billed? You can configure backup billing alerts on the Overview page to receive a notification before the free backup space is used up.
Snapshot backups enabled	Snapshot backups rely on the Cloud Backup and Recovery (CBR) service. For details, see What Is CBR? Once snapshot backup is enabled, cross-region backup cannot be configured. Enabling snapshot backup will incur fees. Snapshot backups are billed by actual consumption, which is calculated by CBR. The backup time is proportional to how much data your instance has. If you have large amounts of data and want to speed up the backup process, enable snapshot backups. After snapshot backup is enabled, the backup policy is snapshot backup. Existing automated and manual backups can still be used to restore data. After snapshot backups are enabled, deleting an instance automatically deletes its automated backups, while manual backups are retained. DDL operations cannot be performed when a snapshot backup is being created. If a DDL operation is being performed, a snapshot backup will be created after the DDL operation is complete. After snapshot backup is enabled, the next full backup is a snapshot backup. You can use the snapshot backup to restore data.	Billing rules after snapshot backup is enabled: For snapshots created before September 2025: No backup space is provided for free. You are billed for database server backup vaults in CBR on a pay-per-use basis. For details, see How Is CBR Billed? For snapshots created in September 2025 and later: RDS provides free snapshot backup space equal to the size of your purchased storage space. After the free space is used up, you are billed for CBR snapshots in RDS on a pay-per-use basis. For details, see RDS Pricing Details. For example, if you purchase an instance with 40 GB of storage, you receive 80 GB of free backup space, which includes 40 GB for log backups and 40 GB for snapshot backups. Figure 1 Storage and backup You can configure backup billing alerts on the Overview page to receive a notification before the free backup space is used up.

Procedure

Log in to the RDS console.
Click in the upper left corner and select a region.
On the Instances page, click the target DB instance name.
In the navigation pane on the left, choose Backups & Restorations.
In the upper right corner of the page, choose Modify Backup Policy > Configure Same-Region Backup Policy. On the displayed page, you can view the backup policies you have. If you want to modify one of them, adjust the following parameters:

Figure 2 Modifying a backup policy
- Retention Period: It indicates how many days your automated full backups and binlog backups can be retained. The retention period is from 1 to 732 days and the default value is 7.
  - Extending the retention period enhances data availability.
  - If you shorten the retention period, the new backup policy applies to existing backups. Manual backups will not be deleted automatically. Exercise caution when making your selection.
  Automatic deletion policy for full backups:
  
  To ensure data integrity, the system keeps the most recent backup that has exceeded the retention period during automatic deletions. This ensures that data within the retention period can still be restored.
  
  For example, if Backup Cycle was set to Monday and Tuesday and Retention Period was set to 2, the deletion behavior is as follows:
  - The full backup created on Monday is automatically deleted on Thursday.
    The full backup created on Monday expires on Wednesday, but according to the deletion policy, the system retains the most recent full backup that has exceeded the retention period. So it is retained until a new backup expires. The next full backup is created on Tuesday and expires on Thursday. Therefore, on Thursday, the Monday backup is deleted and the Tuesday backup is retained.
  - The full backup created on Tuesday is automatically deleted on Wednesday of the following week.
    The backup generated on Tuesday is scheduled to expire on Thursday; however, as it is the last available backup, it is retained until a subsequent backup expires. The next backup is generated the following Monday and expires the following Wednesday, at which point the full backup generated on Tuesday is automatically deleted.
  Automatic deletion policy for binlog backups:
  
  Binlog backups are deleted along with full backups. To ensure data integrity, RDS for MySQL retains the most recent full backup beyond the specified retention period and all binlog backups generated from 24 hours before this full backup starts to the current time. This ensures that data within the retention period can be restored.
  
  Binlog backups refer to backup files stored in OBS, whereas local binlog retention policies govern the binlog files stored on disks. Please make sure to distinguish between them.
- Time Window: Set it to a one-hour period within the 24-hour day during which the backup task may start, such as 01:00-02:00 or 12:00-13:00. It indicates when the backup starts, not the duration of the entire backup task. The backup duration depends on the data volume of your instance.
  
  To minimize potential impact on workloads, set the time window to off-peak hours. The backup time window is saved using the UTC time zone of your local browser. It changes with the time zone if the DST or standard time is switched.
- Backup Cycle: All options are selected by default, but you can change them. Select at least one day of the week.
- Backup retention policy after instance deletion: Existing backups will be retained according to the selected policy when the instance is released.
  Retained backups will continue to be billed. For details, see Backup Space Pricing.
  - Automated Backup
    - Do not keep them: All automated backups of the instance are deleted when the instance is released.
    - Keep the last backup: Only the latest automated backup of the instance is retained after the instance is released.
    - Keep all: All existing automated backups of the instance are retained after the instance is released.
  - Manual Backup
    - Do not keep them: All manual backups of the instance are deleted when the instance is released.
    - Keep the last backup: Only the latest manual backup of the instance is retained after the instance is released.
    - Keep all: All manual backups of the instance are retained after the instance is released.
Click OK.

You can configure a standard backup policy for up to 50 instances at a time.

Log in to the RDS console.
Click in the upper left corner and select a region.
On the Instances page, select multiple instances and choose More > Configure Same-Region Backup Policy above the instance list.
In the displayed dialog box, specify the following parameters.
- Retention Period: It indicates how many days your automated full backups and binlog backups can be retained. The retention period is from 1 to 732 days and the default value is 7.
  - Extending the retention period enhances data availability.
  - If you shorten the retention period, the new backup policy applies to existing backups. Manual backups will not be deleted automatically. Exercise caution when making your selection.
  Automatic deletion policy for full backups:
  
  To ensure data integrity, the system keeps the most recent backup that has exceeded the retention period during automatic deletions. This ensures that data within the retention period can still be restored.
  
  For example, if Backup Cycle was set to Monday and Tuesday and Retention Period was set to 2, the deletion behavior is as follows:
  - The full backup created on Monday is automatically deleted on Thursday.
    The full backup created on Monday expires on Wednesday, but according to the deletion policy, the system retains the most recent full backup that has exceeded the retention period. So it is retained until a new backup expires. The next full backup is created on Tuesday and expires on Thursday. Therefore, on Thursday, the Monday backup is deleted and the Tuesday backup is retained.
  - The full backup created on Tuesday is automatically deleted on Wednesday of the following week.
    The backup generated on Tuesday is scheduled to expire on Thursday; however, as it is the last available backup, it is retained until a subsequent backup expires. The next backup is generated the following Monday and expires the following Wednesday, at which point the full backup generated on Tuesday is automatically deleted.
  Automatic deletion policy for binlog backups:
  
  Binlog backups are deleted along with full backups. To ensure data integrity, RDS for MySQL retains the most recent full backup beyond the specified retention period and all binlog backups generated from 24 hours before this full backup starts to the current time. This ensures that data within the retention period can be restored.
  
  Binlog backups refer to backup files stored in OBS, whereas local binlog retention policies govern the binlog files stored on disks. Please make sure to distinguish between them.
- Time Window: Set it to a one-hour period within the 24-hour day during which the backup task may start, such as 01:00-02:00 or 12:00-13:00. It indicates when the backup starts, not the duration of the entire backup task. The backup duration depends on the data volume of your instance.
  
  To minimize potential impact on workloads, set the time window to off-peak hours. The backup time is in UTC format. The backup time window changes with the time zone if the DST or standard time is switched.
- Backup Cycle: All options are selected by default, but you can change them. Select at least one day of the week.
- Backup retention policy after instance deletion: Existing backups will be retained according to the selected policy when the instance is released.
  Retained backups will continue to be billed. For details, see Backup Space Pricing.
  - Automated Backup
    - Do not keep them: All automated backups of the instance are deleted when the instance is released.
    - Keep the last backup: Only the latest automated backup of the instance is retained after the instance is released.
    - Keep all: All existing automated backups of the instance are retained after the instance is released.
  - Manual Backup
    - Do not keep them: All manual backups of the instance are deleted when the instance is released.
    - Keep the last backup: Only the latest manual backup of the instance is retained after the instance is released.
    - Keep all: All manual backups of the instance are retained after the instance is released.
Click OK.

FAQ

Why Has Automated Backup of My RDS Instance Failed?
Q: How Do I Clean Up Automated Backups?
A: Automated backups cannot be manually deleted. To delete them, you can adjust the retention period specified in your automated backup policy. Retained backups will be automatically deleted at the end of the retention period.