PolarDB:Backup and recovery FAQ

PolarDB backups are measured by two metrics: 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 consistent snapshot point in time (③ in the following figure).

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

  Example: Assume that the data volume of a cluster is 100 GB. The backup cycle for level-1 backups/data backups is once per day, and the retention period is 3 days.

  Date	Data modification process	Data size in storage	Corresponding snapshot chain (physical backup) size
  Monday	Add 100 GB of data	100 GB + 100 GB = 200 GB	+ 0 GB = 0 GB Note This does not account for the size of the snapshot chain (physical backup) before Monday. In a real-world scenario, the increment is not 0 GB. The data blocks referenced by a snapshot may not be fully written. If new data must be written to these data blocks, a new copy of the data blocks is created. Therefore, writing data after a snapshot is created also increases the size of the snapshot chain (physical backup).
  Tuesday	Modify 1 GB of data and add 1 GB of data	200 GB + 1 GB = 201 GB	0 GB + 1 GB = 1 GB
  Wednesday	Delete 100 GB of data Note The deleted data is the data added on Monday.	201 GB - 100 GB = 101 GB	1 GB + 100 GB = 101 GB
  Thursday	Modify 1 GB of data and add 1 GB of data	101 GB + 1 GB = 102 GB	101 GB + 1 GB = 102 GB
  Friday	Modify 1 GB of data and add 1 GB of data	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) does not decrease. The system continues to retain the historical version of the data blocks for the backup set from Tuesday.
  Saturday	Modify 1 GB of data and add 1 GB of data	103 GB + 1 GB = 104 GB	103 GB + 1 GB - 100 GB = 4 GB Note At this point, the snapshot from Tuesday has expired. The system no longer needs to retain the historical version of the data blocks for the data that was added on Monday and deleted on Wednesday. Therefore, the size of the snapshot chain (physical backup) decreases by 100 GB.

  Note

  • The preceding example is for reference only. It considers only the business data in the cluster and does not include system files. The actual size may differ.

  • To reduce the physical backup size without changing the frequency of data block modifications, you can reduce the backup cycle and retention period. For more information, see How can I reduce the data volume and costs of level-1 backups, level-2 backups, and log backups?

  

No. The differences between Level-1 backup and data backup are as follows:

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 for backups, where each unique data block is stored only once. Therefore, the total physical size is smaller than the sum of the logical sizes and can sometimes be smaller than the logical size of a single backup.

You are charged for the storage space used by level-1 backups/data backups, level-2 backups, and log backups. Level-1 backups/data backups and log backups are enabled by default, and a free quota is provided. Level-2 backups are disabled by default. For more information, see Backup storage (billed for usage that exceeds the free quota).

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

• Enterprise SSD (PL0, PL1, PL2, PL3, and AutoPL)

  • Formula: Hourly cost = (Total data backup size - Free quota) × Hourly price

  • Free quota: Storage capacity × 50%

  Example: In the Chinese mainland, if the total data backup size is 700 GB and the database storage usage is 1,000 GB, the hourly cost is [700 GB - (1,000 GB × 50%)] × USD 0.00003231/GB/hour = USD 0.006462/hour. For more information, see Backup storage (billed for usage that exceeds the free quota).

• PSL4/PSL5

  • Formula: Hourly cost = (Total level-1 backup size - Free quota) × Hourly price

  • Free quota: The formula for calculating the free quota varies based on the Storage Payment 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 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 cost is [700 GB - (1,000 GB × 50%)] × USD 0.000464/GB/hour = USD 0.0928/hour. For more information, see Backup storage (billed for usage that exceeds the free quota).

• Shorten the retention period for backup data as needed. For more information, see Configure a backup policy.

  • Shorten the retention period for level-1 backups, for example, from 7 days to 3 days.

  • Shorten the retention period for level-2 backups, for example, from 70 days to 30 days.

    Note

    Shortening the retention period for level-1 and level-2 backups carries risks. If a backup set that you need is older than the retention period, you cannot use it to restore data.

  • Shorten the retention period for log backups, for example, from 7 days to 3 days.

    Note

    Shortening the retention period for log backups carries risks. You cannot perform a point-in-time restore to a time that is earlier than the oldest retained log backup.

• Reduce the backup frequency (backup cycle) as needed. For more information, see Configure a backup policy.

  • Reduce the frequency of level-1 backups, for example, from once a day to three times a week.

    Note

    Reducing the frequency of level-1 backups may increase the time required for a point-in-time restore.

  • Reduce the frequency of level-2 backups, for example, from three times a week to twice a week.

• Delete unneeded backup sets from the cluster recycle bin to reduce the costs of level-2 backups. For more information, see Delete a backup.

Yes.

The retention period for manual backup files is determined by the Backup Retention Period that you set for Level-1 Backup or Level-2 Backup under Data Backup in the Backup Policy Settings.

You can view the size of a level-2 backup on the Data Backups tab. To access this tab, go to the Settings and Management > Backup and Restoration page in the console.

If you choose to retain backup sets when you release a cluster, you can view them in the cluster recycle bin in the PolarDB console. For more information, see Cluster recycle bin.

You can download a backup file to your computer. However, you cannot directly use the downloaded backup data to restore a PolarDB for MySQL cluster. You can use it to restore data from a backup file to a self-managed MySQL database.

You can use one of the following methods to perform long-term archiving of PolarDB for MySQL backup files to OSS:

• Use Alibaba Cloud Database Backup Service (DBS) to store PolarDB for MySQL backup files in OSS. Perform the following steps:

  1. In the OSS console, create a bucket.

  2. Manually configure a logical backup schedule for PolarDB for MySQL. After the backup is complete, you can manage the backup set. For example, you can 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:

  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 files.

The product does not currently support direct configuration of alerts for backup failures. However, you can implement your own alerting mechanism. For example, you can periodically call the DescribeBackups operation to retrieve the BackupStatus field of a backup job. You can then check its status and trigger a custom alert, such as an email, a text message, or a notification on a monitoring platform, if the status is Failed.

The physical logs of a PolarDB cluster are redo logs. Each redo log file has a fixed size of 1 GB. A backup is triggered only after a 1 GB file is completely written. If a cluster was recently created or has a low access volume, the 1 GB redo log file may not be full. In this case, a backup is not triggered, and no records appear in the redo log backup list.

This is supported.

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

Supported.

Supported.

No, it does not. PolarDB for MySQL creates a new database and table in the current cluster for the recovery operation.