Data Management:Data Disaster Recovery (formerly DBS) FAQ

What are the billable items of a backup schedule?

A backup schedule has up to four billable items:

• Type: You pay for the backup schedule's specifications when you purchase a subscription. The free quota for backup data, unit price, and backup and restoration performance all vary by schedule type. For details, see Backup fees.

• Storage (optional): If you set the storage type to DBS Storage for a subscription backup schedule, you're charged for the storage space used and the duration it's stored. For details, see Storage fees.

• Backup (optional): If the amount of backed-up data exceeds the free quota for your schedule type, the excess is charged. For details, see Backup fees.

• Sandbox (optional): Data Disaster Recovery lets you create sandbox instances for disaster recovery of self-managed MySQL databases. Once enabled, sandbox storage fees apply based on data volume; sandbox instance fees apply based on specifications and usage duration. For details, see Pricing.

You cannot create a pay-as-you-go backup schedule.

Which fees can storage plans and network plans offset?

Storage plans

Data Disaster Recovery offers two types of storage plans, available in various sizes (100 GB, 500 GB, 1 TB, and 500 TB) and subscription periods (one month, six months, and one year). If your storage exceeds your plan quota, you're charged for the excess on a pay-as-you-go basis.

Network plans

Data Disaster Recovery network plans work in all regions worldwide.

For offset rules, offset factors, examples, and purchase methods, see Use storage plans and Use network plans.

Am I charged for an unused backup schedule?

Yes. Even if a backup schedule hasn't generated new backup sets, existing backup sets still occupy storage. You're still charged storage fees.

To avoid unnecessary costs:

• Pay-as-you-go: Release the backup schedule after saving relevant data and downloading historical backup sets. After release, no backup or storage fees are charged. See Release or unsubscribe from a backup schedule.

• Subscription (pre-paid): If you plan to stop using a subscription backup schedule for an extended period but want to retain historical backup sets, you can pause or restart the backup schedule. After you pause the schedule, no new backup fees are charged, but storage fees will continue to apply to subscription backup schedules that use DBS Storage.

• Subscription: If you want to keep historical backup sets but stop running backups, pause the backup schedule. No backup fees are charged while paused, but storage fees still apply if the storage type is DBS Storage. See Pause or start a backup schedule.

Pausing a subscription backup schedule doesn't change its subscription duration.

Storage fees apply only when the storage type is DBS Storage.

For how to release a backup schedule or reduce backup file sizes, see View and reduce the size of backup data, Delete backup files or reduce the size of backup files, and Use the backup for deleted instances feature.

Can I switch between subscription and pay-as-you-go billing?

No. You cannot change the billing method of a backup schedule from pay-as-you-go to subscription, or from subscription to pay-as-you-go.

Can I release a pay-as-you-go backup schedule?

Yes. See Release or unsubscribe from a backup schedule.

Can I unsubscribe from a subscription backup schedule?

No. You cannot release or unsubscribe from a subscription backup schedule. See Unsubscribe from billable features.You cannot unsubscribe from a backup schedule

What happens when a storage plan or network plan expires?

Storage plans and network plans become invalid after they expire and can no longer offset storage or network traffic fees. Your backup schedules and existing backup data are not affected.

What happens when a backup schedule expires or payment is overdue?

See Service expiration and overdue payments.

How do I reduce the cost of a subscription backup schedule?

Purchase storage plans to offset built-in storage fees for backup schedules within the same Alibaba Cloud account. See Built-in storage and OSS.

What are the billable items if I haven't used backup in the console?

Data Disaster Recovery also provides backup and restoration for ApsaraDB RDS, PolarDB, ApsaraDB for MongoDB, Redis, Tair, and AnalyticDB for PostgreSQL. Check whether you're being charged for backup and restoration features used through those services. See Pricing.

Step 1: Assign the AliyunServiceRoleForDBS role

