Connect the backup cluster to a registered cluster under the restore account to enable cross-account application backup and restore.
How it works
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:
-
Cloud Backup activated — used for file-based backups of NAS volumes, OSS buckets, and local disk volumes
-
A restore cluster running Kubernetes 1.16 or later (1.18 or later for ECS snapshot-based disk restoration). See Create an ACK managed cluster, Create an ACK dedicated cluster (discontinued), or Create a cluster registration proxy and register a Kubernetes cluster that is deployed in a data center
-
The restore cluster must use the Container Storage Interface (CSI) plugin. Clusters that use FlexVolume or csi-compatible-controller with FlexVolume are not supported.
csi-compatible-controllerwith FlexVolume are not supported -
CSI 1.1.0 or later installed (required for disk snapshot-based volume backup)
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, andapps/v1. After migration to Kubernetes 1.28, the Deployment API version is restored toapps/v1. -
Ingresses in a Kubernetes 1.16 cluster support
extensions/v1beta1andnetworking.k8s.io/v1beta1. Ingresses cannot be restored in a cluster running Kubernetes 1.22 or later.
ImportantIn Kubernetes 1.16,
appsandrbac.authorization.k8s.ioalready 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.
-
Log on to the ACK console with the backup cluster's account. In the left-side navigation pane, click Clusters.
-
On the Clusters page, click the name of the backup cluster. In the left navigation pane, click Add-ons.
-
On the Add-ons page, click the Manage Applications tab.
-
Find migrate-controller and click Uninstall.
-
In the Uninstall message, click OK.
Step 2: Install the backup center component in the registered cluster
-
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.
-
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
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.
-
Disable the ECS snapshot feature.
-
Edit the
csdr-configConfigMap:kubectl -ncsdr edit cm csdr-config -
Set
enable_ecs_snapshottofalse. Save and exit. -
Restart the controller:
kubectl -ncsdr delete pod -l control-plane=csdr-controller
-
-
If the restore account has no backup vault, create one and associate it with the
cnfs-oss-*OSS bucket in the restore account. -
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
ossnamespace. If the namespace contains other applications, add labels to select onlysts-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.
-
-
Create a backup task for the sts-nas and sts-disk applications.
-
Set Backup Volume to Mounted Volumes.
-
With
enable_ecs_snapshotset tofalse, 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.
-
Enable the ECS snapshot feature.
-
Edit the
csdr-configConfigMap:kubectl -ncsdr edit cm csdr-config -
Set
enable_ecs_snapshottotrue. Save and exit. -
Restart the controller:
kubectl -ncsdr delete pod -l control-plane=csdr-controller
-
-
If the restore account has no backup vault, create one and associate it with the
cnfs-oss-*OSS bucket in the restore account. -
Create a backup task for the sts-oss application.
-
Set Backup Volume to Disable.
-
Select the
ossnamespace. If the namespace contains other applications, add labels to select onlysts-oss. -
On the Backup Records tab, wait for the status to change to Completed and verify all related resources are backed up.
-
-
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
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.
-
Restore the sts-oss application. See Restore applications and volumes.
-
On the Application Backup page, click Back up Now, select and initialize the backup vault, and wait for the backup file to sync.
-
Select the backup-oss backup file and create a restore task.
-
Verify sts-oss is running. Use
kubectl execto log in to the container and confirm data consistency.
-
-
Restore the sts-nas and sts-disk applications with StorageClass conversion. See Restore applications and volumes.
-
On the Application Backup page, click Back up Now and select backup-nas-disk. For StorageClass conversion, select
alicloud-diskforpvc-diskandalibabacloud-cnfs-nasforpvc-nas.alicloud-diskdefaults to thealicloud-disk-topology-alltypeStorageClass from the CSI plugin. You can also use a custom StorageClass. -
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
-
With the restore cluster's account, restore the sts-oss application. See Restore applications and volumes.
-
On the Application Backup page, click Back up Now, select and initialize the backup vault, and wait for the backup file to sync.
-
Select the backup-oss backup file and create a restore task.
-
Verify sts-oss is running with
kubectl exec.
-
-
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. -
Before accepting the shared snapshots, record the PVC-to-snapshot mappings in the backup account. These mappings are required for manual restoration.
-
In the ECS console, record the mapping between each snapshot ID and its corresponding disk ID.
-
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-2ze323ra0h2v5lxxxxxUse these mappings to link each PVC to its corresponding snapshot ID.
-
-
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.
-
Manually restore the disk volumes in the restore cluster.
-
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
snapshotHandlein the VolumeSnapshotContent to the new snapshot ID. -
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
dataSourceparameter pointing to the VolumeSnapshot.
-
-
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.
-
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.
-
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.