All Products
Search
Document Center

Container Service for Kubernetes:Cross-account application backup and restore with a registered cluster

Last Updated:Jun 17, 2026

Connect the backup cluster to a registered cluster under the restore account to enable cross-account application backup and restore.

How it works

image

The backup cluster connects to a registered cluster under the restore account. The backup center in the registered cluster manages backup and restoration across both accounts.

What is backed up

Resource type Backed up Notes
Kubernetes resources (StatefulSet, Deployment, pod, Service, ConfigMap, Secret, Ingress, CronJob, PersistentVolumeClaim (PVC), PersistentVolume (PV), and so on) Yes
NAS volumes (via Cloud Backup) Yes Cannot be backed up or restored across accounts through VPCs
Disk volumes (via Cloud Backup or ECS snapshot) Yes Requires additional cross-account steps with the ECS snapshot solution
OSS volumes No Restored by mapping to the original OSS bucket with the backup cluster's AccessKey pair
Resources that are being deleted No

Prerequisites

Make sure that you have:

Install and configure the following components in the restore cluster before running a restore task:

  • aliyun-acr-credential-helper (Container Registry password-free component): Grant permissions and configure acr-configuration

  • alb-ingress-controller (ALB Ingress component): Configure an ALBConfig

Billing

The backup center itself is free. You may be charged for the following services:

Charge When it applies Details
OSS storage All backup scenarios — OSS stores the backup YAML files Standard OSS storage rates apply
ECS snapshot storage Disk volume backups using the ECS snapshot solution Starting October 12, 2023, 11:00 (UTC+8), the instant access feature no longer incurs storage or usage fees. PL0–PL3 ESSD (enhanced SSD) and ESSD AutoPL disks have instant access enabled by default
Cloud Backup NAS volume backups, and disk volume backups using the Cloud Backup solution Does not apply to OSS volume restoration

Limitations

  • Both clusters must run Kubernetes 1.16 or later. Migrating applications from a later Kubernetes version to an earlier one is not recommended.

  • For cross-region restoration, create the registered cluster in the same region as the restore cluster. The backup cluster connects over the Internet; restoration uses the internal network.

  • The backup center restores resources to a compatible API version in the restore cluster. If no compatible version exists, deploy the resource manually. See Release notes for Kubernetes versions supported by ACK and the upstream Deprecated API Migration Guide.

    • Deployments in a Kubernetes 1.16 cluster support extensions/v1beta1, apps/v1beta1, apps/v1beta2, and apps/v1. After migration to Kubernetes 1.28, the Deployment API version is restored to apps/v1.

    • Ingresses in a Kubernetes 1.16 cluster support extensions/v1beta1 and networking.k8s.io/v1beta1. Ingresses cannot be restored in a cluster running Kubernetes 1.22 or later.

    Important

    In Kubernetes 1.16, apps and rbac.authorization.k8s.io already support API version v1. After migrating to Kubernetes 1.28, manually restore Ingress and CronJob resources.

  • The backup center template for registered clusters differs from standard ACK clusters. When you connect or disconnect the backup cluster, reinstall the backup center component in the target cluster.

  • ECS snapshots created in the registered cluster belong to the backup cluster's account. To restore disk volumes in the restore account, share the snapshots across accounts (ECS snapshot solution) or use Cloud Backup.

  • To restore NAS volumes managed by CNFS (StorageClass: alibabacloud-cnfs-nas), create the StorageClass first.

  • If a same-name resource exists in the restore cluster, the backup center skips it. Restores are non-destructive.

Sample applications

These sample applications illustrate backup and restore behavior for each volume type.

Application Volume type PVC Data backup required Notes
sts-disk Disk volume pvc-disk Yes (Cloud Backup or ECS snapshot) Requires data consistency; suspend write operations before backup
sts-nas NAS volume pvc-nas Yes (Cloud Backup) Cannot back up or restore across accounts through VPCs; the restore cluster cannot read the original NAS data
sts-oss OSS volume pvc-oss No Restored by mapping to the original OSS bucket with the backup cluster's AccessKey pair

To create applications with different volume types, see Storage - CSI.

Choose a disk backup solution

Choose a solution when your application uses disk volumes.

