All Products
Search

This Product

    Realtime Compute for Apache Flink:Namespace cloning

    Document Center

    Realtime Compute for Apache Flink:Namespace cloning

    Last Updated:Aug 06, 2026

    Namespace cloning lets you quickly copy entities and configurations between namespaces in the same region. This reduces repetitive development, improves resource use, and serves as a cold backup for disaster recovery. This topic describes the use cases, procedure, and usage notes for namespace cloning.

    Use cases

    Category

    Use case

    Recommendation

    Data backup

    • Regularly back up critical data to prevent data loss from system failures.

    • Create independent data snapshots at different stages of the project lifecycle to support traceability or rollbacks.

    • Use an empty target namespace: Clone data to a new, empty namespace. This ensures the independence of the backup data and prevents conflicts with existing data.

    • Full backup: Each clone is a full backup of the data. The system automatically captures the latest complete data state, so you do not need to manually filter for incremental data.

    • Version management: You can easily implement version control by naming the target namespace with a date or version number. For example, Backup_20241001 and Backup_20241015 can represent backups from different points in time, making it easier to query and restore data later.

    Resource cloning and sharing

    • Resource reuse: If a namespace contains many resources, you can clone it to quickly copy them and avoid repetitive setup.

    • Cross-team collaboration: When multiple teams need to share the same resources, you can clone them into separate namespaces for each team.

    • Environment isolation: In test, development, or production environments, you can use the cloning feature to create independent copies of resources to ensure isolation and consistency across environments.

    • Target namespace with existing data: In resource sharing scenarios, the target namespace often contains existing resources. Cloning helps you seamlessly integrate the source data into the existing resource structure.

    • Permission management: Use permission management to ensure that only authorized users can access and manage resources in the target namespace.

    Storage and data migration

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

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

    Storage permissions: To clone from OSS storage to fully managed storage, you must also grant read-only permission, including the ListObject action, on the bucket that is bound to the namespace to the fully managed account arn:sts::1060219998962774:assumed-role/aliyunstreamasidefaultrole/refresh_token. For more information, see Set a bucket policy.

    Limitations

    • Region restriction: You can only clone namespaces within the same region.

    • Cloning scope: You can only clone namespaces, not entire workspaces.

    • Excluded content: Task orchestration, queues, permissions, and alert configurations are not cloned.

    • Version policy: Only the latest draft from the development environment and the latest deployment from the operations environment are cloned. Historical draft versions are ignored.

    • Concurrent operations: You cannot simultaneously clone one source namespace to multiple targets, or multiple sources to one target.

    • Storage compatibility: If the source workspace uses fully managed storage, the target workspace must also use fully managed storage. You cannot select a workspace that uses OSS as the target.

    • Architecture compatibility: Cloning is supported only between namespaces that have the same architecture. Cross-architecture cloning between x86 and ARM is not supported.

    • Stateful cloning: Stateful cloning that uses a checkpoint or savepoint is supported only for engine versions VVR 6.0.2 and later.

    Usage notes

    Permissions
    To clone a namespace, you must have the Editor role for both the source and target namespaces. The system uses this user's identity for end-to-end authentication. For more information, see Authorize users in the development console.

    Cloning restrictions

    • Resource lock: You cannot change resource configurations during the cloning process.

    • Irreversible operation: The cloning operation is irreversible. If you stop the process, you must manually delete any cloned resources.

    • Avoid duplication: Cloning to the same target namespace multiple times creates duplicate resources.

    • Storage permissions: To clone from OSS storage to fully managed storage, you must also grant read-only permission, including the ListObject action, on the bucket that is bound to the namespace to the fully managed account arn:sts::1060219998962774:assumed-role/aliyunstreamasidefaultrole/refresh_token. For more information, see Set a bucket policy.

    Cloned job state

    When you choose stateful cloning:

    • For completed or stopped streaming jobs, the system clones the latest snapshot or system checkpoint.

    • For running or transitioning streaming jobs, if the running streaming job cloning policy is set to Do not skip, the system automatically creates a snapshot before cloning. However, because the job continues to run, it may generate a newer system checkpoint, so the cloned snapshot may not be the latest state.

    Check streaming job status

    • In migration scenarios, stop the source job before cloning to prevent data inconsistencies from newly generated state.

    • Running the source job and its cloned copy simultaneously can disrupt your business logic. Ensure there is no impact before you start the cloned job.

    • A successful system checkpoint indicates that the cloned job is functioning correctly. Monitor its status closely.

    Handle naming conflicts
    The system automatically renames any entity in the target namespace that has the same name as a cloned entity. You can view a list of renamed items on the Details page of the cloning history.

    Manually update configurations
    You must manually update catalog names in the job code and configuration because they are not automatically updated during cloning. This prevents the job from failing.

    Debug jobs
    After cloning is complete, jobs and the session cluster are stopped. A cloned job may fail to run, for example, if dependency settings are missing. Take the following actions:

    1. Debug the job draft.

    2. Check that dependency files are as expected.

    3. Adjust the job's dependency configurations.

    Procedure

    1. Prepare the source namespace, the target workspace, and the target namespace. For more information, see Activate Realtime Compute for Apache Flink or Manage namespaces.

    2. Clone the entities and configuration of the namespace.

      1. Log on to the Realtime Compute for Apache Flink console.

      2. In the More column for the source workspace, choose Namespace Cloning > Start.

      3. Configure the cloning settings.

        1. Select the source and target namespaces.

        2. Select the objects to clone.

          You can select objects to clone as needed, such as job drafts, deployments, file resources, custom catalogs, UDFs, connectors, data formats, and variable configurations.

          When you clone deployments, all jobs in the current namespace are selected by default. You can filter the list to select specific jobs. Filtering is supported by job name, job type, engine version, run status, and the time when the job was last cloned.

        3. Configure cloning policies.

          Configuration

          Option

          Description

          Streaming job state cloning policy

          With state

          Clones the latest snapshot or system checkpoint to prevent reprocessing of already processed data.

          Stateless

          Clones only the job configuration and code, without any snapshot or system checkpoint.

          Running streaming job cloning policy

          Skip

          Skips running streaming jobs to prevent data interference from new state generated by the source job. Recommended for migration scenarios.

          Do not skip

          Creates a snapshot of running streaming jobs before cloning to ensure that the latest state is captured. Recommended for backup scenarios.

          Error handling policy

          Skip and continue

          If an entity fails to clone, the failure is logged and the process continues with the remaining entities.

          Stop cloning

          If any entity fails to clone, the entire cloning task stops immediately. Data that was successfully cloned is retained.

          Allow stateless cloning

          If stateful cloning fails, the process automatically falls back to stateless cloning and continues.

      4. Click Start.

    3. View the cloning progress and results.

      • During cloning

        Shortly after you click Start, a notification appears above the workspace list. Click View cloning progress to monitor the process. The process may take a long time, but you can let it run in the background.

        In the Namespace Cloning dialog box, you can view the cloning progress for each module, including metadata management, session management, Security Center, data development, and job operations. At the bottom of the dialog box, you can find the Run in Background and Stop cloning buttons.

      • After cloning is complete

        In the More column for the target workspace, choose Namespace Cloning > History, and then click Details. You can view the categories, total count, and failure count of cloned entities. A list of renamed entities is also displayed.

    Related documents

    To learn how to back up SQL and DataStream jobs, see Back up and deploy a job.