ApsaraDB RDS:Restore full data

Usage notes

Billing rules

You are charged for the new RDS instance that is used to restore data. You can view the price of the new RDS instance when you create the instance.

Enable the full data restoration feature

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

Procedure

You can use the backup data of the original RDS instance to create RDS instance for data restoration. This method does not affect the performance of the original RDS instance.

1. Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.

2. In the left-side navigation pane, click Backup and Restoration. On the page that appears, click Restore Database.

   Note

   You can also click Restore Data in the Instance Distribution section of the Basic Information page.

3. On the Restore Instance page, select a point in time to which you want to restore data or select a backup set from which you want to restore data. Then, configure other parameters.

   Parameter	Description
   Billing Method	Subscription: A subscription RDS instance is an instance for which you pay an upfront fee. For long-term use, the subscription billing method is more cost-effective than the pay-as-you-go billing method. You are offered lower prices for longer subscription periods. Pay-As-You-Go: A pay-as-you-go RDS instance is billed per hour based on your actual resource usage. We recommend that you select the pay-as-you-go billing method for short-term use. If you no longer reqiure an pay-as-you-go RDS instance, you can release it to reduce costs.
   Restore Method	By Backup Set: allows you to restore data from a backup set. Logical backup files are not supported. By Time: allows you to restore data to a point in time after the first full backup that is performed within the log backup retention period. For more information about how to view or modify the log backup retention period, see Use the automatic backup feature. Note The By Time option is available only if the log backup feature is enabled.
   Product Type	If you set the Edition parameter to Basic Edition, this parameter is not displayed. If you set the Edition parameter to High-availability Edition, the options for the Product Type parameter vary based on the storage type of your RDS instance. If you set the Storage Type parameter to ESSD, the Standard and Economy product types are available. For more information, see Product types. If you set the Storage Type to Local SSD, only the Standard product type is available. If you set the Edition parameter to Cluster Edition, the Standard and Economy product types are available.
   Zone of Primary Node and Zone of Secondary Node	A zone is an independent physical location within a region. The Zone of Primary Node parameter specifies the zone in which the primary RDS instance resides. The Zone of Secondary Node parameter specifies the zone in which the secondary RDS instance resides. You can select the Single-zone Deployment or Multi-zone Development method. Single-zone Deployment: If you select this deployment method, the values of the Zone of Primary Node and Zone of Secondary Node parameters are the same. Multi-zone Development: If you select this deployment method, the values of the Zone of Primary Node and Zone of Secondary Node parameters are different. We recommend that you select this deployment method to perform zone-disaster recovery. You must manually configure the Zone of Primary Node and Zone of Secondary Node parameters. Note After the RDS instance is created, you can view information about the new RDS instance and its secondary RDS instance on the Service Availability page. If you select RDS Basic Edition, the database system consists of only one primary RDS instance and supports only the single-zone deployment method.
   Instance Type	General-purpose (Entry-level): A general-purpose RDS instance exclusively occupies the memory and I/O resources that are allocated. However, this type of instance shares CPU and storage resources with other general-purpose instances that are deployed on the same host. Dedicated (Enterprise-level): You can select a dedicated instance type or a dedicated host instance type. A dedicated RDS instance exclusively occupies the CPU, memory, storage, and I/O resources that are allocated. The dedicated host instance family is the highest configuration of the dedicated instance family. A dedicated host RDS instance exclusively occupies all the CPU, memory, storage, and I/O resources on the host on which the instance is deployed. Dedicated Cluster: A dedicated cluster exclusively occupies all the resources on a VM or physical host. The permissions to manage the hosts in a dedicated cluster can be granted to you. This allows you to create multiple database instances on a host. For more information, see Create a host. 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.
   Capacity	The storage capacity that is provisioned to store data files, system files, binary log files, and transaction files in the instance. You can adjust the storage capacity at a step size of 5 GB.

