Wenkai Yin(尹文开)
Wenkai Yin(尹文开)
It's better that we can root cause this issue. If patching call could cause the conflict error the retrying should be applied to all patches.
> Velero can patch the "missing" optional field during the transitionary period on all resources then the next version can have it be set to required. @kaovilai Could you explain...
See errors in the Velero server log: ``` time="2025-08-14T08:32:12Z" level=error msg="backup failed" backuprequest=velero/velero-daily-20250814082854 controller=backup error="rpc error: code = Unknown desc = error putting object backups/velero-daily-20250814082854/velero-daily-20250814082854.tar.gz: operation error S3: PutObject, https...
This would be easier to cancel the in-progress backup in https://github.com/vmware-tanzu/velero/issues/4772
The backup repository isn't cleaned up immediately when one backup is deleted, the clean up is done during the maintenance job, see the explanation here https://velero.io/docs/v1.14/file-system-backup/#backup-deletion
How many new backups do you create every day? What's the TTL of them? Does the size of the workload data you backed up increase every day? What's the frequency...
Maybe we can use the [API Aggregation layer](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) to achieve this.