The AliyunServiceRoleForDBS is a Resource Access Management (RAM) service-linked role that allows Data Disaster Recovery to access Alibaba Cloud database services—including ApsaraDB RDS, ApsaraDB for MongoDB, Redis, PolarDB clusters, and self-managed databases hosted on Elastic Compute Service (ECS) instances. For details about service-linked roles, see Service-linked roles.

1. Log on to the DMS console V5.0.

2. In the top navigation bar, choose Security and Specifications (DBS) > Disaster Recovery for Data (DBS) > Disaster Recovery Data Source.

   In simple mode, hover over the icon in the upper-left corner and choose All Features > Security and Specifications (DBS) > Disaster Recovery for Data (DBS) > Disaster Recovery Data Source.

3. In the dialog box that appears, click Authorize DBS SLR.

   If no dialog box appears after you log on, skip this step and create a backup schedule directly. See Manage a backup by using a disaster recovery data source or Create a backup by using a backup schedule list.

4. Click OK.

The AliyunServiceRoleForDBS role is created. To delete the role later, see Delete a RAM role.

Step 2: Activate OSS

Activating OSS is free. After activation, Data Disaster Recovery can store backup data in OSS.

1. Log on to the DMS console V5.0.

2. In the top navigation bar, choose Security and Specifications (DBS) > Disaster Recovery for Data (DBS) > Backup Plan.

   In simple mode, hover over the icon in the upper-left corner and choose All Features > Security and Specifications (DBS) > Disaster Recovery for Data (DBS) > Backup Plan.

3. In the dialog box that appears, click Activate OSS Now.

4. In the next dialog box, click Activate Now

5. On the OSS page, read and agree to the service agreement by selecting the check box, then click Activate Now.

Data Disaster Recovery is now activated.

AliyunServiceRoleForDBS

Role name: AliyunServiceRoleForDBS

Policy attached to the role: AliyunServiceRolePolicyForDBS

Permissions:

