CSI PVC restoring as-is with same original volume handle when VolumeSnapshot is not present with RestorePVs as true

[mayankagg9722]

What steps did you take and what happened:

1. Having CSI dynamic PVC and PVs in the cluster. Performing velero backup with snapshotVolumes: false
2. Restoring with this backup in the same cluster to different namespace. (performing namespace mapping).

Behaviour during Backup: Volume Snapshot are not taken as snapshotVolumes is set to False, but PVC YAMLs are backed up.

Issue During Restore: During restore velero is also restoring PVC Yamls as-is in the cluster with the same original volume handle, causing conflict if original PVC already exists in the cluster when RestorePVs=true

There are 2 different behaviours currently with velero restore:

1. RestorePVs=false

Here, restore of PVC yaml happens but velero is removing the volumehandle which is leading to new PV getting provisioned in the cluster ( this is the right behaviour).

velero/pkg/restore/actions/csi/pvc_action.go

Line 178 in aa7ca15

pvc.Spec.VolumeName = ""

2. RestorePVs=true

Here, restore of PVC yaml happening with same original volume handle in the cluster and velero is not removing the volumehandle which is leading to PVC provisioning failed (we need to improve this behaviour).

velero/pkg/restore/actions/csi/pvc_action.go

Line 224 in aa7ca15

if !ok {

Creation of PVC Yaml during restore:
https://github.com/vmware-tanzu/velero/blob/aa7ca1515926fa029e4d2f4d12e712f5e639a9ef/pkg/restore/restore.go#L1513C3-L1513C33

What did you expect to happen:
We expect volume handle from the PVC should be removed so that dynamic volume creation can happen at the time of restore of PVC YAML even when restored with flag RestorePVs=true when volume snapshot is not present.

Error:

Logs:

RestorePVs=false

RestorePVs=true

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"

[ywk253100]

@mayankagg9722 Could you explain a bit more about why you expect RestorePVs=true to work in your case?
Per my understanding, RestorePVs=false already meets your requirement and RestorePVs=ture works as design.

[mayankagg9722]

@ywk253100 If snapshots for the volumes do not exist, the behavior should remain consistent regardless of whether the restorePVs setting is enabled or disabled during the restore process.

Expected behavior: If Velero attempts to restore PVC YAMLs for which snapshots are unavailable, it should still create the PVC YAMLs but omit the volumeHandle. This ensures that new PVs can be dynamically provisioned.

[kaovilai]

We expect volume handle from the PVC should be removed so that dynamic volume creation can happen at the time of restore of PVC YAML even when restored with flag RestorePVs=true when volume snapshot is not present.

If you completely delete NS containing PVC and PV and restore from backup.. I would expect the same PV name to be created and used when not restoring from a snapshot.

The example scenario only happens if your backup inclulde PVC and PV yaml and you restore to a different NS perhaps right?

[mayankagg9722]

Yes @kaovilai you are right. So, is this the expected behaviour?

[kaovilai]

As currently implemented yes. Velero does not have pv name conflict resolution that I'm aware of.

Only scenarios that do not involve defining pv name such as creating PVC from dataSource snapshot.

[mayankagg9722]

@kaovilai I think we can make a similar change to make volume handling nil explicitly during this scenario as well when there is no snapshot exists:

velero/pkg/restore/actions/csi/pvc_action.go

Line 178 in aa7ca15

pvc.Spec.VolumeName = ""

velero/pkg/restore/actions/csi/pvc_action.go

Line 224 in aa7ca15

if !ok {

What are your thoughts?

[kaovilai]

Sure thing. Works for me.