An in-place restore of a VMDisk that still exists reports Succeeded, but the disk data is not restored. Velero cannot replace the live PVC, logs a warning, and the RestoreJob never shows it.
The restore warning from Velero:
tenant-root: PersistentVolumeClaim "vm-disk-vdtest" is invalid: spec: Forbidden: spec is immutable after creation except resources.requests and volumeAttributesClassName for bound claims
After the RestoreJob finished, the PVC had the same age and the same PV as before, so nothing was replaced.
The cause looks like the pre-restore step. prepareForRestore suspends the HelmReleases, renames the original PVC and deletes the DataVolumes, but it takes the disk list from the underlying resources recorded at backup time. collectUnderlyingResources returns nil for anything that is not a VMInstance, so for a VMDisk none of that preparation runs and Velero restores on top of the existing objects.
The backup itself is fine. I deleted the VMDisk, ran a RestoreJob from the same backup, and the sha256 of the whole block device matched the one taken before the backup. Tested on v1.7.0-alpha.3 with the default BackupClass.
I'd expect one of two things: the VMDisk gets the same in-place preparation as a VMInstance disk, or the RestoreJob fails when Velero reports it could not restore the PVC. #4428 is about restore-to-copy for VMDisk, and this is the in-place path.
An in-place restore of a VMDisk that still exists reports
Succeeded, but the disk data is not restored. Velero cannot replace the live PVC, logs a warning, and the RestoreJob never shows it.The restore warning from Velero:
After the RestoreJob finished, the PVC had the same age and the same PV as before, so nothing was replaced.
The cause looks like the pre-restore step.
prepareForRestoresuspends the HelmReleases, renames the original PVC and deletes the DataVolumes, but it takes the disk list from the underlying resources recorded at backup time.collectUnderlyingResourcesreturns nil for anything that is not a VMInstance, so for a VMDisk none of that preparation runs and Velero restores on top of the existing objects.The backup itself is fine. I deleted the VMDisk, ran a RestoreJob from the same backup, and the sha256 of the whole block device matched the one taken before the backup. Tested on v1.7.0-alpha.3 with the default BackupClass.
I'd expect one of two things: the VMDisk gets the same in-place preparation as a VMInstance disk, or the RestoreJob fails when Velero reports it could not restore the PVC. #4428 is about restore-to-copy for VMDisk, and this is the in-place path.