Run an Application Restore 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 were 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 backed up in the production cluster need to be restored to the disaster recovery cluster.

#Prerequisites

• A successful application backup exists in the object storage where the cluster stores backup files.

• If the PersistentVolume has a reclaimPolicy of Retain, delete spec.claimRef.uid and spec.claimRef.resourceVersion on the corresponding PersistentVolume (PV) before restoring data to the bound PVC.

• For cross-cluster recovery (data migration), ensure that the target cluster and the cluster where the backup file resides can read the same backup file. This can be achieved in two ways:

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

  • Copy the required backup files to the object storage connected to the target cluster in advance.

• If Backup Kubernetes resources and persistent volume claims was selected as the resource type for the application backup, ensure that the target cluster StorageClass name matches that of the source cluster. If not, configure the mapping between the source and target storage classes in Advanced Recovery Target Settings.

#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 parameters as follows.

   Parameter	Description
   Backup Repository	Select a repository that has passed connectivity verification, or click Create Backup Repository. Tip: After creating a repository, click OK and Create Application Backup to return and continue, or click Create to return to the repository list.
   Recovery File Configuration	Select the backup file that stores the backup data. Tip: The file name prefix is the name of the backup policy; only successfully backed up files can be selected.
   Recovery Target Configuration	Namespaces: The namespace where data recovery is performed and the source namespace of the backup data. The optional range is the namespace set in the backup policy. The system restores backup data to the same namespace based on your selection. Tip: To restore to other namespaces in the cluster, configure Advanced Recovery Target Settings.
   Advanced Recovery Target Settings	Restore backup data originally scheduled for the source namespace to any namespace in the cluster (existing or newly created). Source Namespace: The selected namespace. Target Namespace: The namespace where data recovery is performed; either an existing namespace or a new one created by entering a non-existent name. Tip: If Backup Kubernetes Resources and Persistent Volume Claims was selected as the application backup resource type, ensure that the target cluster StorageClass name matches the source. If not, configure the source and target storage class names in the advanced options; the platform stores data using the new storage class.

5. Click YAML in the upper-right corner to switch to YAML editing mode. Refer to Configuring Hooks to configure commands that run during recovery.

   Caution: By default, the backup file is compared with resources in the target namespace. Only data that exists in the backup file but is missing in the namespace is restored. Resources with the same name or incremental resources (existing in the namespace but missing in the backup file) are not overwritten.

   To overwrite resources with the same name that already exist in the namespace:

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

   2. Add existingResourcePolicy: update under .spec, and add pods to excludedResources as follows: excludedResources: ["pods"].

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

6. Click Start.

#What's next

1. Namespace Import: After cross-cluster or cross-platform migration, manually import the namespace into the corresponding project in Project Management. Otherwise, the recovered application may not be visible in the platform UI.

2. Reconfigure Fixed IP: After cross-cluster or cross-platform migration, fixed IP addresses of containers in compute components change. If necessary, manually update the Static IP Address parameter of the container group for deployments, daemon sets, and stateful sets.

#Relevant operations

#Try again

If the recovery task fails, retry the task.

#Procedure

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

2. Switch to the Recovery Management tab.

3. Click Retry on the right 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. View the execution status and details (YAML) through the recovery record, and manually download the operation log of the application recovery task.

#Procedure

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

2. Switch to the Recovery Management tab.

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