All Products
Search
Document Center

PolarDB:Overview

Last Updated:Oct 19, 2023

This topic describes how to enable PolarDB for PostgreSQL(Compatible with Oracle) to automatically create backups at specified intervals or manually create backups to prevent data loss in a timely manner. PolarDB for PostgreSQL(Compatible with Oracle) allows you to retain backups of a cluster when you delete the cluster.

Data backup

Data backups are divided into level-1 backups and level-2 backups by storage location.

Storage locationDefault configurationRetention periodBenefitView backup size
Level-1 backupYes3 to 14 days
  • Level-1 backups are created based on Redirect-on-Write (ROW) snapshots. These snapshots are stored in the distributed file system of PolarDB for MySQL. The system does not replicate data when it saves a data block to a snapshot. When a data block is modified, the system saves one of the previous versions of the data block to a snapshot and creates a new data block that is redirected by the original data block. Therefore, you can create backups within a few seconds regardless of the size of your database storage.
  • The backup and restoration features of PolarDB for MySQL clusters use multi-threading parallel processing and other innovative technologies. This allows you to restore data from a backup set (snapshot) to a new cluster within 10 minutes.
Note By default, the level-1 backup feature is enabled, and you cannot disable this feature.
The following figure shows the total physical storage of level-1 backups. Total size of level-1 backups (snapshots)
Note The total size of level-1 backups of a PolarDB for MySQL cluster is the sum of the dedicated physical storage occupied by all level-1 backups, as shown in part ①. It is not the sum of the logical data sizes of all level-1 backups, as shown in part ②. The data of the PolarDB for MySQL cluster and multiple level-1 backups (snapshots) can be stored in the same physical data block that is billed only once. For more information, see FAQ.
Level-2 backupNo
  • 30 to 7,300 days
  • Enable the Permanently Retain Backups before Cluster Deletion feature to save level-2 backups permanently.
  • Level-2 backups are level-1 backups that are compressed and then stored in on-premises storage. Level-2 backups are slower to restore than level-1 backups. However, level-2 backups are more cost-effective than level-1 backups.
  • If you enable this feature, expired level-1 backups are transferred to on-premises storage and stored as level-2 backups. The backups are transferred at a rate of approximately 150 MB/s.
Note If a level-1 backup expires before the previous one is transferred to a level-2 backup, the level-1 backup is deleted and is not transferred to a level-2 backup. For example, a PolarDB for MySQL cluster creates level-1 backups at 01:00 every day and retains the backups for 24 hours. If the PolarDB for MySQL cluster creates Level-1 Backup A at 01:00 on January 1 and creates Level-1 Backup B at 01:00 on January 2. Level-1 Backup A expires at 01:00 on January 2 and starts to be transferred to a level-2 backup. However, Level-1 Backup A stores a large amount of data, and the transfer task is not completed by 01:00 on January 3. In this case, Level-1 Backup B is deleted after it expires at 01:00 on January 3 and is not transferred to a level-2 backup.
The following figure shows the total size of level-2 backups. The total size of level-2 backups is the sum of the data sizes of all level-2 backups. 2

Physical log backup

  • Benefits

    The log backup feature allows you to create backups by uploading real-time redo logs to Object Storage Service (OSS) in parallel. The feature is enabled by default, and log backups are retained for 3 to 7,300 days. You can save the backups permanently by enabling the Permanently Retain Backups before Cluster Deletion feature.

    Note By default, log backup is enabled, and you cannot disable this feature.

    Log backups help consistent point-in-time recovery. Based on a full backup set (snapshot) and the redo logs generated after the backup set is created, you can perform point-in-time recovery (PITR) for a PolarDB for MySQL cluster. Log backups can prevent data loss caused by user errors and ensure the security of data that is generated within a period of time. If you perform PITR, you must consider the amount of time that is required to query redo logs. Redo logs are queried at a rate of 1 GB every 20 seconds to 70 seconds. The total restoration duration is the sum of the time required to restore backup sets and the time required to query redo logs.

  • View backup size

    The following figure shows that the total size of log backups is the sum of the size of each log backup file.

    View the total size of log backup files: