Restore full data to a new RDS for MySQL instance - ApsaraDB RDS

Restore an ApsaraDB RDS for MySQL instance to a new RDS instance using data backup files and log backup files. Use this approach to analyze historical data or recover from unintended operations without affecting your production instance.

Prerequisites

Before you begin, ensure that:

The original RDS instance is in the Running state and is not locked
No migration tasks are in progress on the original RDS instance
At least one data backup has completed (ApsaraDB RDS performs automatic backups by default — see Overview of backup methods)
(Required for point-in-time restore) Log backup is enabled — see Use the log backup feature for an ApsaraDB RDS for MySQL instance
(Required for restore from backup set) At least one physical backup has completed — see Automatic backup

How it works

Full data restoration creates a new RDS instance from your backup data. The original instance is unaffected throughout the process.

Item	Description
Restoration range	The entire RDS instance is restored.
Specifications of the new RDS instance	Inherits the whitelist configurations, backup configurations, and parameter configurations of the original instance.
Account information	Includes account information at the point of restoration, plus account information from the selected backup file.
Data	Matches the data in the specified backup file of the original RDS instance.
Restore point	Depends on which backup features are enabled: log backup disabled — restore only to the backup creation time; log backup enabled — restore to any point within the log backup retention period; point-in-time recovery (PITR) enabled — restore to any point based on the Time Range of Specific Points in Time for Restoration parameter. For differences between PITR and log backup, see Differences between the PITR and log backup features.

Limitations

You cannot restore downloaded backup files directly to an existing RDS for MySQL instance. Restore to a new instance first, verify the data, and then migrate data to the existing instance.
Restoration may fail if the new RDS instance runs an earlier database engine version than the original instance.
Restoration may fail if table names or column names contain Chinese characters or special characters.
Restoration may fail if binary logs on the original RDS instance have been deleted.
Tables without primary keys cannot be restored if implicit_primary_key is set to off on the original RDS instance.

Billing

You are charged for the new RDS instance from the moment it is created. Check the price when configuring the instance before confirming the order.

For temporary use, create a pay-as-you-go or serverless RDS instance. After verifying and migrating the data back to the original instance, release the new instance to stop charges. See Migrate data between ApsaraDB RDS instances and Release or unsubscribe from an ApsaraDB RDS for MySQL instance.

Restore a full instance

You do not need to manually enable the full data restoration feature. After an RDS instance is created, the system automatically performs periodic backups. You can use the generated data backup files and log backup files to restore full data at any time.

Go to the Instances page. In the top navigation bar, select the region where the RDS instance resides. Find the instance and click its ID.
In the left-side navigation pane, click Backup and Restoration.
Click Restore Database.
Note
Alternatively, click Restore Instance in the Instance Distribution section of the Basic Information page.

On the Restore Instance page, select a restore point or backup set, then configure the instance parameters.

Parameter	Description
Billing Method	Subscription: Pay upfront for long-term use at lower per-unit cost. Pay-as-you-go: Billed per hour based on actual usage; release the instance when no longer needed.
Restoration Mode	By Backup Set: Restore from a specific physical backup. Logical backup files are not supported. By Point in Time: Restore to any point within the log backup retention period. Available only when log backup is enabled.
Product Type	Not displayed for Basic Edition. For High-availability Edition: ESSD or Premium ESSD storage supports Standard and YiTian product types; Premium Local SSD storage supports Standard only. For Cluster Edition: Standard and YiTian product types are available. See Product types.
Zone of primary node and Zone of secondary node	Single-zone deployment: Primary and secondary nodes are in the same zone. Multi-zone deployment: Primary and secondary nodes are in different zones for zone-disaster recovery. Multi-zone deployment is recommended. After creation, view zone details on the Service Availability page. Basic Edition supports single-zone deployment only.
Instance Type	General-purpose instance types: Dedicated memory and I/O; shared CPU and storage with other instances on the same host. Dedicated instance types: Dedicated CPU, memory, storage, and I/O. The dedicated host configuration exclusively occupies all resources on the host. For supported cores, memory, connections, and IOPS per instance type, see Primary ApsaraDB RDS instance types. Note Each instance type supports a specific number of cores, memory capacity, maximum number of connections, and maximum IOPS. For more information, see Primary ApsaraDB RDS instance types.
Storage Capacity	Maximum storage for data files, system files, binary log files, and transaction files. Adjustable in 5 GB increments.

Click Next: Instance Configuration and configure the network settings.

Parameter	Description
Network Type	Classic network: Traditional network type. VPC: Recommended. A virtual private cloud (VPC) provides higher security and performance. When selecting VPC, configure the VPC and vSwitch of Primary Node parameters. For multi-zone deployment, also configure vSwitch of Secondary Node. The new RDS instance and your Elastic Compute Service (ECS) instance must be in the same network type — and the same VPC if both use VPC — to communicate over an internal network.
Resource Group	Assign the instance to a resource group for simplified management of resources and permissions. Select an existing group or create one. If grouping is not needed, select Default Resource Group.

Parameter

Description

Network Type

Classic network: Traditional network type. VPC: Recommended. A virtual private cloud (VPC) provides higher security and performance. When selecting VPC, configure the VPC and vSwitch of Primary Node parameters. For multi-zone deployment, also configure vSwitch of Secondary Node. The new RDS instance and your Elastic Compute Service (ECS) instance must be in the same network type — and the same VPC if both use VPC — to communicate over an internal network.

Resource Group

Assign the instance to a resource group for simplified management of resources and permissions. Select an existing group or create one. If grouping is not needed, select Default Resource Group.