Cloud Backup solution ECS snapshot solution
How it works Set enable_ecs_snapshot: false in csdr-config. Cloud Backup handles disk volume data. Set the target StorageClass to disk during restore. Set enable_ecs_snapshot: true in csdr-config. Share the ECS snapshot from the backup account to the restore account. Manually create a VolumeSnapshotContent and VolumeSnapshot before running the restore task.
Advantages No additional manual configuration Faster; guarantees data consistency on the same disk
Disadvantages Slower; cannot guarantee data consistency Manual steps required for each disk volume
Use when Your application does not require strict data consistency, or you have many disk volumes Your application requires data consistency and you can perform the snapshot-sharing steps

For applications without disk volumes, use the Cloud Backup solution.

(Optional) Step 1: Uninstall the backup center component in the backup cluster

Skip this step if migrate-controller is not installed in the backup cluster.

If the backup center is already installed in the backup cluster, uninstall it first. The template for registered clusters differs from standard ACK clusters, and both cannot coexist.

  1. Log on to the ACK console with the backup cluster's account. In the left-side navigation pane, click Clusters.

  2. On the Clusters page, click the name of the backup cluster. In the left navigation pane, click Add-ons.

  3. On the Add-ons page, click the Manage Applications tab.

  4. Find migrate-controller and click Uninstall.

  5. In the Uninstall message, click OK.

Step 2: Install the backup center component in the registered cluster

  1. Use the restore account to create a registered cluster and connect the backup cluster to it.create a registered cluster and connect the backup cluster to it.

  2. Install migrate-controller and grant permissions in the registered cluster.

    The registered cluster is in the same region as the backup cluster, so no OSS internal network route is needed.

Step 3: Create a backup task in the registered cluster

Important

Perform this step in the registered cluster under the restore account, not in the backup cluster.

Cloud Backup solution

Choose this for a simpler setup with disk volumes, or when your application has no disk volumes.

  1. Disable the ECS snapshot feature.

    1. Edit the csdr-config ConfigMap:

      kubectl -ncsdr edit cm csdr-config
    2. Set enable_ecs_snapshot to false. Save and exit.

    3. Restart the controller:

      kubectl -ncsdr delete pod -l control-plane=csdr-controller
  2. If the restore account has no backup vault, create one and associate it with the cnfs-oss-* OSS bucket in the restore account.

  3. Create a backup task for the sts-oss application.

    • Set Backup Volume to Disable — sts-oss maps to the original OSS bucket and does not need volume backup.

    • Select the oss namespace. If the namespace contains other applications, add labels to select only sts-oss.

    • On the Backup Records tab of the Application Backup page, wait for the status to change from InProgress to Completed. Click the record name and confirm that the StatefulSet, pod, PVC, PV, and Secret (containing the AccessKey pair) are backed up.

  4. Create a backup task for the sts-nas and sts-disk applications.

    • Set Backup Volume to Mounted Volumes.

    • With enable_ecs_snapshot set to false, Cloud Backup handles disk volume data. Monitor progress in the Cloud Backup console under Container Backup > Backup Jobs.

ECS snapshot solution

Choose this when your application uses disk volumes and requires data consistency.

  1. Enable the ECS snapshot feature.

    1. Edit the csdr-config ConfigMap:

      kubectl -ncsdr edit cm csdr-config
    2. Set enable_ecs_snapshot to true. Save and exit.

    3. Restart the controller:

      kubectl -ncsdr delete pod -l control-plane=csdr-controller
  2. If the restore account has no backup vault, create one and associate it with the cnfs-oss-* OSS bucket in the restore account.

  3. Create a backup task for the sts-oss application.

    • Set Backup Volume to Disable.

    • Select the oss namespace. If the namespace contains other applications, add labels to select only sts-oss.

    • On the Backup Records tab, wait for the status to change to Completed and verify all related resources are backed up.

  4. Create a backup task named backup-nas-disk for the sts-nas and sts-disk applications.

    • Set Backup Volume to Mounted Volumes.

    • Disk volume data is backed up using ECS snapshots by default. View snapshots in the ECS console under Snapshots > Disk Snapshots.

    • NAS volume data is backed up using Cloud Backup. Monitor progress in the Cloud Backup console under Container Backup > Backup Jobs.

Step 4: Create a restore task in the restore cluster

Important

Restores are non-destructive. If a same-name resource exists in the restore cluster, the backup center skips it.

Service restoration behavior:

Service type Restoration behavior
NodePort Ports are retained by default
LoadBalancer with ExternalTrafficPolicy: Local HealthCheckNodePort uses a random port by default. Set spec.preserveNodePorts: true when creating the restore task to retain the original port
LoadBalancer using an existing SLB instance The restored Service retains the original SLB instance but all listeners are disabled. Configure the listeners manually in the SLB console
LoadBalancer managed by cloud controller manager (CCM) The CCM creates new SLB instances during restoration. See Considerations for configuring a LoadBalancer type Service

Cloud Backup solution

Use the restore cluster's account to perform these steps.

  1. Restore the sts-oss application. See Restore applications and volumes.

    1. On the Application Backup page, click Back up Now, select and initialize the backup vault, and wait for the backup file to sync.

    2. Select the backup-oss backup file and create a restore task.

    3. Verify sts-oss is running. Use kubectl exec to log in to the container and confirm data consistency.

  2. Restore the sts-nas and sts-disk applications with StorageClass conversion. See Restore applications and volumes.

    1. On the Application Backup page, click Back up Now and select backup-nas-disk. For StorageClass conversion, select alicloud-disk for pvc-disk and alibabacloud-cnfs-nas for pvc-nas. alicloud-disk defaults to the alicloud-disk-topology-alltype StorageClass from the CSI plugin. You can also use a custom StorageClass.

    2. Verify the applications and data. In the ECS console, confirm that new disks are created in the restore account and mounted to the correct nodes.

ECS snapshot solution

  1. With the restore cluster's account, restore the sts-oss application. See Restore applications and volumes.

    1. On the Application Backup page, click Back up Now, select and initialize the backup vault, and wait for the backup file to sync.

    2. Select the backup-oss backup file and create a restore task.

    3. Verify sts-oss is running with kubectl exec.

  2. Use the backup cluster's account to share the disk snapshots with the restore account. In the ECS console, share each snapshot. Backup center snapshots are prefixed with snapshot-. Match them to backup records by creation time.

  3. Before accepting the shared snapshots, record the PVC-to-snapshot mappings in the backup account. These mappings are required for manual restoration.

    1. In the ECS console, record the mapping between each snapshot ID and its corresponding disk ID.

    2. In the backup cluster, query the PVC and disk ID for each PV that uses a disk volume:

      kubectl get pv <PV-Name> -o jsonpath='{"PVC: "}{.spec.claimRef.name}{"\nNamespace: "}{.spec.claimRef.namespace}{"\nVolumeHandle: "}{.spec.csi.volumeHandle}'

      Expected output:

      PVC: <disk-pvc-name>
      Namespace: <disk-pvc-namespace>
      VolumeHandle: d-2ze323ra0h2v5lxxxxx

      Use these mappings to link each PVC to its corresponding snapshot ID.

  4. Use the restore cluster's account to log on to the Resource Management console and accept the shared snapshots. Snapshot names stay the same but IDs change. Use the names and step 3 mappings to map each PVC to the new snapshot ID.

  5. Manually restore the disk volumes in the restore cluster.

    1. Use static provisioning to create a VolumeSnapshotContent and VolumeSnapshot in the restore cluster. See Create a snapshot of a disk volume. Create the VolumeSnapshot in the same namespace as the target PVC. Set snapshotHandle in the VolumeSnapshotContent to the new snapshot ID.

    2. Create a PVC with the same name as the original, referencing the VolumeSnapshot. See step 6 in Create a snapshot of a disk volume. The new PVC matches the original configuration with an additional dataSource parameter pointing to the VolumeSnapshot.

  6. Restore the sts-nas and sts-disk applications. See Restore applications and volumes. The backup center skips sts-disk volumes automatically because they were restored in step 5. The restore task mounts the same-name PVC to the application.

    1. On the Application Backup page, click Back up Now and select backup-nas-disk. Without StorageClass conversion, volumes restore with the original StorageClass. Ensure that StorageClass exists in the restore cluster.

    2. In the ECS console, confirm that new disks are created in the restore account and mounted to the correct nodes.

(Optional) Step 5: Disconnect the backup cluster and redeploy the backup center

After cross-account migration is complete:

  • If cross-account backup or restore is no longer needed, disconnect the backup cluster from the registered cluster.

  • To continue using the backup center in the backup cluster, uninstall the component from the registered cluster and reinstall it in the backup cluster.

Next steps