4. Click Next: Instance Configuration to configure the network type and resource group of the RDS instance.

   Parameter	Description
   Network Type	Classic Network: the traditional type of network. VPC: the recommended type of network. A virtual private cloud (VPC) is an isolated virtual network that provides higher security and higher performance than the classic network. If you select the VPC network type, you must configure the VPC and VSwitch of Primary Node parameters. If you set the Deployment Method parameter to Multi-zone Deployment in the previous step, you must also configure the VSwitch of Secondary Node parameter. Note The network type of the new RDS instance must be the same as the network type of the Elastic Compute Service (ECS) instance that you want to connect. If the new RDS instance and the ECS instance reside in VPCs, make sure that the instances reside in the same VPC. If the new RDS instance and the ECS instance reside in different VPCs, these instances cannot communicate over an internal network.
   Resource Group	You can use resource groups to categorize the resources of your Alibaba Cloud account. Resource groups help you simplify the management of resources and permissions in your Alibaba Cloud account. You can select an existing resource group or create a resource group. If you do not need to group resources, select Default Resource Group.

5. Click Next: Confirm Order.

6. Confirm the configurations in the Parameters section, configure the Purchase Plan and Duration parameters, read and select Terms of Service, click Pay Now, and then complete the payment. You must configure the Duration parameter only when you select the subscription billing method for the RDS instance.

   Note

   If you select the subscription billing method for the new RDS instance, we recommend that you select Auto-Renew Enabled below the Duration parameter. This way, you do not need to renew the new RDS instance on a regular basis. This also helps prevent interruptions on your workloads on the new RDS instance if a payment becomes overdue.

7. Optional. Log on to the new RDS instance and verify the data. For more information, see Use a database client or the CLI to connect to an ApsaraDB RDS for MySQL instance.

Correct the online data on the new RDS instance

References

• This topic is suitable for full data restoration. For more information about how to restore individual databases and tables, see Restore individual databases and tables of an ApsaraDB RDS for MySQL instance. For more information, see Overview of data restoration methods.

• If you want to restore data to the original RDS instance, an existing RDS instance, or a self-managed instance, you can use the following methods.

  Restoration destination	Restoration method
  Original RDS instance	Method 1: Restore the data of the original RDS instance to a new RDS instance, verify the data on the new RDS instance, and then migrate some or all data of the required databases and tables to the original RDS instance. For more information, see Migrate data between ApsaraDB RDS for MySQL instances. Method 2: Use the restoration feature for individual databases and tables to restore full data to the original RDS instance. For more information, see Restore individual databases and tables of an ApsaraDB RDS for MySQL instance. Method 3: Use Database Backup (DBS) to create a logical backup. Then, restore data to the original RDS instance by using the logical backup file. For more information, see Restore a MySQL database from a logical backup.
  Another existing RDS instance	Method 1: Restore the data of the original RDS instance to a new RDS instance, verify the data on the new RDS instance, and then migrate the data to another existing RDS instance. For more information, see Migrate data between ApsaraDB RDS for MySQL instances. Method 2: Use DBS to create a logical backup. Then, restore data to another existing RDS instance by using the logical backup file. For more information, see Restore a MySQL database from a logical backup.
  Self-managed instance	Method 1: Restore the data of the original RDS instance to a new RDS instance, verify the data on the new RDS instance, and then migrate the data to a self-managed instance. For more information, see Migrate data between ApsaraDB RDS for MySQL instances. Method 2: Use DBS to create a logical backup. Then, restore data to the self-managed database by using the logical backup file. For more information, see Restore a MySQL database from a logical backup. Method 3: Download a backup file. Then, restore data to the self-managed instance from the backup file. For more information, see Restore the data of an ApsaraDB RDS for MySQL instance from a physical backup file to a self-managed MySQL database, Restore the data of an ApsaraDB RDS for MySQL instance from a logical backup file to a self-managed MySQL instance, or Restore the data of an ApsaraDB RDS for MySQL instance to a self-managed MySQL instance by using a CSV file or an SQL file.

• For more information about how to restore the data of an RDS instance that runs a different database engine, see the following topics:

  • Restore the data of an ApsaraDB RDS for SQL Server instance

  • Restore the data of an ApsaraDB RDS for PostgreSQL instance

  • Restore the data of an ApsaraDB RDS for MariaDB instance

FAQ

• How do I restore one or more individual databases that are deleted?

  You can use the restoration feature for individual databases and tables to restore one or more databases and tables. For more information, see Restore individual databases and tables of an ApsaraDB RDS for MySQL instance. If your RDS instance does not support the restoration of individual databases or tables, you can restore the data of the deleted databases or tables to a new RDS instance, verify the data on the new RDS instance, and then migrate the data from the new RDS instance back to your original RDS instance.

