PolarDB:Backup and recovery FAQ

PolarDB measures backups using two metrics: the logical size of each backup set and the physical size of all backups combined.

• Logical size: The data volume (data and logs) captured at a consistent snapshot point in time (③ in the figure below).

• Physical size: The total size of the backup snapshot chain. PolarDB uses an incremental snapshot chain mechanism — when a data block is modified, the system retains the historical version of that block for the snapshot. Data is removed from the chain only when earlier snapshots expire.

Example: Assume a cluster starts with 100 GB of data, level-1 backups run once per day, and the retention period is 3 days.

Notes on the example:

• Monday: The +0 GB snapshot chain growth is a simplification that does not account for the snapshot chain size before Monday. In practice, writing data after a snapshot is created causes some growth because new data blocks are copied to preserve snapshot consistency.

• Friday: The Monday snapshot has expired, but the snapshot chain size does not decrease yet. The system still retains historical data blocks for the Tuesday backup set.

• Saturday: The Tuesday snapshot expires. The 100 GB added on Monday and deleted on Wednesday no longer needs to be retained in the chain, so the physical size drops by 100 GB.

• This example covers business data only and excludes system files. Actual sizes will differ.

No. The physical size is smaller — often much smaller — because PolarDB's snapshot chain stores each unique data block only once.

PolarDB's snapshot chain stores each unique data block only once across all snapshots. Because of this deduplication, 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 set.

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

The cost formula depends 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 (Chinese mainland): Total data backup size is 700 GB, database storage is 1,000 GB.

Hourly cost = (700 GB − 1,000 GB × 50%) × USD 0.00003231/GB/hour = USD 0.006462/hour

For pricing details, 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: Varies by Storage Payment Method:

  • Subscription (billed by space): Storage capacity × 50%

  • Pay-as-you-go (billed by capacity): Storage usage × 50%

Example (PSL5, Chinese mainland): Total level-1 backup size is 700 GB, database storage usage is 1,000 GB.

Hourly cost = (700 GB − 1,000 GB × 50%) × USD 0.000464/GB/hour = USD 0.0928/hour

For pricing details, see Backup storage (billed for usage that exceeds the free quota).

The following approaches reduce backup storage. Each carries trade-offs — review them before making changes.

Shorten retention periods — configure in Configure a backup policy:

Reduce backup frequency — configure in Configure a backup policy:

Delete unneeded backup sets from the cluster recycle bin to reduce level-2 backup costs. For details, see Delete a backup.

Yes.

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

Go to Settings and Management > Backup and Restoration in the console and open the Data Backups tab.

If you chose to retain backup sets when releasing the cluster, view them in the cluster recycle bin in the PolarDB console. For details, see Cluster recycle bin.

Follow the steps in Download a backup file. Downloaded backup data cannot be used to directly restore a PolarDB for MySQL cluster, but you can use it to restore data to a self-managed MySQL database. For details, see Restoring from a backup file to a self-managed MySQL database.

Two methods are available.

Method 1: Use Alibaba Cloud Database Backup Service (DBS)

1. In the OSS console, create a bucket.

2. Configure a logical backup schedule for PolarDB for MySQL in DBS.

3. After the backup completes, query backup sets or download backup sets as needed.

Method 2: Use mysqldump or Data Management (DMS)

1. Export backup files using mysqldump or DMS.

2. Upload the exported files to OSS.

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, and a backup is triggered only after a full 1 GB file is written. If the cluster was recently created or has low traffic, the redo log file may not have filled up yet — so no backup has been triggered and no records appear in the list.

Yes.

No. A point-in-time restore first restores a full data backup from before the selected point in time, then applies redo logs incrementally to bring the data up to the selected point.

Yes.

Yes.

No. PolarDB for MySQL creates a new database and table in the current cluster for the recovery operation — the original database is not modified.