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

vmware-tanzu / velero

Backup and migrate Kubernetes applications and their persistent volumes

https://velero.io

Apache License 2.0

8.71k stars 1.4k forks source link

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

Closed reasonerjt closed 7 months ago

reasonerjt commented 1 year ago

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 commented 1 year ago

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

allenxu404 commented 12 months ago

The design https://github.com/vmware-tanzu/velero/pull/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 commented 11 months ago

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.