The information of PV is lost if it's restored via podvolume path

[reasonerjt]

If a workload's PV is patched so its reclaim policy is different from what is defined in the storageclass

k get sc
NAME            PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
gp2 (default)   kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  167d

k patch pv pvc-xxxxx -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"

Then if I use velero to backup the workload via podvolume and restore it, the new PV is created after the restore will have the reclaim policy of the storageclass, instead of the patched value.

[reasonerjt]

We should also handle the case when the PV is restored via CSI plugin with/without datamover involved.

[allenxu404]

The design #7070 introduces a new structure called VolumeInfo which includes the following fields:

• BackupMethod: this field indicates the method used to back up the PV.
• PVCName: this field indicates the PV's corresponding PVC.
• PVInfo: this field stores the PV's manifest.

By utilizing the VolumeInfo structure, we can effectively gather all the PVs which are not skipped (by checking the existance of its bound PVC), and are dynamically provided (by checking the field BackupMethod) during the restore. Subsequently, we can patch these new PVs with the manifest of the old PVs by utilizing the PVInfo field.

[reasonerjt]

To make sure the PVs are patched in case both of with or without aync operations, we'll need to introduce a new phase of restore CR.
Per discussion we propose to defer this issue.