ApsaraDB RDS for SQL Server instances allow you to easily migrate data to the cloud. You need to only upload the full backup data of the source database on your self-managed SQL Server instance to an Object Storage Service (OSS) bucket, and then migrate the full backup data to the destination database on your ApsaraDB RDS for SQL Server instance by using the ApsaraDB RDS console. The backup feature of Microsoft is compatible with ApsaraDB RDS for SQL Server. You can use this feature in scenarios such as data backup, migration, and disaster recovery.
You can perform the operations that are described in this topic only when your RDS instance runs SQL Server 2008 R2 and uses local disks.
For more information about how to migrate the full backup data of a self-managed SQL Server instance to an RDS instance that runs SQL Server 2008 R2 with cloud disks or runs SQL Server 2012 or later, see Migrate the full backup data of a self-managed SQL Server instance to an ApsaraDB RDS instance that runs SQL Server 2008 R2 with cloud disks or runs SQL Server 2012 or later.
Prerequisites
The RDS instance runs SQL Server 2008 R2 with local disks.
NoteThe RDS instances that run SQL Server 2008 R2 with cloud disks are discontinued.
A destination database is created on your RDS instance and has the same name as the source database on your self-managed SQL Server instance. For more information, see Create accounts and databases.
If you use a RAM user, make sure that the following requirements are met:
The AliyunOSSFullAccess and AliyunRDSFullAccess policies are attached to the RAM user. For more information about how to grant permissions to RAM users, see Use RAM to manage OSS permissions and Use RAM to manage ApsaraDB RDS permissions.
The service account of ApsaraDB RDS is authorized by using your Alibaba Cloud account to access the OSS bucket.
A custom policy is manually created by using your Alibaba Cloud account and is attached to the RAM user. For more information about how to create a custom policy, see the Create a custom policy on the JSON tab section in Create custom policies.
You must use the following content for the custom policy:
{ "Version": "1", "Statement": [ { "Action": [ "ram:GetRole" ], "Resource": "acs:ram:*:*:role/AliyunRDSImportRole", "Effect": "Allow" } ] }
Usage notes
The migration method that is described in this topic is at the database level. You can migrate the backup data only of a single self-managed SQL Server instance to your RDS instance at a time. If you want to migrate the backup data of multiple or all databases in a self-managed SQL Server instance at a time, we recommend that you use an instance-level migration method. For more information, see Migrate data from a self-managed SQL Server instance to an ApsaraDB RDS for SQL Server instance.
Billing
If you use the method described in this topic to migrate data, you are charged only for the use of OSS buckets.
Scenario | Billing rule |
Upload backup files to an OSS bucket | Free of charge. |
Store backup files in an OSS bucket | You are charged storage fees. For more information, visit the Pricing page of OSS. |
Migrate backup files from an OSS bucket to your RDS instance |
|
Step 1: Back up the source database on the self-managed instance
Start the Microsoft SQL Server Management Studio (SSMS) client.
Log on to the source database.
Execute the following statements to check the recovery model:
USE master; GO SELECT name, CASE recovery_model WHEN 1 THEN 'FULL' WHEN 2 THEN 'BULK_LOGGED' WHEN 3 THEN 'SIMPLE' END model FROM sys.databases WHERE name NOT IN ('master','tempdb','model','msdb'); GO
If the value of
model
is notFULL
, perform Step 4.If the value of
model
isFULL
, perform Step 5.
Execute the following statements to set the recovery model to
FULL
:ALTER DATABASE [dbname] SET RECOVERY FULL; go ALTER DATABASE [dbname] SET AUTO_CLOSE OFF; go
ImportantAfter the recovery model is set to
FULL
, more logs are generated. Make sure that disk space is sufficient.Execute the following statements to back up the source database. In this example, the dbtest database is backed up to the backup.bak file.
USE master; GO BACKUP DATABASE [dbtest] to disk ='d:\backup\backup.bak' WITH COMPRESSION,INIT; GO
Execute the following statements to check the integrity of the backup file:
USE master GO RESTORE FILELISTONLY FROM DISK = N'D:\backup\backup.bak';
ImportantIf a result set is returned, the backup file is valid.
If an error is returned, the backup file is invalid. In this case, you must back up the source database again.
Optional. Execute the following statement to restore the recovery model of the database:
ImportantIf the recovery model of your database is
FULL
, skip this step.ALTER DATABASE [dbname] SET RECOVERY SIMPLE; GO
Step 2: Upload the backup file of the source database to an OSS bucket
If an OSS bucket is created, check whether the bucket meets the following requirements:
The storage class of the OSS bucket is Standard. The storage class cannot be Standard, Infrequent Access (IA), Archive, Cold Archive, or Deep Cold Archive. For more information, see Overview.
Data encryption is not enabled for the OSS bucket. For more information, see Data encryption.
Create an OSS bucket.
Log on to the OSS console.
In the left-side navigation pane, click Buckets. On the Buckets page, click Create Bucket.
Configure the following parameters. Retain the default values for other parameters.
ImportantThe created OSS bucket is used only for the data migration and is no longer used after the data migration is complete. You need to only configure key parameters. To prevent data leaks and excessive costs, we recommend that you delete the OSS bucket after the data migration is complete at the earliest opportunity.
Do not enable data encryption when you create an OSS bucket. For more information, see Data encryption.
Parameter
Description
Example
Bucket Name
The name of the OSS bucket. The name is globally unique and cannot be modified after it is configured.
Naming conventions:
The name can contain lowercase letters, digits, and hyphens (-).
It must start and end with a lowercase letter or a digit.
The name must be 3 to 63 characters in length.
migratetest
Region
The region of the OSS bucket. If you want to upload data to the OSS bucket from an Elastic Compute Service (ECS) instance over an internal network and then restore the data to the RDS instance over the internal network, make sure that the OSS bucket, ECS instance, and RDS instance reside in the same region.
China (Hangzhou)
Storage Class
The storage class of the bucket. Select Standard. The cloud migration operations described in this topic cannot be performed in buckets of other storage classes.
Standard
Upload backup files to the OSS bucket.
NoteIf the RDS instance and the OSS bucket reside in the same region, they can communicate with each other over an internal network. You can use the internal network to upload the backup data. The method is faster, and no fees are generated for Internet traffic. We recommend that you upload the backup file to an OSS bucket that is in the same region as the destination RDS instance.
After the full backup on the self-managed SQL Server instance is complete, you must use one of the following methods to upload the generated full backup file to the OSS bucket:
Configure the validity period and obtain the URL of the backup file.
Log on to the OSS console.
In the left-side navigation pane, click Buckets. Find the bucket to which you upload the backup file and click its name.
In the left-side navigation pane, choose Object Management > Objects.
Select the backup file.
In the View Details panel, change the value of the Validity Period (Seconds) parameter to 28800, which is equivalent to 8 hours.
ImportantThe URL of the backup file is required when you migrate the file from the OSS bucket to your RDS instance. The data migration fails when the validity period of the URL expires.
Click Copy Object URL.
Modify the data backup file URL that you obtain.
By default, the URL contains the public endpoint of the file. If you migrate data over an internal network, you must replace the public endpoint with the internal endpoint in the URL.
For example, if the URL of the backup file is
http://rdstest.oss-cn-shanghai.aliyuncs.com/testmigraterds_20170906143807_FULL.bak?Expires=15141****&OSSAccessKeyId=TMP****
, you need to replace the public endpointoss-cn-shanghai.aliyuncs.com
in the URL with the internal endpointoss-cn-shanghai-internal.aliyuncs.com
.ImportantThe internal endpoint varies based on the network type and region. For more information, see Regions and endpoints.
Step 3: Restore data to your RDS instance by using the backup file in the OSS bucket
- 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.
In the left-side navigation pane, click Databases.
Find the destination database and click Migrate Backup Files from OSS in the Actions column.
In the Import Guide wizard, read the on-screen instructions and click Next.
Read the on-screen instructions and click Next.
Enter the URL of the backup file in the OSS URL of the Backup File field and click OK.
NoteRDS instances that run SQL Server 2008 R2 with local disks support only one-time migration of full backup files.
Step 4: View the status of the migration task
In the left-side navigation pane, click Database Migration to Cloud. Then, find the migration task in the migration task list.
If Task Status is Failed, you can click Task Description or View File Details in the Actions column to view the cause. Fix the problem and repeat the preceding migration procedure again.
Related operations
Operation | Description |
Creates a data migration task. | |
Opens the database to which backup data is migrated on an ApsaraDB RDS for SQL Server instance. | |
Queries the tasks that are created to migrate the backup data of an ApsaraDB RDS for SQL Server instance. | |
Queries the backup file details of a backup data migration task for an ApsaraDB RDS for SQL Server instance. |