Overview

After creating or accessing a cluster, we recommend that you regularly back up the cluster data. Backing up data can help you quickly recover from unexpected disasters and easily migrate business data across clusters while ensuring data reliability.

You can create a backup policy on the platform by configuring the data types to be backed up (cluster configuration data stored in ETCD, business application data), data sources (nodes, namespaces), storage locations, backup methods, and rules. Then, by triggering the policy, you can back up the cluster data according to the configuration in the policy, making it easy for you to automatically back up cluster data at any time or on a regular basis.

Similarly, when you need to restore cluster business data, you can restore it based on the existing backup files by executing an application recovery task.

Tip: If you need to restore the configuration of the cluster based on ETCD backup data, please contact technical support.

Usage scenarios

For different backup and recovery scenarios, we recommend that you configure backup policies and perform recovery in the following recommended ways.

In the current Kubernetes cluster application and data backup recovery

When a local application fails (such as a namespace being accidentally deleted), you can restore the application to the current cluster using the backup file. During the recovery process, there is generally no need to modify the application resources themselves (such as the domain name and port of external services), only to restore the corresponding cluster resources.

1. Deploy plugins: Deploy the backup and recovery component under the current business cluster and configure its default storage (integrated with S3).

2. Create backup tasks: Create an application backup policy under the current cluster, select the namespace that runs the business application for backup, and perform automatic backups on a regular basis.

3. Perform recovery task: When recovery is needed, perform application recovery task under the current cluster.

Business data migration across clusters

The common scenarios for cross-cluster data backup and recovery are as follows:

• For traditional development and testing scenarios, applications need to be migrated across data centers, and data will be restored from backup files to other clusters. After the recovery is completed, modifications related to application resources may be required (such as domain names and ports for external services).

• For data migration scenarios where cluster resources are migrated to other clusters.

• For data migration scenarios where production cluster resources are replicated to development and testing clusters.

Prerequisites

• Try to ensure that the CPU, memory, and other specifications of the source and target clusters to be migrated are the same or not too different, to avoid situations where Pods cannot be scheduled due to resource reasons after migration and become Pending.

• Try to ensure that the network mode of the source and target clusters to be migrated is consistent. Otherwise, some resources may not be restored properly during recovery. If the subnets are different, the Pod IP will change after recovery.

Recommended approach

1. Deploy plugin: Deploy backup and recovery components in the source and target business clusters, and configure default storage for them (integrated with S3).

2. Create backup task: Create application backup policy in the source cluster, select the namespace where the business application is running for backup, and schedule automatic backups.

3. Determine whether to perform image migration: Before restoring data, consider whether to perform image migration based on the actual situation. Generally, if your image repository is not deployed in the source or target cluster, and both clusters can access the image repository, you do not need to perform this step. For the following scenarios, you need to perform image migration. Please refer to Batch image address replacement solution for migration operations.

4. Execute recovery task: Execute application recovery task under the target cluster.

5. Namespace import: After data migration, you need to manually import the namespace into the corresponding project in Project Management, refer to Import Namespace , otherwise the recovered application may not be visible on the platform frontend.

Cross-platform application and data migration

If you have two platforms, for example, in a disaster recovery scenario, when the main platform cluster fails and needs to be switched to the corresponding cluster in the backup platform, the application needs to be modified after migration (such as the domain name and port of external services).

Prerequisites

• Try to ensure that the CPU, memory, and other specifications of the source and target clusters to be migrated are the same or not too different, to avoid situations where the migrated Pod cannot be scheduled due to resource reasons.

• Try to ensure that the network mode of the source and target clusters to be migrated is consistent. Otherwise, some resources may not be restored properly during recovery. If the subnets are different, the Pod IP will change after recovery.

Notes

After data migration, you need to manually import the namespace into the corresponding project, otherwise the recovered application may not be visible on the platform frontend.

Recommended method

1. Deploy plugin: Deploy backup and recovery components in the source and target platform business clusters, and configure default storage (integrated with S3).

2. Create a backup task: Under the To be migrated cluster, create an application backup policy , select the namespace of the business application to be backed up, and schedule automatic backups.

3. Determine whether to perform image migration: Before restoring data, consider whether to perform image migration based on the actual situation. Generally, if your image repository is not deployed in either the source or target cluster, and both clusters can access the repository, you can skip this step. For the following scenario, you need to perform image migration. Refer to Batch Replacement of Image Addresses for migration operations.

4. Perform the restore task: Under the Target cluster, perform the application restore task .

5. Namespace import: After data migration, you need to manually import the namespace into the corresponding project in Project Management. Refer to Importing Namespaces . Otherwise, the restored application may not be visible on the platform frontend.