CSI Snapshot Data Movement restores NFS volumes using temporary Velero PVC identities, preventing preservation of original NFS paths

Anything else you would like to add:

This appears to be a Velero CSI Snapshot Data Movement restore bug.

During restore, Velero provisions the target volume using a temporary PVC created in the velero namespace. Consequently, the NFS CSI driver receives the following temporary identity:

csi.storage.k8s.io/pvc/name: viya-full-restore-20260916-082206-701039688-v6vxj
csi.storage.k8s.io/pvc/namespace: velero

The NFS CSI driver correctly evaluates the configured StorageClass template:

subDir: ${pvc.metadata.namespace}/${pvc.metadata.name}/${pv.metadata.name}

However, because Velero supplies the temporary restore PVC identity during provisioning, the driver creates the backend path as:

velero/viya-full-restore-20260916-082206-701039688-v6vxj/pvc-2391320d-1af6-4efe-84ac-12dfecafcba8

The DataDownload resource already contains the original target application PVC information:

spec:
  sourceNamespace: mt
  targetVolume:
    namespace: mt
    pvc: xxx-crunchy-platform-postgres-00-zgwl-pgdata

Therefore, Velero has the original target namespace and PVC name available, but the dynamically provisioned PV retains the identity and backend path of the temporary Velero PVC.

Although the restored application PVC is eventually named correctly and the restore completes successfully, its PV continues to reference a backend NFS directory based on the temporary Velero restore PVC.

Changing the StorageClass template from:

subDir: ${pvc.metadata.namespace}/${pvc.metadata.name}/${pv.metadata.name}

to:

subDir: ${pvc.metadata.namespace}/${pvc.metadata.name}

does not resolve the underlying issue. It would only change the generated path to:

velero/viya-full-restore-20260916-082206-701039688-v6vxj

because the volume is still provisioned from the temporary PVC in the velero namespace.

Requested solution

Velero CSI Snapshot Data Movement restore should provide a supported mechanism to provision or finalize the restored volume using the original target PVC identity:

<original-namespace>/<original-pvc-name>/<pv-name>

instead of leaving the restored PV associated with:

velero/<temporary-restore-pvc-name>/<pv-name>

Questions for the Velero maintainers

1. How can CSI Snapshot Data Movement restore preserve the original PVC namespace and name when dynamically provisioning the final target volume?

2. Is there an existing Velero restore configuration, resource modifier, or Data Mover setting that allows the final volume to be provisioned using DataDownload.spec.targetVolume.namespace and DataDownload.spec.targetVolume.pvc?

3. Can Velero create a temporary staging volume for DataDownload but then move or bind the restored data to a final volume provisioned from the original application PVC identity?

4. If this is not currently supported, can Velero add a mechanism to preserve or remap the original NFS directory hierarchy during CSI Snapshot Data Movement restore?

5. Can the final restored PV be updated so its CSI attributes and backend path no longer reference the temporary PVC from the velero namespace?

6. What is the supported workaround for preserving original application NFS paths without manually copying data, recreating PVs, or using static provisioning for every PVC?

This is important for disaster recovery environments where NFS path consistency is required for storage administration, auditing, troubleshooting, cleanup, and source-to-target volume correlation.