All Products
Search

This Product

    ApsaraDB RDS:Replicate databases between instances

    Document Center

    ApsaraDB RDS:Replicate databases between instances

    Last Updated:Mar 30, 2026

    Use inter-instance database replication to copy one or more databases, accounts, and account permissions from a source RDS instance to a destination RDS instance.

    Initiate replication from the console or by calling the CopyDatabaseBetweenInstances API operation.

    How it works

    Replication proceeds in two stages:

    1. ApsaraDB RDS takes a full backup of the source instance.

    2. The full backup data is restored to the destination instance.

    Data written to the source instance during replication is not carried over to the destination. If the replication task fails at any point, no data is written to the destination instance, preserving data consistency.

    Limitations

    • The source and destination instances must belong to the same Alibaba Cloud account.

    • The region and network type of the two instances must match. Zones can differ.

    • The destination instance must not have any databases whose names match those you want to replicate.

    • Only one-time full replication is supported. Incremental synchronization after the initial replication is not supported.

    • SQL Server Web instances do not support backup compression, which can reduce backup and restore throughput to below 100 GB per hour.

    Database replication vs. DTS data migration

    Database replication Data Transmission Service (DTS) data migration
    Principle Replicates databases using data backup files or to a point in time. Does not delete source data. Performs logical migration by reading and parsing logs of the source instance. A complete migration consists of schema migration, full data migration, and incremental data migration. Does not delete source data.
    Scope ApsaraDB RDS for SQL Server instances only Self-managed databases on Elastic Compute Service (ECS), on-premises data centers, third-party cloud servers, and ApsaraDB RDS for SQL Server instances. See Supported databases.
    Migration types Full replication only; free of charge Schema migration, full data migration, and incremental data migration. For charges on incremental data migration, see Billing overview.
    Source data Not deleted Not deleted

    Use database replication for straightforward, one-time copies between RDS instances. Use DTS when you need incremental synchronization or want to migrate from a non-RDS source.

    Prerequisites

    Before you begin, ensure that you have:

    • A destination instance whose database engine version is greater than or equal to the source instance's version

    • A destination instance whose RDS edition is greater than or equal to the source instance's edition. Editions in descending order: RDS Cluster Edition, RDS High-availability Edition, RDS Basic Edition

    • A destination instance with available storage larger than the total size of the databases you want to replicate. To expand storage, see Change the specifications of an ApsaraDB RDS for SQL Server instance

    The instance families of the two instances can be the same or different (general-purpose or dedicated).

    Replicate databases

    1. Go to the Instances page. In the top navigation bar, select the region of the source instance, then click the instance ID.

    2. In the left-side navigation pane, click Databases.

    3. Click Replicate to Another Instance.

    4. In the dialog box, configure the following parameters:

      Parameter Description
      Source Instance Name The name of the source RDS instance. Displayed automatically.
      Destination Instance Name The name of the destination RDS instance. The region and network type must match the source instance; zones can differ.
      Source Databases The databases to replicate. Click 右移 or 左移 to move databases between the selection lists. Databases that share a name with an existing destination database are skipped. Selecting a database replicates both its schema and table data.
      Copy Users and Permissions Controls whether accounts and permissions are replicated to the destination instance. Users and permissions are also replicated.: Accounts and their permissions are copied. If the destination already has an account with the same username, that account's permissions are overwritten to match the source. If the account does not exist on the destination, it is created and granted the same permissions. Only databases are replicated. Users and permissions are not replicated. (default): Only database content is copied. After replication, create accounts on the destination and grant permissions manually. See Create accounts and databases.

    5. Click OK.

    The replication task runs in the background. No changes are written to the destination if the task fails.

    FAQ

    How long does replication take?

    Replication time depends primarily on the size of the databases being replicated. The following table gives throughput estimates based on uncompressed data size.

    Operation Required Throughput estimate
    Back up full data on the source No (skipped if a recent backup exists) ~200 GB per hour
    Restore the full backup on the destination Yes ~200 GB per hour
    Restore the database Yes Within 2 minutes

    36-hour rule: If no full backup has been taken on the source instance within the past 36 hours, a fresh full backup is triggered before restoration. To minimize total replication time, manually take a full backup before starting replication, or start replication within 36 hours of the last automatic full backup. See Back up an ApsaraDB RDS for SQL Server instance.

    Example: An instance with 4 CPU cores, 8 GB of memory, and 600 GB of data.

    • Back up full data: ~3 hours (600 GB / 200 GB/hr)

    • Restore full backup on destination: ~3 hours (600 GB / 200 GB/hr)

    • Restore database: within 2 minutes

    Total time: ~6 hours 2 minutes if no recent backup exists; ~3 hours 2 minutes if a full backup was taken within 36 hours.

    Notes on throughput:

    • Backup and restore speed varies by region and time of day. For a more accurate estimate, check the data volume and duration of the most recent full backup.

    • For instances with small specifications (for example, 2 CPU cores and 4 GB of memory), applying incremental transaction logs is resource-intensive and may significantly slow the database restore phase.

    • For instances running SQL Server 2019 or later, the Accelerated Database Recovery option can shorten the database restore phase. Evaluate this option against official Microsoft documentation before enabling it.

    What are the best practices for scheduling replication?

    • Schedule during off-peak hours to reduce impact on production workloads.

    • Avoid long-running transactions on the source instance during replication — for example, creating or rebuilding indexes, or archiving large datasets. These generate additional transaction logs that extend the database restore phase.

    What's next