Relational Database ServiceRelational Database Service

Elastic Cloud Server
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
Domain Name Service
VPC Endpoint
Cloud Connect
Enterprise Switch
Security & Compliance
Web Application Firewall
Host Security Service
Data Encryption Workshop
Database Security Service
Advanced Anti-DDoS
Data Security Center
Container Guard Service
Situation Awareness
Managed Threat Detection
Cloud Certificate Manager
Anti-DDoS Service
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GaussDB(for MySQL)
Distributed Database Middleware
GaussDB(for openGauss)
Developer Services
Distributed Cache Service
Simple Message Notification
Application Performance Management
Application Operations Management
API Gateway
Cloud Performance Test Service
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
Cloud Communications
Message & SMS
Cloud Ecosystem
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP License Service
Support Plans
Customer Operation Capabilities
Partner Support Plans
Professional Services
Intelligent EdgeFabric
SDK Developer Guide
API Request Signing Guide
Koo Command Line Interface
Help Center> Relational Database Service> User Guide> Working with RDS for PostgreSQL> Backups and Restorations> Restoring from Incremental Backup Files to a Self-Built PostgreSQL Database
Updated at: Apr 02, 2022 GMT+08:00

Restoring from Incremental Backup Files to a Self-Built PostgreSQL Database

After RDS for PostgreSQL databases are backed up, you can download backup files by referring to Downloading a Full Backup File and Downloading an Incremental Backup File and restore data from them. This topic uses the Unix OS as an example to describe how to restore from incremental backup files to a self-built database.


  • A full backup has been completed for your databases.
  • You have downloaded the tool for decompressing incremental backup files by clicking here.
  • The version of the local database must be the same as that of the cloud database.
  • Plugins of the same version as the cloud database are installed in the local database.
  • You have done the following preparations for decompressing TAR files:
    • A tool for decompressing TAR files has been installed.
    • Either python2.7 or python3 is supported.
    • lz4, gzip, and shutil have been installed.


  1. Choose a local directory for storing the tablespaces. You can use an existing directory or use mkdir to create a new one.
  2. Stop the local database server.

    For details about how to stop a PostgreSQL database, see the official documentation.

  3. Store the following configuration files in the data directory of the local database to another directory: postgresql.conf, pg_hba.conf, and recovery.done.

    The recovery.done file does not exist in PostgreSQL 12 or later.

  4. Clear the data directory of the local database.

    rm -rf directory

  5. Run the following command to decompress backup data to the directory prepared in 1:

    tar -zxf src_file -C target_dir

    Variables in the command are described as follows:

    src_file: the directory where PostgreSQL full backup files are stored.

    target_dir: the directory data is restored to. It was prepared in 1. The directory must be empty. If the directory does not exist, the system automatically creates one.

    The following directories are generated after the decompression:

    • base: stores full files.
    • pg_wal (or pg_xlog for PostgreSQL version 9.x): stores incremental files.
    • A number of tablespace directories named using digits if the original backup contains tablespace files.

  6. Copy the files in 5 to a specified directory of the local database.

    1. Copy all the decompressed files in the base directory to the data directory of the local database, and then replace the three files in the data directory of the local database with the configuration files in 3.
    2. Copy the files in the decompressed pg_wal directory to the pg_wal directory under the data directory of the local database.

      For PostgreSQL 9.x, the decompressed directory is pg_xlog.

    3. If the original backup contains tablespace files, modify the corresponding tablespace soft links in data/tablespace_map.

  7. Restore data to a specified point in time.

    1. Store the downloaded incremental backup file to the same directory as the full backup file.
    2. Run the following command to decompress the incremental backup file to a temporary directory (for example, /tmp/wal) using the provided script:

      python src_file_dir target_dir

      Variables in the command are described as follows:

      • src_file_dir: indicates the directory for storing PostgreSQL incremental backup files.
      • target_dir: indicates the temporary directory for storing pg_wal logs.
    3. Perform the following operations in sequence to modify the postgresql.conf file (recovery.done or recovery.conf for PostgreSQL 11 or earlier) stored in 3:
      1. Change #recovery_target_time='' to recovery_target_time = '20YY-MM-DD HH:MM:SS', for example, recovery_target_time = '2020-12-22 20:00:00'. (To restore the latest backup data, set the time to the current time.)
      2. Change the value of restore_command to cp /tmp/wal/%f %p. /tmp/wal is the temporary directory for storing pg_wal logs.
      3. Change the value of recovery_target_action to promote or add recovery_target_action = 'promote'.
      4. Change the value of hot_standby to off.
    4. Configure the standby mode.
      • For PostgreSQL 11 and earlier versions, change the value of standby_mode to on in the postgresql.conf file.
      • For PostgreSQL 12 and later versions, create a standby.signal file in the data directory of the local database.

  8. Restart the database and wait until the restoration is complete.

    If the database can be connected after the restart, the restoration was successful.

    After the restoration completes, comment out recovery_target_time and recovery_target_action by adding # in front of the parameters.

Did you find this page helpful?

Failed to submit the feedback. Please try again later.

Which of the following issues have you encountered?

Please complete at least one feedback item.

Content most length 200 character

Content is empty.

OK Cancel