Backup and recovery - PolarDB - Alibaba Cloud Documentation Center

Data is a core asset for enterprises. As the business of enterprises grows, data increases exponentially. This requires business applications to be able to process data online and in real time. Database O&M personnel face great challenges in protecting the core data of enterprises because issues, such as accidental data deletion, system vulnerabilities and ransomware, hardware failures, and natural disasters, can cause data loss. Therefore, backup and restoration are important features of databases.

PolarDB supports data backups and redo log backups:

Data backup: Creates a backup set (snapshot) of a cluster's complete data at a specific point in time. This is a full backup.
Redo log backup: Records the incremental data generated after a backup set is created. This is an incremental backup.

Note

A PolarDB cluster recovery restores data to the current cluster by using a backup set (snapshot).
A PolarDB database or table recovery creates a new database or table in the current cluster to restore the data.

Using a full data backup with its subsequent redo log backups allows you to restore an entire PolarDB cluster or specific databases and tables to any point in time.

Billing rules

You can use the backup and restoration feature free of charge. However, backup files consume storage space. For more information about billing rules, see Backup storage beyond the free quota.
For more information about how to view your bills, see Bills.

Note

If you select to retain backup sets for a long time when you manually unsubscribe or release your cluster, the backup sets are automatically moved to the cluster recycle bin. In this case, level-1 backup files automatically become level-2 backup files and you are charged. For more information, see Cluster recycle bin.

Data backup

PSL4/PSL5

Level-1 backup

Level-1 backups use redirect-on-write (ROW) snapshots and are stored directly in the PolarDB distributed storage system. When a level-1 backup is created, data is not copied. When a data block is modified, the system retains a historical version of the block for the snapshot and generates a new block that is referenced by the source data. This process is called a redirect. This method allows backups to finish in seconds, regardless of the database size.

PolarDB backup and recovery features use multi-threaded parallel processing and other innovations to restore a new cluster from a backup set (snapshot) in about 10 minutes. The recovery time doubles if a hot standby cluster is enabled. The actual recovery time varies based on factors such as the database size.

Level-1 backup size

You can go to the PolarDB console and navigate to the Settings and Management > Backup and Restoration page to view the physical size of level-1 backups. The following figure shows an example:

Note

PolarDB cluster Physical Size of Level-1 Backups (shown as ① in the figure above): This is the total physical space exclusively occupied by all level-1 backups. This value is used as the baseline to calculate the actual storage usage of level-1 backups.
PolarDB cluster Logical Size of Backups (indicated by ② in the preceding figure): The logical size of a single backup set. This size is not used for billing.
The data of a PolarDB cluster and its multiple level-1 backups (snapshots) share the same physical data blocks. These shared blocks are billed only once.

For more information about backups, see the FAQ.

Note

Level-1 backup is enabled by default and cannot be disabled.
The retention period for level-1 backups is 3 to 14 days.

Level-2 backup

A level-2 backup is a compressed version of a level-1 backup stored on a separate, offline storage medium. It has a lower storage cost, but restoring data from a level-2 backup is slower.
If you enable level-2 backup, level-1 backups are automatically converted to level-2 backups after their specified retention period expires.
Level-2 backups support single-region backup and cross-region backup. For more information, see Single-region and cross-region backups.

Level-2 backup size

You can go to the PolarDB console and navigate to the Settings and Management > Backup and Restoration page to view the total size of level-2 backups. The total size of level-2 backups is the sum of the sizes of all individual level-2 backup files. The following figure shows an example:

Note

If a level-1 backup takes too long to be converted to a level-2 backup, the next expiring level-1 backup may be deleted instead of being converted. For example, your PolarDB cluster creates a level-1 backup daily at 01:00 with a 24-hour retention period. PolarDB creates Backup A at 01:00 on January 1. At 01:00 on January 2, Backup A expires and starts converting to a level-2 backup. If this conversion is for a large file and is still running at 01:00 on January 3, Backup B (created on January 2) will expire and be deleted immediately instead of being converted.
Level-2 backup is disabled by default.
The retention period for level-2 backups is 30 to 7,300 days.

ESSD

Level-1 backups are snapshots stored locally on a distributed storage cluster. They offer the fastest backup and recovery speeds but at a higher cost. Long-term storage can slightly affect the write performance of the database. We recommend a retention period of no more than two weeks. A free quota for backup storage is provided. You are charged for usage that exceeds the free quota. You can change the backup cycle to control backup capacity.

Note

Level-1 backup is enabled by default and cannot be disabled.
The retention period for level-1 backups is 3 to 14 days.

Level-1 backup size

Note

PolarDB cluster Physical Size of Level-1 Backups (indicated by ① in the figure above): This is the total physical space exclusively occupied by all level-1 backups. This value is used as the baseline to calculate the actual usage of level-1 backup storage.
PolarDB cluster Logical Size of Backups (indicated by ② in the figure above): The logical size of a single backup set, which is not used for billing.
The data of a PolarDB cluster and its multiple level-1 backups (snapshots) share the same physical data blocks. These shared blocks are billed only once.

For more information about backups, see the FAQ.

Redo log backup

