When you need multiple Data Transmission Service (DTS) tasks with the same source type, access method, and object scope but different endpoints or business lines, creating each task from scratch is repetitive and error-prone. The Duplicate Task feature copies most settings from an existing task so you can reach a working configuration faster.
This feature is not a full clone. Instance parameters in the advanced configuration are reset to their defaults, database passwords are cleared, and you must purchase a new DTS instance. Review the configuration copy details before using this feature in production.
Limitations
The Duplicate Task button appears in the Actions column only when all of the following apply:
Task type: data migration, data synchronization, or data validation
Task status: configuration is complete—tasks in the Not Configured or Staging state are not supported
Exception: Global Active Database (GAD) tasks on ApsaraDB RDS are not supported
Prerequisites
Before you begin, make sure that you have:
An existing DTS task with a completed configuration (task type: data migration, data synchronization, or data validation)
The database account and password for both source and destination databases
Duplicate a task
Go to the DTS console. In the left navigation pane, select Data Synchronization, Data Migration, or Data Verification based on your task type.
Find the task to use as a template. In the Actions column, click Duplicate Task.
The task configuration page opens with most settings prefilled. Review and reconfigure the following before continuing:
Configure source and destination databases: Re-enter the password for both the source and destination databases. Verify that connection information and cross-account authorization are still valid, and confirm that the Database Account has sufficient permissions. > Note: When the source is ApsaraDB RDS for SQL Server, the Database Account field defaults to the built-in account
rdsdt_dtsacct. Change it to the actual database account of your ApsaraDB RDS for SQL Server instance.Configure task objects: Review all object selections, data filtering conditions, and schema or column name mappings. Check that the selected databases and tables still exist in the source database—the system copies only object names and does not verify whether they are still present. > Note: Instance parameters in the advanced configuration—such as Retry Time for Failed Connections and Retry Time for Other Issues—are reset to their defaults. Reconfigure any parameters that the original task had customized before starting the new task.
Purchase instance: Purchase a new DTS instance for this task.
Run a precheck and start the task.
Configuration copy details
The following table shows exactly which settings are copied and which are reset.
| Category | Copied | Reset |
|---|---|---|
| Task name | Defaults to the original task name. Change it to a meaningful name for easier identification. | — |
| Source and destination databases | Database Type, Access Method, Instance Region, Replicate Data Across Alibaba Cloud Accounts, Domain Name or IP, Port Number, Database Name, SSL-encrypted | Database Password (cleared for security); Database Account (cleared if the original task used an RDS system account) |
| Task objects | Selected database and table objects, data filtering conditions, schema and column name mappings, task type (full or incremental), DML and DDL operation types | — |
| Advanced settings | Dedicated cluster | Instance parameters (reset to defaults) |
| Data validation | All data validation configuration items | — |
| DTS task instance | DU configuration of the original Serverless instance | A new instance must be purchased |
When the destination is Kafka or RocketMQ, the topic renaming configuration is cleared.
Apply in production
Risk: unexpected behavior from reset instance parameters
Problem: Duplicating a task resets instance parameters in the advanced configuration—such as Retry Time for Failed Connections and Retry Time for Other Issues—to their defaults. Basic settings (task type, database and table objects, DML and DDL operation types, data validation configuration) are carried over, but performance-related parameters are not.
Impact: If you start the new task without reconfiguring these parameters, its performance and data scope may differ from the original.
What to do: In the task configuration step, review all advanced configuration parameters and restore any that the original task had customized.
Risk: precheck failure from changed database objects
Problem: The feature copies only the list of database and table names from the original configuration. It does not verify whether those objects still exist. If any databases or tables were deleted or renamed after the original task was created, the new task fails the precheck.
What to do: In the object configuration step, remove any objects that no longer exist in the source database, or reselect the correct objects.
Best practices
Treat the duplicated task as a template, not a final product. Review every configuration step before starting.
Pay close attention to object selection. The system copies object names only—always verify they still exist.
Monitor database load. Creating multiple similar tasks increases the load on the source and destination databases and the pressure on network bandwidth. Ensure that your database resources are sufficient to avoid business disruptions from resource bottlenecks.
FAQ
Why did the precheck fail with a "database object does not exist" error?
The duplicated task carries over the original object name list without checking whether those objects still exist in the source database. This error occurs when a database or table was deleted or renamed after the original task was created.
In the object configuration step, remove the missing objects or reselect the correct ones.
Why does the new task behave differently from the original?
Instance parameters in the advanced configuration—such as Retry Time for Failed Connections and Retry Time for Other Issues—are reset to their defaults when you duplicate a task. If these parameters were customized on the original task, the new task will behave differently until you reconfigure them.
In the task configuration step, review and restore all advanced configuration parameters to match your requirements.
Should I duplicate an existing task or modify it to add new sync objects?
It depends on what changed:
New databases or tables between the same source and destination: Edit the original task directly. Add the new sync objects in the object configuration step.
New source or destination, similar sync logic: Create a new task using Duplicate Task. It gets you to a working configuration faster than starting from scratch.