This topic provides answers to some frequently asked questions about the backup and restoration features of PolarDB for MySQL clusters.
Backup
How are the physical size and the logical size of backups calculated?
PolarDB uses two metrics to measure the size of backups: the logical size of each backup (② in the following figure) and the physical size of all backups (① in the following figure).
Logical size: the size of the data (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 mechanism for backups. Each snapshot in the chain represents the state of the data at a specific point in time. When a data block is modified, the system retains a historical version of the data block in a snapshot. The data on the snapshot chain is reduced only when the earlier snapshots expire.
Example: A cluster has 100 GB of data. The system performs level-1 backup/data backup once a day. The backup retention period is three days.
Date
Data modification
Size of data in the storage space
Snapshot chain size (physical size of backups)
Monday
100 GB of data added
100 GB+100 GB=200 GB
+0 GB=0 GB
NoteIn this case, the size of the snapshot chain (physical size of backups) before Monday is not considered.
Take note that the increased data amount is not 0 GB in actual business scenarios. If new data needs to be written into a block that is already referenced by a snapshot, the system creates a new copy of the data block for the writing. Therefore, write operations after a snapshot is generated lead to an increase in the snapshot chain 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 removed
NoteThe removed data is the data 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
NoteIn this case, the snapshot generated on Monday has expired. However, the size of the snapshot chain (physical size of backups) is not decreased, and the system continues to retain the historical version of the data block to be used for the backup set on Tuesday.
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
NoteIn this case, the snapshot generated on Tuesday expired. The data added on Monday was removed on Wednesday, and the system no longer retains the historical data block. Therefore, the size of the snapshot chain (physical size of backups) is decreased by 100 GB.
NoteThe preceding example is only for reference. In the example, the business data in the cluster is used, and system files are not considered.
If you want to reduce the physical size of backups when the frequency of data block modification remains the same, you can shorten the backup cycle and retention period. For more information, see the "How do I reduce the data volume and fees of level-1 backups, level-2 backups, and log backups? section of this topic.
Is the physical size of level-1 backups/data backups equal to the sum of the logical sizes of all backups?
No.
Level-1 backups
The physical size of level-1 backups (① in the following figure) refers to the actual amount of physical storage space that is exclusively occupied by all level-1 backups, not the sum of the logical sizes of all backups (② in the following figure).
Data backups
The physical size of data backups (① in the following figure) refers to the actual amount of physical storage space that is exclusively occupied by all data backups, not the sum of the logical sizes of all backups (② in the following figure).
Why is the physical size of level-1 backups/data backups sometimes smaller than the size of a single backup set?
PolarDB uses two metrics to measure the size of backups: the logical size of each backup and the physical size of all backups. PolarDB uses a snapshot chain mechanism for backups, which records identical data blocks only once. As a result, the total physical size of backups is smaller than the logical size. In some cases, the total physical size of backups is smaller than the logical size of a single backup.
How am I charged for backups in PolarDB?
You are charged for the storage space occupied by level-1 backups/data backups, level-2 backups, and log backups. By default, the level-1 backup/data backup and log backup features are enabled, and a free storage quota is provided for the backups. By default, the level-2 backup feature is disabled. For more information, see Backup storage beyond the free quota.
How are the fees of level-1 backups/data backups calculated?
Backup fees vary based on the storage type of your cluster.
PL0, PL1, PL2, PL3, and AutoPL Enterprise SSDs (ESSDs)
Hourly data backup fee = (Total size of data backups - Free quota) × Price per GB-hour
Free quota: Storage capacity × 50%
For example,a cluster is deployed in the Chinese mainland. The total size of data backups of the cluster is 700 GB, and the cluster storage capacity is 1,000 GB. The hourly data backup fee is calculated by using the following formula: (700 GB - 1,000 GB × 50%) × USD 0.00003231 per GB-hour = USD 0.006462 per hour. For more information, see Backup storage beyond the free quota.
PSL4 or PSL5
Hourly level-1 backup fee = (Total size of level-1 backups - Free quota) × Price per GB-hour
Free quota: The formula used to calculate the free quota varies based on the storage billing method.
Subscription storage billing method: Storage capacity × 50%.
Pay-as-you-go storage billing method: Storage usage × 50%.
For example, a cluster deployed in the Chinese mainland uses the PSL5 storage type and the pay-as-you-go storage billing method. If the total size of level-1 backups is 700 GB and the cluster storage usage is 1,000 GB, the hourly level-1 backup fee is calculated by using the following formula: (700 GB - 1,000 GB × 50%) × USD 0.000464 per GB-hour = USD 0.0928 per hour. For more information, see Backup storage beyond the free quota.
Can I use a storage plan to offset the storage fees of backups?
Yes. You can use a storage plan to offset the storage fees of your PolarDB clusters and the backups of the clusters. The storage plan first offsets the storage fees of all PolarDB clusters within your account. Then, the remaining capacity of the storage plan is applied to offset the storage fees of backups (including level-1 backups/data backups, level-2 backups, and log backups) beyond the free quota based on specified ratios until the storage plan is exhausted. If the storage plan does not have sufficient remaining capacity to offset the backup storage fees, you are charged for the excess storage space based on the pay-as-you-go billing method. For more information, see FAQ about storage plans.
How do I reduce the data volume and fees 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 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.
NoteShortening 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.
NoteShortening 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 settings.
Reduce the frequency of level-1 backup, for example, from once a day to three times a week.
NoteReducing 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 level-1 backups the only backups that can be manually created?
Yes.
How long are manually created backups retained?
The retention period of manually created backups is specified by the Backup Retention Period parameter. To view the parameter settings, log on to the PolarDB console and choose Settings and Management > Backup and Restoration > Backup Policy Settings. You can find the Backup Retention Period parameter in the Level-1 Backup/Data Backup settings in the Data Backup section. To modify the Backup Retention Period parameter, click Modify and specify a new retention period for manually created backups.
How do I view the size of level-2 backups?
To view the size of level-2 backups, log on to the PolarDB console and choose Settings and Management > Backup and Restoration. On the Data Backups tab, you can view the size of level-2 backups.
How do I view the retained backup sets after a cluster is released?
If you select long-term retention for backup sets when you release a cluster, you can view the backup sets in the recycle bin of the cluster in the PolarDB console. For more information, see Cluster recycle bin.
How do I download backup sets to my computer?
For information about how to download backup sets, see Download backup files. You cannot use the downloaded backup sets to directly restore data to the PolarDB for MySQL cluster, but you can use the backup sets to restore the data to a self-managed MySQL database. For more information, see Restore the data of a PolarDB cluster to a self-managed MySQL database by using snapshot backup files.
How do I archive backup files to OSS?
You can use one of the following methods to archive PolarDB for MySQL backup files to OSS:
Use Database Backup (DBS) to store PolarDB for MySQL backup files in Object Storage Service (OSS). Perform the following steps:
Log on to the OSS console and create buckets. For information about how to create buckets, see Create buckets.
Configure a backup schedule. For more information, see Configure a backup schedule. After the backup is complete, you can manage backup sets. For example, you can query or download backup sets. For more information, see Query backup sets or Download backup sets.
Use mysqldump or Data Management (DMS) to export backup files, and then upload them to OSS. Perform the following steps:
Use mysqldump or DMS to export PolarDB for MySQL backup files.
Manually upload the exported backup files to OSS. For more information, see Upload objects.
Restoration
Can I specify custom names for restored databases or tables?
Yes.
If my cluster does not have a data backup, can I restore the data to a previous point in time?
No. To restore data to a previous point in time, perform the following steps: Restore the data from a full backup created before the specified point in time to the cluster. Then, synchronize the incremental data to the cluster based on the redo logs generated between the time when the full backup was created and the specified point in time.
Can I use the cross-region backup and restoration features for a cluster for which transparent data encryption (TDE) is enabled?
Yes.
Can I enable TDE for a cluster after cross-region restoration?
Yes.