mirror of
https://github.com/vmware-tanzu/velero.git
synced 2026-07-26 01:53:09 +00:00
Christian SchlichtherleandLyndon-Li
246dbc3c33
When a backup tarball incidentally contains DataUpload CRs that belong to a different backup (common when a schedule includes the velero namespace where DataUploads live), DataUploadDeleteAction.Execute used to create a "<du-name>-info" ConfigMap labeled with the *executing* backup's name instead of the DataUpload's true owning backup. The ConfigMap is created with Create-only semantics, so the wrong label is never corrected. deleteMovedSnapshots in the backup-deletion controller looks up these ConfigMaps by velero.io/backup-name to discover which Kopia snapshots to delete. With the wrong label, the real owning backup's expiry pass finds no ConfigMaps for its DataUploads and silently leaves their Kopia snapshots in object storage, leaking data over time. Fix: in DataUploadDeleteAction.Execute, compare the DataUpload's velero.io/backup-name label against input.Backup.Name (using label.GetValidName to handle DNS-1035 truncation for long backup names). If the label is present and differs, skip the DataUpload entirely; this prevents the over-eager creation of misnamed ConfigMaps without changing behavior for DataUploads that legitimately belong to the executing backup, or for legacy DataUploads with no backup-name label. Refs: #9472 Signed-off-by: Christian Schlichtherle <cs@bsure-analytics.de>