PolarDB creates log backups by uploading redo logs to Object Storage Service (OSS) in parallel and in real time. Log backups support single-region backup and cross-region backup, with a retention period from 3 to 7,300 days. You can also enable the Long-term Retain Backups before Cluster Deletion feature for long-term storage.

Note

Currently, only the Enterprise Edition supports the Long-term Retain Backups before Cluster Deletion option.
Single-region backup for logs is enabled by default and cannot be disabled.

Log backups enable point-in-time recovery (PITR). By combining a full data backup (snapshot) with subsequent log backups, you can restore a PolarDB cluster to any point in time. This protects your recent data from being lost due to accidental operations. The recovery speed for applying redo logs is about 20 to 70 seconds per GB. The total recovery time is the sum of the snapshot restoration time and the redo log application time.

Backup size

The total size of log backups is the sum of the sizes of all individual log backup files. The following figure shows an example:

日志大小

Risk assessment

If the redo log generation rate of a PolarDB for MySQL cluster reaches 35 MB/s to 50 MB/s, redo logs may accumulate. This can increase your backup storage costs.

Backup data protection

Tamper-proofing:
- Data backups in PolarDB for MySQL are categorized as level-1 or level-2 backups based on their storage location. Level-1 backups are stored as snapshots in the PolarDB distributed storage system. Level-2 backups and log backups are stored in OSS. Both backup storage methods provide Write Once, Read Many (WORM) immutability.
  Note
  Standard Edition clusters support only level-1 backups (data backups) and do not support level-2 backups.
Protection against malicious or accidental deletion:
- Manual deletion: You can only delete data from manual backups. You cannot delete data from automatic backups.
- Automatic backups are automatically deleted after their configured retention period expires. However, you cannot disable the automatic backup feature. In the backup policy settings, the minimum retention period is 3 days (7 days by default), and backups must be performed at least twice a week. Therefore, full backup data and log data from automatic backups cannot be completely deleted.

Single-region and cross-region backups

Backup description

Backup type	Description	Enabled by default	Use cases	Benefits
Single-region backup	Backups are stored in a different availability zone within the same region.	Yes. Note When you enable level-2 backup, single-region backup is enabled by default.	Long-term archiving.	Reduces costs by allowing less frequent backup transfers.
Cross-region backup	Backups are stored in a region other than the source region. Important This feature is available only for PolarDB for MySQL Enterprise Edition.	No. You must enable it manually.	Geo-redundant backup and MLPS Level 3 compliance.	Provides a low Recovery Point Objective (RPO) and is ideal for secure, non-public environments. You can reduce costs by setting a lower frequency for backup transfers.

Note

Low-frequency level-2 backup: The backup cycle for level-2 backups is set to a lower frequency than that of level-1 backups.

Supported regions for cross-region backup

Source region	Destination region
the Chinese mainland	the Chinese mainland
	US (Silicon Valley), US (Virginia)
	China (Hong Kong)
	Singapore, Indonesia (Jakarta), Japan (Tokyo), Malaysia (Kuala Lumpur)
	Germany (Frankfurt)
China (Hong Kong)	the Chinese mainland
	US (Silicon Valley), US (Virginia)
	Japan (Tokyo), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta)
	Germany (Frankfurt)
Japan (Tokyo)	the Chinese mainland
	US (Silicon Valley), US (Virginia)
	China (Hong Kong)
	Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta)
	Germany (Frankfurt)
US (Silicon Valley)	the Chinese mainland
	US (Virginia)
	China (Hong Kong)
	Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta)
	Germany (Frankfurt)
US (Virginia)	the Chinese mainland
	US (Silicon Valley)
	China (Hong Kong)
	Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta)
	Germany (Frankfurt)
Singapore	the Chinese mainland
	US (Silicon Valley), US (Virginia)
	China (Hong Kong)
	Malaysia (Kuala Lumpur), Indonesia (Jakarta)
	Germany (Frankfurt)
Malaysia (Kuala Lumpur)	the Chinese mainland
	US (Silicon Valley), US (Virginia)
	China (Hong Kong)
	Singapore, Indonesia (Jakarta), Japan (Tokyo)
	Germany (Frankfurt)
Indonesia (Jakarta)	the Chinese mainland
	US (Silicon Valley), US (Virginia)
	China (Hong Kong)
	Singapore, Japan (Tokyo), Malaysia (Kuala Lumpur)
	Germany (Frankfurt)
Germany (Frankfurt)	the Chinese mainland
	US (Silicon Valley), US (Virginia)
	China (Hong Kong)
	Singapore, Indonesia (Jakarta), Japan (Tokyo), Malaysia (Kuala Lumpur)
China (Hangzhou) Finance Cloud	China (Shanghai) Finance Cloud, China (Shenzhen) Finance Cloud
China (Shanghai) Finance Cloud	China (Hangzhou) Finance Cloud, China (Shenzhen) Finance Cloud
China (Shenzhen) Finance Cloud	China (Hangzhou) Finance Cloud, China (Shanghai) Finance Cloud

FAQ

For answers to frequently asked questions about backup and recovery, see FAQ.