All Products
Search
Document Center

ApsaraDB RDS:Restore SQL Server data

Last Updated:Jul 23, 2025

If you have backup data for an RDS SQL Server instance, you can restore the backup data to an existing instance or a new instance. This can be used for scenarios such as recovery after misoperations and historical data analysis.

Note

This topic applies to restoring all data to an instance in the same region. To restore data across regions or restore RDS backup files to a self-managed database, see the Restoration solution overview tutorial to choose an appropriate restoration solution.

Limits

  • If the instance has enabled the data archiving to OSS feature, only databases that exist in the backup set (non-archived databases) are supported for restoration. If a database is archived, the restored instance will not include the archived database.

  • Backup data from Serverless instances can only be restored to new Serverless instances and cannot be restored to existing instances.

  • RDS SQL Server 2008 R2 (premium performance local disk) instances are not supported. Data from these instances should be restored through a temporary instance.

  • After TDE is enabled, the backup data generated by the instance can be used to restore to a new instance, but restoring the backup data to an existing instance is not supported.

Restore to an existing instance

You can restore historical backups from Instance A to a specified existing instance (including Instance A) by point in time or backup set. The restoration scope supports selecting some or all databases.

Restoration rules

Instance requirements

Description

Database version

The database version of the existing instance must be greater than or equal to the database version of the original instance.

Instance series

Restoration from a higher series to a lower series is not supported. The series from high to low are: Cluster Edition > High-availability > Basic.

Instance type

Only same type to same type, General-purpose to Dedicated, and Dedicated to General-purpose are supported.

Procedure

  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 navigation pane on the left, click Backup and Restoration, and click Database Restoration.

  3. In the dialog box that appears, select Restore To Existing Instance and click OK.

  4. Set the following parameters and click OK.

    Parameter

    Description

    Restoration Method

    • By Backup Set: You can restore the data in the selected backup set.

    • By Time: You can set any point in time within the log backup retention period. The system will restore data to the specified point in time based on the most recent full backup and incremental backups (restoration of a specific incremental backup is not supported). You can view or modify the log backup retention period as needed.

    Restoration Time

    This parameter is visible when Restoration Method is set to By Time. Select the point in time for the data you want to copy.

    Backup Set

    This parameter is visible when Restoration Method is set to By Backup Set. Select the backup set you want to restore.

    More Backup Sets

    If you cannot find the target backup set in Backup Set, you can select this option to continue searching.

    Target Instance Name

    Select the instance to which you want to restore data. You can restore data to an instance with a higher version. The system displays all instances in the current region under the current Alibaba Cloud account by default, including the current instance.

    Note
    • Snapshot backups can only be restored to instances that have snapshot backup enabled.

    • Backups from shared instances cannot be restored to General-purpose or Dedicated instances, and backups from General-purpose or Dedicated instances cannot be restored to shared instances.

    • If there are too many target instances displayed, you can use the search box to filter them.

    Databases To Restore

    1. Select the databases you want to restore. You can restore some or all databases. The system displays all databases in the instance by default.

    2. Set the database name after restoration. The system uses the original database name by default. Note the following:

      • The database name after restoration cannot be the same as an existing database name in the target instance. Otherwise, the restoration task will report an error. Please modify it to a unique database name.

      • When the database name after restoration is different from an existing database name in the target instance, the system will create a new database without overwriting or affecting the existing data in the target instance.

      • The database name after restoration can only contain uppercase and lowercase letters, numbers, underscores (_), and hyphens (-).

  5. View the progress of the restoration task.

    The system will generate a restoration task. You can click the image.png button in the upper-right corner and filter Task List page by Task Type as Clone Instance to view the restoration progress.

    image.png

Restore to a new instance

You can restore historical backups from Instance A to a new instance by point in time or backup set. The restoration scope supports selecting some or all databases. For the time required to restore to a new instance, see FAQ in this topic.

Billing information

Because the data is restored to a new instance, fees for the new instance will be charged. You can view the fee details when creating the instance.

Note