{
  "Version": "1",
  "Statement": [
    {
      "Action": [
        "rds:DescribeDBInstanceNetInfo",
        "rds:DescribeDBInstanceNetInfoForChannel",
        "rds:DescribeTasks",
        "rds:DescribeDBInstances",
        "rds:DescribeFilesForSQLServer",
        "rds:DescribeImportsForSQLServer",
        "rds:DescribeSlowLogRecords",
        "rds:DescribeBinlogFiles",
        "rds:DescribeSQLLogRecords",
        "rds:DescribeParameters",
        "rds:DescribeParameterTemplates",
        "rds:DescribeDBInstanceAttribute",
        "rds:DescribeDatabases",
        "rds:DescribeAccounts",
        "rds:DescribeSecurityIPList",
        "rds:DescribeSecurityIps",
        "rds:DescribeDBInstanceIPArray",
        "rds:DescribeDBInstanceIPArrayList",
        "rds:DescribeDBInstanceSSL",
        "rds:DescribeDBInstanceTDE",
        "rds:CreateDBInstance",
        "rds:CreateAccount",
        "rds:CreateDatabase",
        "rds:ModifySecurityIps",
        "rds:GrantAccountPrivilege",
        "rds:CreateMigrateTask",
        "rds:CreateOnlineDatabaseTask",
        "rds:DescribeMigrateTasks",
        "rds:DescribeOssDownloads",
        "rds:CreateBackup",
        "rds:DescribeBackups",
        "rds:DescribeBackupPolicy",
        "rds:ModifyBackupPolicy",
        "rds:DescribeBackupTasks",
        "rds:DescribeBinlogFiles"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "ecs:DescribeInstance",
        "ecs:DescribeInstances",
        "ecs:DescribeVpcs",
        "ecs:DescribeSecurityGroups",
        "ecs:DescribeSecurityGroupAttribute",
        "ecs:AuthorizeSecurityGroup",
        "ecs:JoinSecurityGroup",
        "ecs:RevokerSecurityGroup"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "kms:ListKeys"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "cms:PutEventRule",
        "cms:PutEventTargets",
        "cms:ListEventRules",
        "cms:ListEventTargetsByRule",
        "cms:DeleteEventRule",
        "cms:DeleteEventTargets"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "polardb:DescribeDBClusterIPArrayList",
        "polardb:DescribeDBClusterNetInfo",
        "polardb:DescribeDBClusters",
        "polardb:ModifySecurityIps",
        "polardb:DescribeDBClusterEndpoints",
        "polardb:DescribeDBClusterAccessWhitelist",
        "polardb:ModifyDBClusterAccessWhitelist"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "dds:DescribeDBInstanceAttribute",
        "dds:DescribeReplicaSetRole",
        "dds:DescribeSecurityIps",
        "dds:DescribeDBInstances",
        "dds:ModifySecurityIps"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "kvstore:DescribeSecurityIps",
        "kvstore:DescribeInstances",
        "kvstore:DescribeAccounts",
        "kvstore:DescribeDBInstanceNetInfo",
        "kvstore:CreateAccount",
        "kvstore:ModifySecurityIps",
        "kvstore:DescribeInstanceAttribute",
        "kvstore:AllocateInstancePrivateConnection",
        "kvstore:DescribeLogicInstanceTopology"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "drds:DescribeDrdsDB",
        "drds:DescribeDrdsDBs",
        "drds:DescribeDrdsDbInstance",
        "drds:DescribeDrdsDbInstances",
        "drds:DescribeDrdsDBIpWhiteList",
        "drds:DescribeDrdsInstances",
        "drds:ModifyDrdsIpWhiteList",
        "drds:CreateDrdsDB",
        "drds:DescribeTable",
        "drds:DescribeTables",
        "drds:ModifyRdsReadWeight",
        "drds:ChangeAccountPassword",
        "drds:CreateDrdsInstance",
        "drds:CreateInstanceAccount",
        "drds:CreateInstanceInternetAddress",
        "drds:DescribeInstanceAccounts"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "vpc:DescribeVpcs"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "bssapi:QueryResourcePackageInstances"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": "hdm:AddHDMInstance",
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": "ram:DeleteServiceLinkedRole",
      "Resource": "*",
      "Effect": "Allow",
      "Condition": {
        "StringEquals": {
          "ram:ServiceName": "dbs.aliyuncs.com"
        }
      }
    }
  ]
}

Lifecycle rules

The lifecycle of a backup set ranges from seven days to 3,650 days (10 years). Data Disaster Recovery automatically deletes expired backup sets from a backup schedule, but only when the schedule contains more than three full backup sets. If the count is three or fewer, expired backup sets are not deleted.

To trigger the cleanup policy, run a manual backup or wait for the next scheduled backup until the full backup set count exceeds three. See Manually initiate a backup task.

If you manually delete full backup sets and the count drops to three or fewer, the cleanup policy stops running. Incremental backup sets continue to accumulate and occupy storage. To stop incremental backup, disable it manually. See Enable or disable incremental log backup.

Lifecycle rule changes apply to both new and existing backup sets.

Modify lifecycle rules

See Modify the backup policy of a backup schedule or Modify the lifecycle of a backup schedule.

More operations

To view backup sizes or reduce backup frequency, see Delete backup sets or reduce the backup frequency.

FAQ

Why aren't backup sets deleted after the lifecycle expires?

The cleanup policy only runs when a backup schedule has more than three full backup sets. If the count is three or fewer, expired backup sets are kept regardless of lifecycle settings.

Why does an expired incremental backup still occupy storage?

You've likely manually deleted full backup sets, bringing the count to three or fewer. With the cleanup policy inactive, incremental backup sets accumulate indefinitely. See the Lifecycle rules section above.

Key concepts

When to use this

• The original backup source database has been migrated or decommissioned and you want to switch to a different database.

• Testing is complete and you want to switch from a test database to a production database.

• The database account or password is incorrect, or the account lacks sufficient permissions.

• The tables in the backup source have changed and you want to update the backup objects.

Change the database account, password, or backup objects

Change only backup objects

1. Find the backup schedule and click Manage in the Actions column. The Configure Task page appears.

2. In the Basic Information section, click Edit Backup Objects.

   

3. Update the backup objects and click Save.

   • To add a database, select it in the Available section and click the icon.

   • To remove a database, select it in the Selected section and click the icon.

   

4. In the Start Full Data Backup dialog box, click OK or Close

   • OK: A full backup starts in about one minute for the updated backup objects. Perform this during off-peak hours to minimize impact on the source database.

   • Close: The updated configuration is saved, but no immediate backup runs. The next scheduled full backup uses the new configuration.

When this applies

During the precheck step of configuring a backup schedule, the precheck fails with a message indicating that binlog_format is not set to ROW. See Back up an on-premise database or cloud database from a third-party provider.

Usage notes

• Set binlog_format to ROW. In ROW mode, the before and after images of rows affected by DML operations are logged, which enables accurate data restoration.

• Avoid STATEMENT or MIXED mode—ROW mode is more stable and reliable.

• Changing binlog_format to ROW only affects binary logs and doesn't impact query performance. To make the change take effect for all connections, kill existing database connections.

Procedure

1. Run the following command using a privileged account on the source database:

   SET GLOBAL binlog_format = 'ROW';

   To verify the current value:

   SHOW GLOBAL VARIABLES LIKE 'binlog_format';

2. Kill all existing database connections. Without this step, connected processes may continue writing in non-ROW mode, causing inconsistent incremental data.

Prerequisites

• A backup schedule is purchased. Set the Data Source Type to MySQL and Backup Method to Logical Backup when purchasing. See Create a backup schedule.

• A read-only ApsaraDB RDS for MySQL instance exists. See Create a read-only ApsaraDB RDS for MySQL instance.

• Depending on the connection method:

  • Public endpoint (Method 1): The public endpoint of the read-only instance is obtained. See View and manage instance endpoints and ports. The Data Disaster Recovery server CIDR blocks are added to the instance whitelist. When configuring the backup schedule, set Database Location to User-Created Database with Public IP Address \<IP Address:Port Number\> and click Set Whitelist to get the CIDR blocks.

  • Internal endpoint (Method 2): The real-time internal IP address is obtained by running ping on your local device against the internal endpoint. The Data Disaster Recovery server CIDR blocks are added to the instance whitelist. When configuring the backup schedule, set Database Location to RDS Instance and click Set Whitelist. > Important: The internal IP address obtained this way is a real-time IP. If you clone the instance, migrate it to another zone, or change its VPC or vSwitch, the internal IP may change, causing backup failures.

Usage notes

• Public endpoint backups: Binary logs may be delayed. On the Backup and Restoration page of the read-only instance, set the Retention Period parameter to a larger value. The default is 18 hours.

  

• Internal endpoint backups: If you clone the read-only instance, migrate it to another zone, or change its VPC or vSwitch, the real-time internal IP may change. When this happens, backups fail. Get a new real-time IP and reconfigure the backup source. See the Prerequisites section and Modify the backup source database.

Get the internal and public endpoints

1. Go to the Instances page. Select the region where the RDS instance resides and click the instance ID.

2. On the Basic Information page, click View Details next to the Network Type parameter to see the internal and public endpoints.

   If no public endpoint exists, click Apply for Public Endpoint > OK to request one.

   

   

FAQ

Why does the source instance fail to connect when using the internal endpoint?

The internal IP obtained by running ping is a real-time IP. Cloning the read-only instance, migrating it to another zone, or changing its VPC or vSwitch can cause this IP to change, breaking the backup connection.

To fix this, run ping again against the internal endpoint to get the updated IP, then reconfigure the backup source. See Modify the backup source database.

Can Data Disaster Recovery back up both full data and incremental data for a read-only instance?

Yes.