Migrate full backup data of SQL Server 2012, 2014, 2016, 2017, or 2019 databases

Note

You can migrate only one database at a time. If you want to migrate multiple or all the databases at a time, we recommend that you use the instance-level migration solution. For more information, see Migrate data from a self-managed SQL Server instance to an ApsaraDB RDS for SQL Server instance.

Step 1: Perform a full backup for the on-premises database

Preparations

• Make sure that no data is being written to the on-premises database. The data written during the backup process is not backed up.
• Full backup files can be migrated to ApsaraDB MyBase. Differential backup files or log backup files cannot be migrated to ApsaraDB MyBase. For more information about differential backup files, see Differential backup files. When you back up the on-premises database, make sure that the backup file is suffixed with bak.
  Note

  • bak: specifies a full backup file.
  • diff: specifies a differential backup file.
  • trn or log: specifies a log backup file of transactions.
• The names of full backup files cannot contain special characters. For example, do not use forward slashes (/), asterisks (*), ampersands (&), dollar signs ($), percent signs (%), and at signs (@). Otherwise, the migration fails.

1. Download the backup script file.
2. Use SQL Server Management Studio (SSMS) to develop the backup script and configure the following parameters:
   • backup_databases_list: The database to be backed up. If you want to back up multiple databases, separate the names of the databases with semicolons (;) or commas (,).
   • backup_type: The backup type. FULL indicates full backup. DIFF indicates differential backup. LOG indicates log backup.
   • is_run: The operation that is performed for backup. 1: performs a backup. 0: performs no backup but a check.
3. Run the backup script.

Step 2: Upload the backup file to OSS

Step 3: Migrate the backup file to the destination database

1. Log on to the ApsaraDB MyBase console.
2. In the upper-left corner of the page, select the region where you want to create a dedicated cluster.
3. Find the dedicated cluster where the instance is deployed and click Details in the Actions column.
4. In the left-side navigation pane, click Instances. On the page that appears, click the ID of the instance to which the backup file is migrated.
5. On the instance configuration page, click Backup and Restoration in the left-side navigation pane, and then click Migrate OSS Backup Data to RDS.
   
6. In the Import Guide wizard, double-click next step and configure the following parameters.
   

   Parameter	Description
   Database Name	The name of the destination database.
   OSS Bucket	Select the OSS bucket where the backup file is stored.
   OSS Subfolder Name	Enter the name of the subfolder where the backup file is stored.
   OSS File	Select the backup file that you want to migrate to the destination database. You can enter the prefix of the backup file name, and click the search icon to search for the backup file in fuzzy match mode.
   Cloud Migration Method	Select Immediate Access (Full Backup). Note Immediate Access (Full Backup): Select this option if only one full backup file needs to be migrated. Specify the following parameters in CreateMigrateTask: BackupMode = FULL IsOnlineDB = True Access Pending (Incremental Backup): Select this option if you need to migrate full backup files, log backup files, or differential backup files. Specify the following parameters in CreateMigrateTask: BackupMode = UPDF IsOnlineDB = False
   Consistency Check Mode	Synchronization is essential to your workloads. Therefore, we recommend that you select Synchronize DBCC. When the destination database is opened, the system runs the DBCC CHECKDB command. If you enable Synchronize DBCC, the time required to open the database increases. A larger database requires a longer period of time to run the DBCC CHECKDB command. Configure the following setting in CreateMigrateTask: CheckDBMode = SyncExecuteDBCheck. If your business is sensitive to service downtime and synchronization does not affect your business, we recommend that you select Asynchronize DBCC. When the database is opened, the system does not run the DBCC CHECKDB command. After the database is opened, the system runs the DBCC CHECKDB command. If you enable Asynchronize DBCC, the time that is required to open the database is reduced. This way, the service downtime is reduced. Configure the following setting in CreateMigrateTask: CheckDBMode = AsyncExecuteDBCheck.

7. Click OK.