Procedure

  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 navigation pane on the left, click Backup and Restoration, and click Database Restoration.

  3. In the Select Restoration Method dialog box, select Restore To New Instance and click OK.

  4. On the Database Restoration page, set the following parameters.

    Category

    Description

    Billing method

    • Subscription: This is a prepaid billing method that requires payment when you create an instance. It is suitable for long-term requirements and is more cost-effective than the pay-as-you-go billing method. The longer the subscription period, the higher the discount.

    • Pay-as-you-go: This is a postpaid billing method that charges you by hour. It is suitable for short-term requirements. You can release the instance immediately after use to reduce costs.

    Restoration Method

    • By Backup Set: You can restore the data in the selected backup set.

    • By Time: You can set any point in time within the log backup retention period. The system will restore data to the specified point in time based on the most recent full backup and incremental backups (restoration of a specific incremental backup is not supported). You can view or modify the log backup retention period as needed.

    Database

    You can restore all or some databases. If you select Partial, you need to manually enter the database names, separated by commas (,).

    Note

    If the instance has enabled snapshot backup, only All databases can be restored, and Partial database restoration is not supported.

    Edition

    Different regions and database versions support different editions. Please refer to the actual interface.

    Storage Type

    Select enterprise SSD (ESSD) or premium performance disk. For more information, see Storage type introduction.

    Primary Node Zone

    Select the zone where the primary node of the instance is located.

    Note

    The Basic Edition includes only one node, so there is only one zone.

    Deployment Method

    • Multi-zone Deployment (recommended): The primary node and secondary node are located in different zones within the same region, providing cross-zone disaster recovery.

    • Single-zone Deployment: The primary node and secondary node are located in the same zone.

    Note
    • There is no substantial difference between different zones in the same region.

    • The performance of ECS accessing RDS in the same zone is better than accessing RDS in other zones of the same region, but the difference is small.

    • When you select Basic Edition, only Single-zone Deployment is supported.

    • If the upper-right corner of the target zone displays Sold Out, please change to another zone.

    • This parameter is not supported for the Basic Edition.

    Secondary Node Zone

    If Deployment Method is set to Multi-zone Deployment, you need to select the zone where the secondary node of the instance is located.

    Note

    The Basic Edition includes only one node, so there is no secondary node zone.

    Instance Type

    Different regions and database versions support different instance types. Please refer to the actual interface.

    Storage Capacity

    The storage capacity of the new instance must be greater than or equal to that of the original instance.

    • You can view the storage capacity of the original instance on the Basic Information page of the RDS instance details page.

    • The storage capacity includes data space, system file space, log file space, and transaction file space.

  5. Click Next: Instance Configuration and set the following parameters.

    Category

    Description

    Network Type

    Currently, only virtual private cloud (VPC) is supported. You can create a VPC and vSwitch as needed.

    Note

    Make sure that the RDS instance and the ECS instance you want to connect are in the same VPC. Otherwise, the RDS instance and the ECS instance cannot communicate through the internal network.

    Resource Group

    The resource group to which the instance belongs. You can create a resource group as needed.

  6. Click Next: Confirm Order.

  7. Confirm the Parameter Configuration, select Quantity and Duration (for subscription instances only), click Confirm Order, and complete the payment.

    You can go to the instance list and find the newly created instance based on the creation time. Creating an instance takes about 1 to 10 minutes. Please refresh the page to check.

  8. You can connect to the new SQL Server instance and check the restored databases and tables.

Related operations

You can also restore data using the API (RecoveryDBInstance).

FAQ

How long does it take to restore data to a new instance?

Estimated time

Typically, the estimated time range for restoring data to a new instance is as follows. Note that the backup and restoration speeds below are based on uncompressed data size.

Note

Because the Web version of the instance does not support backup compression, backup efficiency will be affected, and backup and restoration speeds may be reduced to below 100 GB/hour.

Operation

Required

Estimated time

Notes

Create and configure a new instance

Required

10-15 minutes

The time required depends on the edition and instance type selected when restoring to a new instance.

Perform a full backup of the instance

Not required

200 GB/hour

  • Because the recovery speed of transaction logs is much lower than the data recovery speed of full backups, to ensure the best efficiency of data recovery, if the instance has not performed a full backup within 36 hours, the instance will perform a full backup during the upgrade process to find a balance between speeding up recovery and adding an extra full backup.

    It is recommended to manually perform a full backup at an appropriate time before restoration, or initiate the restoration task within 36 hours after the system automatic full backup is completed, to reduce the total time required for the restoration process.

  • Backup speed may vary depending on the region and time period.

  • For more accurate backup and recovery performance, refer to the data volume and backup time of the most recent full backup.

Restore full backup to the target instance

Required

200 GB/hour

None

Perform incremental transaction log backup on the source instance

Required

200 GB/hour

There may be an additional 2-minute overhead before and after the incremental log backup (such as backup preparation, completion, resource allocation, etc.).

Apply incremental transaction log backup to the target instance

Required

200 GB/hour

There may be an additional 2-minute overhead before and after applying the incremental log backup (such as backup consistency verification, etc.).

Bring the database online

Required

Normally within 2 minutes

  • Resource consumption: Applying incremental transaction logs is a resource-intensive operation. Small instance types (such as 2 cores, 4 GB) may experience reduced recovery speed due to many transaction logs.

  • Database recovery acceleration option: RDS SQL Server 2019 and higher versions provide an Accelerated Database Recovery option, which may reduce the time required for the database recovery online step. Please refer to the Microsoft official documentation to comprehensively evaluate whether to enable this option.

Estimation example

Test instance: Instance type is 4 cores 8 GB, data size is 600 GB.

  • Create and configure a new instance: Estimated time is 12 minutes.

  • Full backup (not required): Estimated time is 3 hours. (600 GB / 200 GB per hour)

  • Restore full backup to the target instance: Estimated time is 3 hours. (600 GB / 200 GB per hour)

  • Perform incremental transaction log backup on the source instance: Estimated time is 5 minutes. (10 GB / 200 GB per hour) + 2 minutes additional overhead = 5 minutes

  • Apply incremental transaction log backup to the target instance: Estimated time is 5 minutes. (10 GB / 200 GB per hour) + 2 minutes additional overhead = 5 minutes

  • Bring the database online: Estimated time is within 2 minutes.

In summary, in this example, if the instance has not performed a full backup within 36 hours, the total estimated time is about 6 hours and 24 minutes. Otherwise, it takes about 3 hours and 24 minutes.

Restoration recommendations

  • Maintenance window planning: It is recommended to perform restoration operations during periods of low system load to minimize the impact on business.

  • Long-running transaction issues: During the restoration process, avoid executing long-running transaction operations, such as creating or rebuilding indexes, data archiving, etc., to avoid extending the time of the database recovery online step.