Click Next: Confirm Order.
Review the Parameter Configuration section, set Quantity and Subscription Duration (subscription billing only), click Confirm Order, and complete payment.
Note
For subscription instances, enable Auto-renew to avoid manual renewals and service interruptions from overdue payments.
(Optional) Log in to the new RDS instance and verify the data.

Migrate restored data back to the original instance

After verifying the data on the new RDS instance, use Data Transmission Service (DTS) to migrate some or all databases and tables back to the original instance.

Set the new RDS instance as the source database and the original RDS instance as the destination database. Set Access Method to Alibaba Cloud Instance for both. See Migrate data between ApsaraDB RDS for MySQL instances.

Depending on your goal, choose the right approach after restoration:

Replace the original instance's data: Migrate all data from the new instance to the original instance.
Recover specific data: Write and run a migration task that extracts only the affected databases or tables and applies them to the original instance.

Restoration methods by destination

Destination	Available methods
Original RDS instance	Method 1: Restore to a new instance, verify, then migrate selected data back to the original instance. Method 2: Use the database and table restore feature to restore directly. Method 3: Use Database Backup (DBS) to create a logical backup, then restore using the logical backup file — see Restore a MySQL database from a logical backup.
Another existing RDS instance	Method 1: Restore to a new instance, verify, then migrate the data to the target instance. Method 2: Use DBS to create a logical backup and restore — see Restore a MySQL database from a logical backup.
Self-managed database	Method 1: Restore to a new instance, verify, then migrate the data. Method 2: Use DBS to create a logical backup and restore — see Restore a MySQL database from a logical backup. Method 3: Download a backup file and restore from it — see Restore from a physical backup, Restore from a logical backup, or Restore using snapshot backup files.

For restoration guidance for other database engines, see Restore SQL Server data, Restore the data of an ApsaraDB RDS for PostgreSQL instance, and Restore the data of an ApsaraDB RDS for MariaDB instance.

FAQ

How do I restore individual databases that were deleted?

Use the database and table restore feature to restore specific databases and tables. If your instance doesn't support this feature, restore the deleted databases to a new RDS instance, verify the data, and migrate it back to the original instance.

Can I restore data to a specific point in time?

Yes, if log backup is enabled. You can restore to any point within the log backup retention period. If log backup is disabled, you can only restore to the time when the data backup was created. To check the log backup retention period, see Use the log backup feature.

Can I restore to a point in time if no data backup files exist?

No. Point-in-time recovery requires a full data backup completed before the target time, plus the binary logs from that backup to the target time. Without a full backup, neither can be applied.

If the backup retention period is seven days, can I restore data from seven days ago?

No. Once the retention period expires, backups are deleted automatically and cannot be recovered.

Can I use the data tracking feature of Data Management (DMS) to retrieve deleted backups?

No. Data tracking uses binary logs, which are also subject to the backup retention period. Binary logs older than the retention period are unavailable. To extend how far back you can recover, increase the backup retention period — see Automatic backup.

Why am I charged for data restoration?

Charges apply to the new RDS instance created during restoration, not to the restore operation itself. The instance is billed from the moment it is created. See the Billing section above for options to minimize cost.

How long does it require to restore data to a new RDS instance?

The period of time that is required to restore data to a new RDS instance depends on the data volume and network conditions. In most cases, several minutes to several hours are required for the data restoration.

The time required varies based on data volume, instance specifications, storage type, and binary log complexity. As a reference, restoring 200 GB of data on a 2-core, 4 GB memory High-availability Edition instance with Premium Local SSDs takes approximately 3 hours (with binary log application time of 30 minutes).

Example of the period of time required for data restoration

The following table lists the periods of time that are required to restore data to a new RDS instance that provides 2 cores and 4 GB of memory and runs RDS High-availability Edition with Premium Local SSDs.

Operation	Time required
Create an RDS instance	5 minutes
Configure an RDS instance	15 minutes
Download a backup file	200 GB-hour
Start an RDS instance	5 minutes
Download a binary log file	200 GB-hour
Apply a binary log file	Based on content

Note

For example, if you want to restore 200 GB of data and the period of time that is required to apply the binary log files is 30 minutes, the period of time that is required to complete the restoration is approximately 3 hours. This applies if the backup data and binary logs are serially downloaded.
If you want to restore data at a faster speed, you can enable a sandbox instance. The system automatically synchronizes the data to the sandbox instance for you to perform quick restoration. For more information, see Use the emergency recovery feature.

Factors

The restoration speed varies based on a number of factors, and the restoration may fail in a few circumstances. You may also need to manually troubleshoot the errors that occur due to the executions of SQL statements. The following factors affect the restoration speed:

Data volume: Larger backup data slows restoration.
Large transactions: Binary logs containing large transactions reduce speed.
Hot data updates: Binary logs with high-frequency updates reduce speed.
Foreign key constraints: Verification overhead reduces speed.
Binary log volume: More binary log records for point-in-time recovery reduces speed.
Storage type: Cloud disks restore faster than Premium Local SSDs.
Instance specifications: Higher specifications improve speed.
Database engine version: Versions that support parallel replication restore faster.

Important

The following factors may cause restoration failures:

Why can't I select a vSwitch from the vSwitch of Primary Node drop-down list?

No vSwitches exist in the zone selected in the previous step. Click the link in the drop-down list to go to the VPC console, create a vSwitch in the required zone, and then return to select it.

What's next

To restore individual databases or tables instead of the entire instance, see Restore individual databases and tables of an ApsaraDB RDS for MySQL instance.
For an overview of all restoration options, see Overview of data restoration methods.