Project Clone copies all entities and configuration from a source project to a target project in the same region. Use it to back up critical jobs, share resources across teams, or migrate data between storage types—without rebuilding from scratch.
Key concepts
Understand the difference between the two state types before you configure the clone strategy:
| Term | Description |
|---|---|
| Snapshot (savepoint) | A manually triggered state that you control. Trigger one before cloning to capture the latest job state. |
| System checkpoint | A state automatically managed by the system. The system clones only the most recent checkpoint. |
When you configure the clone strategy, you choose whether to carry either type of state into the target project (stateful) or clone only job code and configuration (stateless).
Use cases
| Goal | When to use | Key recommendation |
|---|---|---|
| Data backup | Back up critical jobs regularly; create snapshots at lifecycle milestones for rollback | Clone into an empty target project. Each clone creates a full backup—you do not need to manually filter incremental data. Name target projects by date or version—for example, Backup_20241001—so you can identify and recover a specific backup quickly. |
| Resource sharing | Reuse existing resources across teams; set up isolated dev, test, or production environments | The target project can already contain other resources. Use permission management to control who can access cloned resources. |
| Storage migration | Move from self-managed Object Storage Service (OSS) storage to fully managed storage; promote a test project to production | Grant read-only permissions (including ListObject) on the project-bound bucket to the fully managed account ARN before cloning. See Configure bucket policies and authorization policies. |
Prerequisites
Before you begin, make sure that:
-
The source project and target workspace and project are ready. See Enable Realtime Compute for Apache Flink or Manage projects.
-
Your account has the Owner role. Only the Owner role can enable cross-project migration. See Grant permissions in the development console.
-
If you are migrating from OSS to fully managed storage: the fully managed account ARN (
arn:sts::1060219998962774:assumed-role/aliyunstreamasidefaultrole/refresh_token) has read-only permissions, includingListObject, on the project-bound bucket.
Limitations
| Dimension | Constraint |
|---|---|
| Region | Same region only. Cross-region cloning is not supported. |
| Scope | Projects only. Cloning an entire workspace is not supported. |
| Excluded items | Task orchestration, queues, permissions, and alert configurations are not cloned. |
| Version policy | Only the latest draft (development mode) and published jobs (O&M mode) are cloned. Historical versions in development mode are ignored. |
| Concurrency | One-to-one only. Do not clone one source project to multiple targets, or multiple sources to one target, at the same time. |
| Storage compatibility | If the source workspace uses fully managed storage, the target must also use fully managed storage. OSS is not allowed as a target. |
| Architecture | Same architecture only. Cross-architecture cloning—for example, x86 to ARM—is not supported. |
| Stateful cloning | Stateful cloning with checkpoints or savepoints requires Ververica Runtime (VVR) 6.0.2 or later. |
Before you clone
Review these notes before starting a clone operation.
Cloning cannot be undone. If you stop a clone operation midway, manually delete the partially cloned resources from the target project.
Resource locking
Resource configurations are locked during cloning. You cannot modify them until cloning completes.
Trigger a snapshot before cloning
The system clones only the most recent snapshot or checkpoint of each job, regardless of job state (running, completed, or stopped). Trigger a snapshot manually before cloning to make sure the latest state is captured.
Avoid duplicate resources
Cloning to the same target project multiple times creates duplicate resources. If any entity names conflict, the system renames them automatically. Check the renaming list in Clone history after the operation.
Update catalog names manually
Catalog names in job code and configuration are not updated automatically after cloning. Edit them in the target project before starting the job—otherwise the job fails.
Test cloned jobs
After cloning, all jobs and Session clusters remain in the stopped state. Before starting any cloned job:
-
Test the job draft.
-
Verify that dependency files match expectations.
-
Adjust the job's dependency configuration as needed.
Clone a project
-
Log on to the Realtime Compute Management Console.
-
In the More column for the workspace you want to clone, click Clone workspace > Start clone.
-
Configure the clone:
-
Select a clone space (target workspace and project).
-
Select the objects to clone.
-
Select a clone strategy using the following table as a guide:
Configuration Options When to use Stateful streaming job cloning strategy Stateful Carry over the latest snapshot or system checkpoint to avoid reprocessing already handled data. Stateless Clone only job code and configuration. No state is copied. Running streaming job cloning strategy Skip Skip running jobs to prevent data interference from new states generated by the source job. Recommended for migration. Do not skip Include all selected running jobs and their latest snapshots or checkpoints. Recommended for backup. Error handling strategy Skip and continue Log failed items and continue with the remaining items. Stop cloning Halt the entire operation if any item fails. Allow stateless cloning If stateful cloning fails for an item, fall back to stateless cloning and continue. -
-
Click Start clone.
Monitor cloning progress
After clicking Start clone, a notification appears above the workspace list. Click View cloning progress to monitor the operation. Cloning may take time—you can leave it running in the background.
Verify the result
When cloning completes, view the results in Clone history:
-
In the More column for the target workspace, click Clone workspace > Clone history.
-
Click Details to see the entity types cloned, total count, failure count, and any automatic renaming applied to duplicate entities.
What's next
-
To back up individual SQL or DataStream jobs without cloning an entire project, see Back up a job and deploy a new job.