This topic describes how to migrate full backup data from an SQL Server database to ApsaraDB for MyBase by using backup sets.

Prerequisites

  • The self-managed SQL Server database runs one of the following versions:
    • SQL Server 2017 Enterprise Edition.
    • SQL Server 2012 Standard Edition, 2012 Enterprise Edition, 2014 Standard Edition, 2016 Standard Edition, 2016 Enterprise Edition, 2017 Standard Edition, and 2019 Standard Edition.
    • SQL Server 2012 Enterprise Edition, Basic Edition, 2012 Web Edition, and 2016 Web Edition.
  • The storage capacity of ApsaraDB for MyBase is sufficient. If the storage capacity of the destination cluster is insufficient, expand the storage capacity of the cluster before the migration. For more information, see Modify the configuration of an instance.
  • An Object Storage Service (OSS) bucket is created. Make sure that the OSS bucket and the SQL Server instance in the ApsaraDB for MyBase cluster are deployed in the same region. For more information about how to create an OSS bucket, see Create buckets.

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 for MyBase. Differential backup files or log backup files cannot be migrated to ApsaraDB for 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

Preparations
You can upload the full backup file to OSS by using one of the following three methods:
  • Method 1 (recommended): Upload the file by using the ossbrowser tool
    1. Download, install, and then log on to ossbrowser.
    2. Create and manage buckets and directories.
    3. Upload the file to the specified bucket or directory.
      Note For more information about how to upload the file to the specified bucket or directory, see Upload backup files by using the ossbrowser tool.
  • Method 2: Upload the file in the OSS console

    If the backup file is smaller than 5 GB, you can upload the backup file in the OSS console. For more information, see Upload files to OSS.

  • Method 3: Upload the file by calling OSS API operations

    You can implement multipart upload and resumable upload for the backup file by calling OSS API operations. For more information, see Upload backup files by calling OSS API operations.

Note Before the migration is complete, do not delete backup files from the OSS bucket. If you delete the backup files before the migration is complete, the migration fails.

Step 3: Migrate the backup file to the destination database

  1. Log on to the ApsaraDB for MyBase console.
  2. In the top navigation bar, select the deployment region.
    Select a region
  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.
    s
  6. In the Import Guide wizard, double-click next step and configure the following parameters.
    a
    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.

What to do next

  1. Click Refresh to view the latest status of the data migration task.
  2. On the Backup and Restoration page, click the Backup Data Upload History tab to view the details about the migration task. By default, the details page displays the records of the previous week.