Updated on 2026-03-25 GMT+08:00

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 then RDS backs up data based on the automated backup 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 by week and cannot be deleted. Select at least one day in a week. The system can keep backups for 1 to 732 days.
  • There are three types of sparse backup policies. The system can keep backups for 1 to 732 days.
    • 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

A one-hour period the backup will be scheduled within 24 hours, such as 01:00-02:00 or 12:00-13:00

A one-hour period the backup will be scheduled within 24 hours, such as 01:00-02:00 or 12:00-13:00

CBR backup

Supported

Supported

Constraints and Billing

Table 2 Constraints

Category

Constraints

Billing

CBR 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 you delete a DB instance, its automated backups are also deleted but its manual backups are retained.
  • 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.
  • 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 the billing details, see How Is RDS Backup Data Billed?

CBR enabled

  • CBR backups depend on the Cloud Backup and Recovery (CBR) service. For details, see What Is CBR?
  • Enabling CBR backup will incur fees. CBR backups are billed by actual vault usage, which is calculated by CBR.
  • The backup time is proportional to how much data your instance has. Too much data can decrease the backup efficiency. If you have large amounts of data and want to speed up the backup process, submit a service ticket to enable CBR snapshot backup.
  • After CBR is enabled, snapshot backup is used. Existing automated and manual backups can still be used to restore data.
  • When you delete a DB instance, its automated backups are also deleted but its manual backups are retained.
  • DDL operations cannot be performed when a CBR snapshot is being created. If a DDL operation is being performed, a snapshot will be created after the DDL operation is complete.
  • After CBR is enabled, the next full backup is a snapshot backup. You can use the snapshot backup to restore data.
If CBR is enabled, CBR snapshots are billed as follows:
  • 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 storage space, RDS provides 80 GB backup space for free, including 40 GB for logs and 40 GB for CBR snapshots.

    Figure 1 Storage and backup

Procedure

  1. Click in the upper left corner and select a region.
  2. Click in the upper left corner of the page and choose Databases > Relational Database Service.
  3. On the Instances page, click the target DB instance name.
  4. In the navigation pane on the left, choose Backups & Restorations.
  5. 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.
      • Reducing the retention period takes effect for existing backups. Any backups (except manual backups) that have expired will be automatically deleted. Exercise caution when performing this operation.

      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 will expire on Thursday, but as it is the last backup, so it will be retained until a new backup expires. The next backup will be generated on the next Monday and will expire on the next Wednesday. So the full backup generated on Tuesday will not be automatically deleted until the next Wednesday.

    • Automatic deletion policy for binlog backups:

      To ensure data integrity, the system keeps the binlog backup of the previous day when the full backup is deleted. This ensures that data within the retention period can still be restored.

    • Time Window: Set it to a one-hour period the backup will be scheduled, 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 it. Select at least one day of the week.

  6. Click OK.

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

  1. On the Instances page, select multiple instances and choose More > Configure Same-Region Backup Policy above the instance list.
  2. 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.
      • Reducing the retention period takes effect for existing backups. Any backups (except manual backups) that have expired will be automatically deleted. Exercise caution when performing this operation.

      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 will expire on Thursday, but as it is the last backup, so it will be retained until a new backup expires. The next backup will be generated on the next Monday and will expire on the next Wednesday. So the full backup generated on Tuesday will not be automatically deleted until the next Wednesday.

    • Time Window: Set it to a one-hour period the backup will be scheduled, 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 it. Select at least one day of the week.

  3. Click OK.

FAQ