Restore operation is stuck in pending state

You may encounter this issue when a pod in the cluster expects a schedulerName.

Problem

A restore procedure appears to be stuck in pending state.

Cause

This situation can arise when a pod in the backup has a schedulerName defined in the pod spec that is not present in the cluster to which it is being restored.

Prerequisites

To fix this issue, you can create a resource modifier configmap in the velero namespace on the target cluster, and then reference it when performing the restore.

A resource modifier is a set of rules for applying patches to resources. The following example shows a resource modifier that removes the schedulerName field from pod specs during restore.

version: v1
resourceModifierRules:
- conditions:
    groupResource: pods
  patches:
  - operation: remove
    path: "/spec/schedulerName"

Solution

1. Create a YAML file (for example, my-resource-modifier.yaml) that defines the resource modifier as shown above.
2. Create the resource modifier configmap in the velero namespace on the target cluster. For example:

   kubectl -n velero create cm my-res-mod-configmap --from-file my-resource-modifier.yaml

3. Add the name of the resource modifier configmap to your data values file. For example:

   ClusterName: target-cluster
   ManagementClusterName: attached
   ProvisionerName: attached
   BackupName: example-backup
   BackupSourceClusterName: source-cluster
   BackupSourceManagementClusterName: attached
   BackupSourceProvisionerName: attached
   ResourceModifierConfigMap: my-res-mod-configmap 
   

4. Then retry the restore operation.

   tanzu mission-control data-protection restore create -v ./data-values-file