All Products
Search

This Product

    Realtime Compute for Apache Flink:Project Clone

    Document Center

    Realtime Compute for Apache Flink:Project Clone

    Last Updated:Feb 06, 2026

    The Project Clone feature enables you to quickly copy entities and configuration information from a source project to a target project within the same region. This reduces redundant development work, improves resource efficiency, and provides cold backup for disaster recovery. This topic describes the use cases, procedure, and important considerations for project cloning.

    Scenarios

    Type

    Use case

    Recommendation

    Data backup

    • Back up critical data regularly to prevent data loss during failures.

    • Create independent data snapshots at different stages of the project lifecycle for traceability or rollback.

    • Target project is empty: Clone the source project data into a new, empty target project. This ensures backup independence and avoids conflicts with existing data.

    • Full backup: Each clone creates a full backup. You do not need to manually filter incremental data. The system automatically captures the latest complete data state.

    • Version management: Name your target projects by date or version number to manage data versions. For example, Backup_20241001 and Backup_20241015 represent backups taken at different times, making later queries and recovery easier.

    Resource Cloning and Sharing

    • Reuse resources: Quickly introduce new resources by cloning when your existing project already contains many historical resources. Avoid rebuilding from scratch.

    • Cross-team collaboration: Distribute shared resources across multiple teams by cloning them into separate projects.

    • Environment isolation: Create isolated, consistent resource copies for test, development, or production environments.

    • Target project already has data: Unlike data backup, the target project often contains other resources. Cloning integrates source data seamlessly into your existing resource setup.

    • Permission management: Use permission management during cloning to ensure only authorized users can access or modify resources in the target project.

    Storage or data migration

    • Migrate from self-managed OSS storage to a fully managed service.

    • Migrate data from a test project to a production project.

    Storage permissions: When cloning from OSS to fully managed storage, grant read-only (including ListObject) permissions on the project-bound Bucket to arn:sts::1060219998962774:assumed-role/aliyunstreamasidefaultrole/refresh_token (fully managed account). For details, see Configure bucket policies and authorization policies.

    Limits

    • Region limit: Cross-project cloning is supported only within the same region. Cross-region cloning is not supported.

    • Cloning granularity: Only projects can be cloned. 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 in development mode and published jobs in O&M mode are cloned. Historical versions in development mode are ignored.

    • Concurrent operations: One-to-one cloning only. Do not clone one source project to multiple target projects simultaneously. Do not clone multiple source projects to one target project simultaneously.

    • Storage compatibility: If the source workspace uses fully managed storage, the target workspace must also use fully managed storage. OSS is not allowed as a target.

    • Architecture compatibility: Cloning is supported only between workspaces with the same architecture. Cross-architecture cloning—for example, from x86 to ARM—is not supported.

    • Stateful cloning: Stateful cloning with checkpoints or savepoints is supported only for Ververica Runtime (VVR) 6.0.2 or later.

    Important notes

    Obtain required permissions
    Ensure your account has clone permissions for the target workspace. Only the Owner role can enable cross-project migration. For details, see Grant permissions in the development console.

    Cloning limits

    • Resource locking: You cannot modify resource configurations during cloning.

    • No rollback: You cannot undo a clone operation. If you stop cloning, delete the cloned resources manually.

    • Avoid duplicates: Cloning multiple times to the same target project creates duplicate resources.

    • Storage permissions: When cloning from OSS to fully managed storage, grant read-only permissions—including ListObject—to arn:sts::1060219998962774:assumed-role/aliyunstreamasidefaultrole/refresh_token (fully managed account) on the project-bound bucket. For details, see Configure bucket policies and authorization policies.

    Create snapshots manually

    The system clones only the most recent snapshot or checkpoint of each job, regardless of whether the job is running, completed, or stopped. Manually trigger a snapshot before cloning to ensure the latest data is copied.

    Handle duplicate entity names
    The system automatically renames duplicate entities in the target project. View the renaming list in Clone history.

    Update catalog names manually
    Catalog names configured or referenced in jobs are not updated automatically. Edit the job code and configuration to update catalog names. Otherwise, the job fails.

    Test cloned jobs
    After cloning, jobs and Session clusters remain in the stopped state. Cloned jobs may not run immediately—for example, if dependency configurations are missing. Perform these steps:

    1. Test job draft.

    2. Verify that dependency files match expectations.

    3. Adjust the job’s dependency configuration.

    Procedure

    1. Prepare the source project and the target workspace and project. For details, see Enable Realtime Compute for Apache Flink or Manage projects.

    2. Clone project entities and configuration information.

      1. Log on to the Realtime Compute Management Console.

      2. In the More column for the workspace you want to clone, click Clone workspace > Start clone.

      3. Enter the clone configuration.

        1. Select a clone space.

        2. Select the objects to clone.

        3. Configure the clone strategy.

          Configuration

          Configuration options

          Description

          Stateful streaming job cloning strategy

          Stateful

          Clone the latest snapshot or system checkpoint. This prevents reprocessing of already handled data.

          Stateless

          Clone only job configuration and code. Do not clone snapshots or system checkpoints.

          Running streaming job cloning strategy

          Skip

          Automatically skip running streaming jobs during cloning. This avoids data interference caused by new states generated by the source job. Recommended for migration.

          Do not skip

          Clone all selected streaming jobs and their latest snapshots or system checkpoints. Recommended for backup.

          Error handling strategy

          Skip and continue

          Log failed items and continue with the rest.

          Stop cloning

          Stop the entire task if any item fails to clone.

          Allow stateless cloning

          If stateful cloning fails, fall back to stateless cloning and continue.

      4. Click Start clone.

    3. Check cloning progress and completion status.

      • During cloning

        After clicking Start clone, a message appears above the workspace list. Click View cloning progress to monitor the process. Cloning may take time. You can keep it running in the background.

        image

      • After cloning completes

        In the More column for the target workspace, click Clone workspace > Clone history. Then click Details. You can view the entity types cloned, total count, and failure count. The renaming list also appears.

    References

    To back up SQL and DataStream jobs, see Back up a job and deploy a new job.