ApsaraDB RDS provides three distinct approaches to moving or preserving data: migration, synchronization, and recovery. Each serves a different purpose and fits different operational scenarios. Use the comparison below to pick the right approach before you start.
At a glance
| Data migration | Data synchronization | Data recovery | |
|---|---|---|---|
| Purpose | Move data to or from Alibaba Cloud | Keep two data sources in sync continuously | Restore an instance from a backup |
| Powered by | Data Transmission Service (DTS) | Data Transmission Service (DTS) | ApsaraDB for RDS console |
| One-time or ongoing | One-time (you can release the task immediately after it completes) | Ongoing (runs continuously) | One-time |
| Supports incremental changes | Yes (optional) | Yes (always) | No |
| Two-way sync | No | Yes | No |
| Typical use cases | Cloud onboarding, cloud offboarding | Active geo-redundancy, disaster recovery, real-time warehousing | Accidental deletion, instance corruption |
Data migration
Data migration moves data between Alibaba Cloud and other environments using DTS. Use it when you need a one-time transfer — for example, migrating an on-premises database to the cloud or moving data from a third-party cloud platform.
Supported sources and destinations:
On-premises databases
User-created databases on ECS instances
Databases on third-party cloud platforms
ApsaraDB for RDS instances (for migrating away from Alibaba Cloud)
Key behavior: You can release a migration task immediately after it completes. If you select the incremental data migration option when creating the task, data changes that occur during migration are also transferred — but this is not the same as ongoing synchronization.
Data synchronization
Data synchronization keeps two data sources in sync in real time. Unlike migration, a synchronization task runs continuously after you create it — it does not stop automatically.
When to use data synchronization:
Active geo-redundancy — distribute active traffic across multiple regions
Disaster recovery — maintain a live standby that takes over if the primary fails
Cross-border data synchronization — replicate data across geographic regions
Query load balancing — offload read traffic to a replica
Cloud BI systems — feed real-time data into reporting pipelines
Real-time data warehousing — stream operational data into a warehouse continuously
Capabilities beyond incremental migration:
Update synchronized objects without stopping the task
Enable two-way data synchronization between two sources
When not to use data synchronization:
| Scenario | Use instead |
|---|---|
| One-time cloud migration | Data migration |
| Restoring from accidental data loss | Data recovery |
| Replicating a single backup snapshot | Data recovery |
Data recovery
Data recovery restores an ApsaraDB for RDS instance from a backup. Use it when you need to undo data loss or corruption — not to move data to a new environment.
Two recovery methods:
Point-in-time recovery — restore to a specific point in time using a backup file combined with binary log files
Backup-based recovery — restore from a full backup file
When to use data recovery:
Accidental deletion of data
Instance corruption
Limitation: Data recovery does not support incremental data migration. To migrate data from a recovered instance back to an original instance without updating application endpoints, restore to a new instance first, then use DTS to migrate the data back.
Combine approaches
Migration and recovery work well together. For example:
Restore an instance to a new ApsaraDB for RDS instance using data recovery.
Use DTS to migrate data from the restored instance back to the original instance.
This lets you recover data without changing the connection endpoints that your applications use.