FAQ about the backup and recovery features of PolarDB - PolarDB

This topic answers frequently asked questions about the backup and recovery features of PolarDB for MySQL.

Backup

How are the physical and logical sizes of backups calculated?

PolarDB uses two metrics to measure backup size: the logical size of each backup (② in the following figure) and the physical size of all backups (① in the following figure).

Logical size: The data volume (data and logs) at a snapshot checkpoint time (③ in the following figure).

Physical size: The size of the backup snapshot chain. PolarDB uses an incremental snapshot chain for backups. This mechanism retains the snapshot state at each point in time. When a data block is modified, the system keeps the historical version of the data block for the snapshot. The data on the snapshot chain decreases only when earlier snapshots expire.

Example: Assume a cluster has 100 GB of data. A level-1 backup/data backup is performed once a day, and the retention period is 3 days.

Date	Data modification	Data size in storage	Snapshot chain size (physical backup size)
Monday	100 GB of data added	100 GB+100 GB=200 GB	+0 GB=0 GB Note The size of the snapshot chain (physical backup size) before Monday is not considered. Note that in a real-world scenario, the increment is not 0 GB. A data block referenced by a snapshot may not be fully written. If new data needs to be written to these data blocks, a new copy of the data block is created for writing. Therefore, writing data after a snapshot is created also increases the size of the snapshot chain (physical backup size).
Tuesday	1 GB of data modified and 1 GB of data added	200 GB+1 GB=201 GB	0 GB+1 GB=1 GB
Wednesday	100 GB of data deleted Note The deleted data is the data that was added on Monday.	201 GB-100 GB=101 GB	1 GB+100 GB=101 GB
Thursday	1 GB of data modified and 1 GB of data added	101 GB+1 GB=102 GB	101 GB+1 GB=102 GB
Friday	1 GB of data modified and 1 GB of data added	102 GB+1 GB=103 GB	102 GB+1 GB=103 GB Note At this point, the snapshot from Monday has expired. However, the size of the snapshot chain (physical backup size) does not decrease. The system continues to retain the historical version of the data block for the backup set from Tuesday to use.
Saturday	1 GB of data modified and 1 GB of data added	103 GB+1 GB=104 GB	103 GB+1 GB-100 GB=4 GB Note At this point, the snapshot from Tuesday has expired. Because the data added on Monday was deleted on Wednesday, the system no longer retains the historical data block. Therefore, the size of the snapshot chain (physical backup size) decreases by 100 GB.

Note

The preceding example is for reference only. It considers only the business data in the cluster and not system files. The actual size may vary.
To reduce the physical backup size while the data block modification frequency remains unchanged, you can reduce the backup cycle and retention period. For more information, see How do I reduce the data volume and costs of level-1 backups, level-2 backups, and log backups?

Is the physical size of level-1 backups/data backups the sum of all logical backup sizes?

No. The following sections describe level-1 backups and data backups:

Level-1 backup

The physical size of level-1 backups (① in the following figure) is not the sum of all logical backup sizes (② in the following figure). It is the total size of the physical space that all level-1 backups (snapshots) exclusively occupy.

Data backup

The physical size of data backups (① in the following figure) is not the sum of all logical backup sizes (② in the following figure). It is the total size of the physical space that all data backups (snapshots) exclusively occupy.

Why is the physical size of level-1 backups/data backups smaller than a single backup set?

PolarDB backups have two size metrics: the logical size of each backup set and the physical size of all backups. PolarDB uses a snapshot chain mechanism that records identical data blocks only once. Therefore, the total physical size is smaller than the total logical size, and can sometimes be smaller than a single logical backup size.

How am I charged for PolarDB backups?

You are charged for the storage space of level-1 backups/data backups, level-2 backups, and log backups. Level-1 backup/data backup and log backup are enabled by default, and a specific amount of free storage is provided. Level-2 backup is disabled by default. For more information, see Backup storage (beyond the free quota).

How are the costs of level-1 backups/data backups calculated?

Backup storage costs depend on the Storage Class of your cluster.

enterprise SSD (ESSD) (PL0, PL1, PL2, PL3, and AutoPL)
- Formula: Hourly fee = (Total data backup size - Free quota) × Hourly price
- Free quota: Storage capacity × 50%
Example: For a cluster in the Chinese mainland, if the total data backup size is 700 GB and the database storage usage is 1,000 GB, the hourly fee is [700 GB - (1,000 GB × 50%)] × USD 0.00003231/GB/hour = USD 0.006462/hour. For more information, see Backup storage (beyond the free quota).
PSL4/PSL5
- Formula: Hourly fee = (Total level-1 backup size - Free quota) × Hourly price
- Free quota: The formula to calculate the free quota varies based on the storage billing method. The formulas are as follows:
  - Subscription (billed by space): Storage capacity × 50%.
  - Pay-as-you-go (billed by capacity): Storage usage × 50%.
