Clone namespace PVCs with --namespace-mappings fails

[liogate]

What steps did you take and what happened:

Hello there. We are testing the process of copying a Persistent Volume (PV) with a Retain policy on the Scaleway provider. Below are the steps we have followed:

• Created a cluster-wide backup with Restic enabled, making sure to include the namespace containing my Persistent Volume Claim (PVC).
• Successfully deleted and restored my namespace.
• Attempted to restore the backup using namespace mapping <ns-a>:<ns-b>, which includes PV, PVC, and pods for this restoration, along with a few additional resources.

velero restore create \
  --from-backup $VELERO_SELECTED_BACKUP \
  --include-namespaces $VELERO_SELECTED_NAMESPACE \
  --namespace-mappings $VELERO_SELECTED_NAMESPACE:$VELERO_RESTORE_NAMESPACE \
  --include-resources pods,configmaps,secrets,serviceaccount,persistentvolumeclaims,persistentvolumes \
  --restore-volumes=true

The result -- PVC Restore is stuck with could not restore and following error shows up : PersistentVolume "pvc-xxx" already exists. We have exactly same PV id on both namespace VELERO_SELECTED_NAMESPACE and VELERO_RESTORE_NAMESPACE.

Related issue : #192 (comment)
CC : @sseago

What did you expect to happen:

To restore volume with different cloud provider volume id to avoid conflict with existing volume on original namespace.

Environment:

• Velero version (use velero version): v1.12.1
• Velero features (use velero client config get features):
• Kubernetes version (use kubectl version): v1.27.6
• Kubernetes installer & version:
• Cloud provider or hardware configuration: Scaleway Kapsule
• OS (e.g. from /etc/os-release):

Vote on this issue!

This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

• 👍 for "I would like to see this bug fixed as soon as possible"
• 👎 for "There are more important bugs to focus on right now"

[reasonerjt]

@liogate
Could you clarify if you are using dynamic provisioning? If the answer is "yes", when the PVC is restored in the new namespace, it should trigger the provider defined in storage class to create a new PV.

[liogate]

Hi @reasonerjt,
We are using one of native storage class bssd-retain from Scaleway which provide new persistent volume automatically. Hope this helps.

[ywk253100]

@liogate I cannot reproduce the issue in my AKS env.
As @reasonerjt mentioned, when restoring the PVC the PV info on it is cleared and a new PV should be created: https://github.com/vmware-tanzu/velero/blob/v1.12.1/pkg/restore/restore.go#L1449
Not sure why this doesn't work in your env, could you do some debugging in this direction?

[ywk253100]

Closing due to inactivity