Restore backup data to a new RDS instance to recover from unintended operations or to analyze historical data. After restoring, verify the data on the new instance, then migrate it back to the original instance.
How it works
The restoration process consists of three steps:
Restore the backup data to a new RDS instance — by backup set or by point in time.
Log in to the new instance and verify the restored data.
Migrate the verified data from the new instance back to the original instance.
For a full comparison of data restoration methods, see Overview of data restoration methods.
Prerequisites
Before you begin, make sure that:
The original instance is in the Running state
No migration tasks are running on the original instance
At least one complete backup set exists (required for restoring by backup set)
Log backup is enabled on the original instance (required for restoring by point in time) — see Back up an ApsaraDB RDS for PostgreSQL instance to configure automatic backups
Basic Edition instances do not support log backup, so point-in-time restore is unavailable for these instances.
Usage notes
The new instance inherits the same backup and parameter settings as the original instance.
The data and account information on the new instance reflects the state captured in the specified backup set or log backup file.
If the original instance uses cloud disks, the new instance does not inherit the whitelist and security group configurations. Reconfigure these after the restore completes.
Billing
A new RDS instance is created during the restore process, and you are charged for it immediately upon creation. The price is shown during the instance creation flow.
To minimize costs for a temporary restore:
Select Pay-as-you-go or create a serverless instance.
After migrating the data back to the original instance, release the new instance.
For more information, see Migrate data between ApsaraDB RDS instances and Release or unsubscribe from an ApsaraDB RDS for PostgreSQL instance.
Restore data to a new instance
Go to the Instances page. In the top navigation bar, select the region where the instance resides. Find the instance and click its ID.
In the left-side navigation pane, click Backup and Restoration.
In the upper-left corner, click Restore Database.
Configure the basic resource parameters.
Parameter Description Billing Method Subscription: Billed upfront. More cost-effective for long-term use. Pay-as-you-go: Billed per hour based on actual usage. Better for short-term use. NoteIf the original instance uses serverless billing, you can only restore to a new serverless instance.
Restoration Mode By Point in Time: Restores to any point within the log backup retention period. To check or change the log backup retention period, see Back up an ApsaraDB RDS for PostgreSQL instance. By Backup Set: Restores from a specific backup set. NoteBy Point in Time is only available if log backup is enabled.
Edition Basic Edition: Single-instance architecture with compute-storage separation. High-availability Edition: One primary and one secondary instance. Cluster Edition: One primary and multiple secondary nodes. Available editions vary by region and database engine version. See Overview. Deployment Method Single-zone Deployment: Primary and secondary instances are in the same zone. Multi-zone Development: Primary and secondary instances are in different zones, providing zone-disaster recovery. Configure Zone of Primary Node and Zone of Secondary Node accordingly. NoteBasic Edition supports single-zone deployment only. After creation, view zone details on the Service Availability page.
Instance Type General-purpose instance types: The instance exclusively occupies its allocated memory and I/O but shares CPU and storage with other instances on the same server. Dedicated instance types: The instance exclusively occupies its allocated CPU, memory, storage, and I/O. Dedicated host types provide the highest specifications, occupying all resources on the physical host. For supported cores, memory, connections, and IOPS per type, see Primary ApsaraDB RDS instance types. Storage Capacity Storage for data files, system files, log files, and transaction files. Adjust in 5 GB increments. NoteFor dedicated instances using Premium Local SSDs, storage capacity is fixed per instance type. See Primary ApsaraDB RDS instance types.
Click Next: Instance Configuration and configure the network parameters.
Parameter Description Network Type Select VPC. A virtual private cloud (VPC) provides an isolated network with higher security and better performance. After selecting VPC, configure VPC and vSwitch of Primary Node. If you selected Multi-zone Development, also configure vSwitch of Secondary Node. Make sure the RDS instance and the ECS instance you want to connect to are in the same VPC; instances in different networks cannot communicate over an internal network. Resource Group The resource group the instance belongs to. Click Next: Confirm Order.
Review the settings in the Parameter Configuration section. Set Quantity and (if using subscription billing) Subscription Duration. Accept the Terms of Service, click Pay Now, and complete payment.
Log in and verify the data
After the new instance is available, log in and verify that the restored data is correct. See Connect to an ApsaraDB RDS for PostgreSQL instance for connection instructions.
Migrate data to the original instance
After verifying the data, migrate it from the new instance back to the original instance using Data Transmission Service (DTS). Migration replicates data without interrupting workloads on the source instance. See Migrate data between RDS instances.
What's next
To restore specific databases or tables rather than the full instance, see Restore individual databases and tables.
To restore a small amount of data quickly using a logical backup file, see Use pg_restore to restore data from a logical backup file.
To restore data to a self-managed PostgreSQL instance, see Restore data to a self-managed PostgreSQL instance by using a CSV file or an SQL file.