Perform the application recovery task

You can quickly restore the application to the target namespace by performing an application recovery task based on existing application backup records in the following scenarios:

• Kubernetes resources are accidentally deleted and need to be restored.

• Application data needs to be migrated to other namespaces in the same cluster.

• Application resources need to be migrated to namespaces in other clusters on the platform.

• Kubernetes resources that have already been backed up in the production cluster need to be restored to the disaster recovery cluster.

Prerequisites

• An application backup that has been successfully backed up already exists in the object storage where the cluster stores backup files.

• If the storage resource used by your persistent volume claim has a Recycle Strategy of Retain, you need to delete the spec.claimRef.uid and spec.claimRef.uid.resourceVersion fields of the corresponding persistent volume claim before you can continue to restore the application data in the persistent volume.

• If you need to perform cross-cluster recovery (data migration), you need to ensure that the target cluster and the cluster where the backup file is located can read the same backup file. This can be achieved in two ways:

  • The target cluster and the cluster where the backup file is located are connected to the same object storage.

  • The required backup files are copied to the object storage connected to the target cluster in advance.

• If you have selected Backup Kubernetes resources and persistent volume claims as the resource type for the application backup created in the backup management, ensure that the StorageClass name of the target cluster is the same as the StorageClass name of the source cluster. If you cannot ensure consistency, configure the mapping relationship between the source cluster storage class and the target cluster storage class in the Advanced Settings for Recovery Target.

Procedure

1. In the left navigation bar, click Clusters > Backup and Recovery.

2. Switch to the Recovery Management tab.

3. Click Execute Application Recovery Task.

4. Configure the relevant parameters according to the following instructions.

   Parameter	Description
   Backup Repository	Select a backup repository that has passed connectivity verification, or click Create Backup Repository . Tip: After creating a backup repository, you can click OK and Create Application Backup to return to this page and continue creating, or click Create to return to the backup repository list page to view the created backup repositories.
   Recovery File Configuration	Select the backup file that stores the backup data. Tip: The file name prefix is the name of the backup policy, and only successfully backed up files can be selected.
   Recovery Target Configuration	Namespaces: The namespace where data recovery is performed, and also the source namespace of the backup data. The optional range is the namespace set in the backup policy. The system will restore the backup data in the same namespace based on your selection. Tip: If you need to restore backup data to other namespaces under the cluster, please configure Advanced Recovery Target Settings.
   Advanced Recovery Target Settings	By configuring advanced settings, you can restore backup data originally scheduled to be restored in the source namespace of the backup data to any namespace (existing or newly created) under the cluster. Source Namespace: The selected namespace. Target Namespace: The namespace where data recovery is performed, which can be an existing namespace under the cluster or a new namespace created by entering a non-existent namespace name under the cluster during recovery. Tip: When you select Backup Kubernetes Resources and Persistent Volume Claims as the application backup resource type in backup management, make sure that the StorageClass name of the target cluster is consistent with the StorageClass name of the source cluster backup file. If they are inconsistent, you can configure the source storage class name and target storage class name in the advanced options, and the platform will automatically store data based on the new storage class.

5. Click on the YAML button in the upper right corner to switch to YAML editing mode. You can refer to Configuring Hooks to customize the extension commands that need to be run during the configuration recovery process.

   Caution: By default, when executing an application recovery task, the backup file will be compared with the resources in the target namespace. Only the data that exists in the backup file but is missing in the namespace will be restored. It will not overwrite the resources with the same name or incremental resources (existing in the namespace but missing in the backup file) in the namespace.

   If you need to overwrite resources with the same name that already exist in the namespace, please refer to the following steps:

   1. Click on the YAML button in the upper right corner to switch to YAML editing mode.

   2. Add the key-value pair existingResourcePolicy: update under .spec, and add the pods field to the value of excludedResources as follows: excludedResources: ["pods"].

   Tip: This method cannot overwrite application data in persistent volumes bound to PVC.

6. Click on Start.

What’s next

1. Namespace Import: After data migration in cross-cluster and cross-platform scenarios, you need to manually import the namespace into the corresponding project in Project Management. Refer to Importing Namespaces . Otherwise, the recovered application may not be visible on the platform frontend.

2. Reconfigure Fixed IP: After data migration in cross-cluster and cross-platform scenarios, the fixed IP addresses of the containers in your compute components will change. If you need to make changes, you need to manually update the Static IP Address parameter of the container group in the container platform for deployments, daemon sets, and stateful sets.

Relevant operations

Try again

When the recovery task execution fails, you can retry and execute the recovery task again.

Tip: Retrying will generate a new recovery record, and you can view the execution status of the task through the new recovery record.

Procedure

1. Click Clusters > Backup and Recovery on the left navigation bar.

2. Switch to the Recovery Management tab.

3. Click the > Retry on the right side of the failed recovery record, and confirm.

Download the application recovery task log

Each time a recovery task is executed, a recovery record is generated. You can view the execution status and details (YAML) of the recovery task through the recovery record, and manually download the operation log of the application recovery task.

Procedure

1. Click Clusters > Backup and Recovery on the left navigation bar.

2. Switch to the Recovery Management tab.

3. Click the > Export Log on the right side of the recovery record.