All Products
Search
Document Center

PolarDB:Backup and restoration

Last Updated:Dec 11, 2025

This topic describes the backup and restoration features and billing methods of PolarDB-X.

Backup

Backup types

PolarDB-X supports data and log backups.

  • Data backup: The system performs data backups and creates backup sets by using physical backup methods. You can restore data to the time when a backup set is created.

  • Log backup: Also known as incremental backup, it backs up binary logs that record data changes.

    When log backup is enabled, you can restore data to a specific time accurate to the second within the retention period by using data backups and log backups. For example, if a data backup set of an instance was created at 00:00:01 on January 1, 2021 and log backup is enabled, you can restore data to any second after 00:00:01 on January 1, 2021.

Backup modes

PolarDB-X supports automatic and manual backups.

  • Automatic backup: automatically triggered by the system at specific intervals.

    • The automatic backup policy is enabled by default and cannot be disabled. It includes data and log backups.

    • By default, data backups are performed twice a week (Monday and Thursday) and log backups are performed continuously. You can specify the time window and schedule for automatic backups.

  • Manual backup: manually triggered in the PolarDB-X console.

Note
  • Automatic backups must run at least once a week.

  • Make sure the previous backup is complete before starting a new one.

Storage location of backup files

  • Data backup: Data backup files are stored in Alibaba Cloud's storage system and do not occupy your database instance's storage space. By default, they are retained for 30 days.

  • Log backup: Log backup files are temporarily stored in your database instance. They are automatically uploaded to Alibaba Cloud's storage system after being stored for a specific period of time (7 hours by default) or when they use 30% of the instance's storage space. The files are retained for 7 days.

    You can configure the local log backup retention policy to prevent log backups from using too much storage space. For more information, see Data backup.

Impacts

In PolarDB-X, backups are performed on the secondary data nodes, which do not handle business traffic. This ensures that data and log backups do not consume the CPU resources of the primary node or impact instance performance.

Note

In rare cases where the secondary node is unavailable, data and log backups are performed on the primary node.

Restoration

Restoration methods

PolarDB-X supports restoration by backup set and point-in-time restoration.

  • Restoration by backup set: restores data from a specific backup set. You can restore data only to the time when the backup set was created.

  • Point-in-time restoration: uses data and log backups to restore data to any time (accurate to the second) within the retention period. For example, if a data backup set was created at 00:00:01 on January 1, 2021 and log backups are generated afterward, you can restore the instance data to any second after that time.

Data restoration locations

PolarDB-X supports data restoration only to a new instance. After data is restored, use tools such as DTS to import the data back to the original instance.

  • The new instance has the same whitelist, backup, and parameter configurations as the original instance.

  • The data in the new instance is the same as the data in the backup file or the data at the specified point in time.

  • The information about the account that is used to create the data backup or log backup is replicated to the new instance.

  • The new and original instances use the same topology, including the same number of nodes.

Global consistency

PolarDB-X is a distributed database where data is stored across multiple data nodes. If an instance contains distributed transactions, the instance must ensure data consistency across all nodes. The following figure shows how to ensure global consistency during account transfers.

image

PolarDB-X stores a table of account balances, with data distributed across two data nodes. The sum of the account balances is USD 200. In this example, distributed transactions are used to transfer money between different accounts.

At 16:14:20 on July 25, 2021, Account B transferred USD 30 to Account A, and Account D transferred USD 20 to Account C. To restore data to 16:14:20 on July 25, 2021 and ensure global consistency, you can restore data only to the specific point in time before or after the transactions are processed. In this case, the sum of the account balances must be USD 200, as shown in Restoration 2 in the preceding figure. In this scenario, data cannot be restored from Restoration 1. If data is restored based on Restoration 1, the sum of account balances during data restoration is equal to USD 250. This causes global inconsistency.