• Can I restore the data of my RDS instance to a specific point in time?

  Yes, you can restore the data of your RDS instance to a specific point in time. If the log backup feature is enabled, you can restore the data of your RDS instance to a point in time within the log backup retention period. If the log backup feature is disabled, you can restore the data to the point in time when the data backup was created.

• Can I restore the data of my RDS instance to a specific point in time if no data backup files are available?

  No, you cannot restore the data of your RDS instance to a specific point in time if no data backup files are available. To restore data to a specific point in time, you must find a full data backup that is completed before the specified point in time and restore the data from the full data backup. Then, you must restore the incremental data from the log backup file that is generated at the specified point in time.

• If the backup retention period is set to seven days, can I restore data that is generated seven days ago? Can I use the data tracking feature of DMS to retrieve the data backups that are deleted?

  No, you cannot restore the data that is generated seven days ago. Data backups are retained based on the retention period that is specified. After the retention period elapses, data backups are automatically deleted and cannot be restored. You cannot use the data tracking feature of Data Management (DMS) to retrieve the data backups that are deleted. Data tracking allows you to use binary logs to restore data. However, the data backup retention period is seven days, and you cannot track binary logs that are generated seven days ago. You can modify the backup retention period based on the descriptions in Use the automatic backup feature.

• Why am I charged for database restoration?

  You are charged for the new RDS instance. You can view the price of the new RDS instance when you create the instance.

  Note

  • If you want to temporarily use an RDS instance, you can create a pay-as-you-go RDS instance. After data is restored to the new RDS instance, you can migrate the data to the original RDS instance and then release the new RDS instance. For more information, see Migrate data between ApsaraDB RDS instances and Release or unsubscribe from an ApsaraDB RDS for MySQL instance.

  • You are immediately charged for the new RDS instance after the instance is created.

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

  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 local disks.

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

  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 of full data is approximately 3 hours, which is the sum of the periods of time that are listed in the preceding table.

  • If you want to restore data at a faster speed, you can enable a sandbox instance. The system automatically synchronizes the data that you want to restore to the sandbox instance for you to perform quick restoration. For more information, see Use the emergency recovery feature of an ApsaraDB RDS for MySQL instance.

  Affecting factors: The restoration speed varies based on various factors, and the restoration may fail in some scenarios. You may also need to resolve the errors that occur when SQL statements are executed. The following factors affect the restoration speed:

  • Volume of full data: If the data volume is large, the restoration speed is low.

  • Volume of incremental data: If the data volume is large, the restoration speed is low.

  • Large transactions: If binary log files contain information about large transactions, the restoration speed is low.

  • Hot data updates: If binary log files contain information about hot data updates, the restoration speed is low.

  • Foreign key constraints: Foreign key constraints increase the costs of verification and decrease the restoration speed.

  • Number of binary log records: If you restore data to a specific point in time, a large number of binary log records are required, which decreases the restoration speed.

  • Partitioned tables: If partitioned tables exist, data restoration is not supported. This rule takes effect if you use MySQL 8.0.

  • Storage type: When you use standard SSDs or enhanced SSDs (ESSDs), the restoration speed is higher than the restoration speed when you use local SSDs.

  • Specifications: High specifications indicate a high restoration speed.

  • Database engine version: If the database engine version that you use supports parallel replication, the restoration speed is high. If the database engine version that you use does not support parallel replication, the restoration speed is low.

  Important

  The following factors may cause restoration failures:

  • Binary logs are not parsed as expected because the new RDS instance runs an earlier database engine version than the original RDS instance.

  • Table names or column names contain Chinese characters or special characters.

  • Binary logs in the original RDS instance are deleted.

  • Tables that do not have primary keys cannot be restored because the implicit_primary_key parameter is set to off in the original RDS instance.

• When I create an RDS instance to which I want to restore data, why am I unable to select a vSwitch from the VSwitch of Primary Node drop-down list?

  If no vSwitches are available in the zone that you specified in the Basic Configurations step, you cannot select a vSwitch from the VSwitch of Primary Node drop-down list in the Instance Configuration step. In this case, click the link to go to the VPC console. In the VPC console, create a vSwitch. Then, you can select a vSwitch from the VSwitch of Primary Node drop-down list.