Use the backup center to back up an application in one ACK cluster and restore it in another cluster in the same region. This is the recommended approach for cluster upgrades, infrastructure refreshes, and cross-cluster disaster recovery within a region.
Limitations
Check these constraints before starting. Unmet conditions cause migration to fail:
Kubernetes version: The restore cluster must run Kubernetes 1.18 or later to use Elastic Compute Service (ECS) instance snapshots for disk data restoration.
Storage plugin: The restore cluster must use the Container Storage Interface (CSI) plugin. Migration is not supported on clusters using FlexVolume or a combination of csi-compatible-controller and FlexVolume.
System components: Install and configure the following components in the restore cluster before running a restore task:
aliyun-acr-credential-helper: Grant the required permissions and configureacr-configuration.alb-ingress-controller: Configure an ALBConfig resource.
Cross-region: This procedure supports same-region migration only. For cross-region migration, see Migrate applications across clusters in different regions.
Volume plugin compatibility: For clusters using different volume plugins or running older Kubernetes versions, see Use the backup center to migrate applications in an ACK cluster that runs an old Kubernetes version.
Prerequisites
Before you begin, ensure that you have:
Two ACK managed clusters in the same region: a backup cluster and a restore cluster
The migrate-controller component installed with the required permissions in both the backup cluster and the restore cluster. For details, see Install migrate-controller and grant permissions
A backup vault created or identified during migrate-controller installation. The system automatically detects existing vaults during installation, so you only need to create one if none exists. For details, see Create a backup vault
How it works
The backup center uses a shared backup vault as the intermediary between clusters. When you create a backup task in the backup cluster, the backup center uploads the application state and volume data to the vault. The backup center then synchronizes the backup record to the restore cluster, making the backup available as a restore point after synchronization completes.
When a restore task runs, the API version of Kubernetes resources upgrades automatically to the version recommended by the restore cluster. For example, a Deployment using extensions/v1beta1 in a Kubernetes 1.16 cluster becomes apps/v1 when restored in a Kubernetes 1.28 cluster.
Migrate a WordPress application across ACK clusters
This example uses two ACK managed clusters in the China (Hohhot) region — Cluster_A as the backup cluster and Cluster_B as the restore cluster. The WordPress application uses disk volumes for text content and NAS file system volumes for images.
Step 1: Set up the clusters
Create ACK managed clusters Cluster_A and Cluster_B in the same region. Update Cluster_B to Kubernetes 1.18 or later to support ECS snapshot-based disk restoration.
Install WordPress in Cluster_A using Helm. For details, see Deploy a WordPress application by using Helm.
Publish a blog post on WordPress that includes images. This populates both the disk volume (text) and the NAS file system volume (images), giving you data to verify after migration.
Step 2: Install migrate-controller and create a backup vault in Cluster_A
Install the migrate-controller component in Cluster_A and grant the required permissions. Create a backup vault during installation. For details, see Install migrate-controller and grant permissions.
If a backup vault already exists, the system detects it automatically. You do not need to create another one.
Step 3: Back up the application in Cluster_A
Create a backup task named 123backup-1 in Cluster_A to back up the default namespace. For details, see Create a backup plan or back up instantly.
Wait for the backup task status to change to Completed. Once complete, the backup record becomes visible on the Backups and Snapshots tab of the Application Backup page in Cluster_B after the vault syncs.
Step 4: Restore the application in Cluster_B
On the Application Backup page in Cluster_B, click Restore Now and select the shared backup vault.
If prompted to initialize the vault, click Initialize Backup Vault to associate it with Cluster_B.
After initialization, select the backup file 123backup-1 and start the restore task. For details, see Restore applications and volumes.
Step 5: Verify the migration
Verify workload health:
In the left-side navigation pane of the Cluster_B details page, go to Workloads > Deployments.
Find the WordPress Deployment and click Details in the Actions column.
Confirm the Deployment status is Running.
Verify application accessibility and data integrity:
In the left-side navigation pane, go to Network > Services.
On the Services page, locate the WordPress Service and click the link in the External Endpoint column.
Confirm the WordPress homepage loads and the blog post — including images stored in NAS — appears intact.
What's next
To manage backups and restores from the command line, see Use kubectl to back up and restore applications.
To migrate applications across regions, see Migrate applications across clusters in different regions.
For clusters using different volume plugins or Kubernetes versions, see Use the backup center to migrate applications in an ACK cluster that runs an old Kubernetes version.