Example: For a cluster that uses the PSL5 storage class in the Chinese mainland, if the total level-1 backup (snapshot) size is 700 GB and the database storage usage is 1,000 GB, the hourly fee is [700 GB - (1,000 GB × 50%)] × USD 0.000464/GB/hour = USD 0.0928/hour. For more information, see Backup storage (beyond the free quota).

Can a storage plan offset backup storage costs?

Yes. After you purchase a storage plan, if there is remaining capacity after offsetting the storage usage of all PolarDB clusters under your account, the remaining capacity automatically offsets the backup storage usage (level-1/data backup, level-2 backup, and log backup) that exceeds the free quota, based on a specified deduction ratio, until the storage plan is depleted. If the remaining capacity is not enough to cover the backup storage usage, the excess usage is billed on a pay-as-you-go basis. For more information about storage plan deductions, see Storage plan FAQ .

How do I reduce the data volume and costs of level-1 backups, level-2 backups, and log backups?

Shorten the retention period of backup data based on your business requirements. For more information, see Configure backup policy settings.
- Shorten the retention period of level-1 backups, for example, from 7 days to 3 days.
- Shorten the retention period of level-2 backups, for example, from 70 days to 30 days.
  Note
  Shortening the retention period of level-1 and level-2 backups poses risks. If the backup set that you want to use to restore data exceeds the retention period, you cannot restore data by using the backup set.
- Shorten the retention period of log backups, for example, from 7 days to 3 days.
  Note
  Shortening the retention period of log backups poses risks. If the log backup set that you want to use to restore data exceeds the retention period, you cannot restore data to a specific point in time.
Reduce the backup frequency (backup cycle) based on your business requirements. For more information, see Configure backup policy settings.
- Reduce the frequency of level-1 backup, for example, from once a day to three times a week.
  Note
  Reducing the frequency of level-1 backup may increase the amount of time required to restore data to a point in time.
- Reduce the frequency of level-2 backup, for example, from three times per week to twice per week.
You can purchase storage plans to offset the fees of level-1 backup, level-2 backup, and log backup. For more information, see Storage plans.
Delete backup sets that you no longer require from the recycle bin of your cluster to reduce the costs of level-2 backup. For more information, see Delete a backup.

Are manual backups supported only for level-1 backups?

Yes.

What is the retention period for manual backups?

The retention period for manual backup files is determined by the Backup Retention Period setting for Level-1 Backup/Data Backup in the Data Backup section of the Backup Policy Settings.

How do I view the size of level-2 backups?

You can view the size of level-2 backups on the Data Backups tab of the Configuration and Management > Backup and Recovery page in the console.

How do I view retained backup sets after a cluster is released?

If you chose to retain backup sets for the long term when you released your cluster, you can view them in the cluster recycle bin in the PolarDB console. For more information, see Cluster recycle bin.

How do I download backup sets to a local machine?

You can download the backup files of your cluster to a local machine by following the instructions in Download a backup file. The downloaded backup data cannot be directly used to restore a PolarDB for MySQL cluster. However, you can use it to restore data from a backup file to a self-managed MySQL database.

How do I archive backup files to OSS for long-term storage?

You can use one of the following two methods to archive PolarDB for MySQL backup files to OSS for long-term storage:

Use the Alibaba Cloud DBS service to store PolarDB for MySQL backup files in OSS. The steps are as follows:
1. In the OSS console, create a bucket.
2. Manually configure a logical backup plan for PolarDB for MySQL. After the backup is complete, you can manage the backup sets. For example, you can query backup sets or download backup sets.
Use mysqldump or DMS to export backup files, and then upload them to OSS. The steps are as follows:
1. Use mysqldump or DMS to export PolarDB for MySQL backup files.
2. Manually upload the exported backup files to OSS. For more information, see Upload objects.

How to set alerts for failed backups?

This product does not currently support direct configuration of alerts for failed backups. To create a custom alert, periodically call the DescribeBackups API to get the BackupStatus field of a backup job. If the status is Failed, trigger a custom alert based on the result.

How do I set up alerts for backup failures?

This product does not support direct configuration of alerts for backup failures. However, you can create your own alerting mechanism. For example, periodically call the DescribeBackups API operation to get the BackupStatus field for a backup job. Check if the status is Failed. If it is, trigger a custom alert, such as an email, a text message, or a notification on your monitoring platform.

Recovery

Can I customize the names of new databases or tables after recovery?

Yes.

Can I perform a point-in-time restore without a data backup?

No. A point-in-time restore first restores a full data backup created before the selected point in time to the cluster. Then, it uses Redo logs to incrementally restore data to the selected point in time.

Do clusters with TDE enabled support the cross-region backup and recovery feature?

Yes.

Can I enable TDE on a cluster after a cross-region recovery?

Yes.

Will a recovered table affect the original database?

No. When you restore a specific database or table for a PolarDB for MySQL cluster, a new database or table is created in the current cluster for the recovery operation.