Fail get DataUploadResult for restore - multiple DataUpload result cms found #7057
Comments
|
@zanderson-aim |
Please also check the PVCs |
This results in about 9000 lines which look like this |
I deleted them from the live system to test the restore, so they don't currently exist any more. |
|
@zanderson-aim Are there running data mover restores at the time you run |
No currently nothing running |
|
@zanderson-aim |
|
@zanderson-aim
2 may be very large, not sure if you can make it, but let's see it. |
|
|
@zanderson-aim Most resources in the |
|
Makes sense, I will update the job and test again. I guess these makes all the "old" backups that include velero already unrestorable? |
yes |
|
If this is true, can we change the default to permanently exclude the velero namespace, or even better, maybe, always exclude velero resources by default? |
|
I can confirm it worked after I excluded the namespace. |
|
I did tried some older backups before 1.12 and they worked fine with the namespace included. Must be something with changes in 1.12. |
OK, I will keep this issue open and see if we can make some improvement around DataUpload CRs. |
|
@shubham-pampattiwar @sseago We probably want to make sure that this is documented in our downstream docs |
|
For info I had exactly the same issue with v.12.1, restore of snapshots (Kopia to Minio) were failing when velero was included in the backup. I excluded all kube- namespaces but left velero in. New backups without velero namespace restore fine. |
|
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days. If a Velero team member has requested log or more information, please provide the output of the shared commands. |
|
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days. If a Velero team member has requested log or more information, please provide the output of the shared commands. |
|
I have the same issue. I solved this by cleaning the s3 bucket, installing the Velero doing the backup again, and restoring. Kopia might get confused when the bucket has multiple backups. |
|
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days. If a Velero team member has requested log or more information, please provide the output of the shared commands. |
|
Facing same issue when trying to restore with velero version 1.14 |
|
I faced the same issue with For context: I deleted my postgres namespace and wanted to restore it with Fail to restore from DataUploadResult: fail get DataUploadResult for restore: 2024-11-09-1-20241110161813: multiple DataUpload result cms found with labels velero.io/pvc-namespace-name=postgres.postgres-volume-claim,velero.io/restore-uid=b9cb9487-31ee-4434-93f1-40fd076e13d6,velero.io/resource-usage=DataUpload I found this issue after googling and panicked after seeing #7057 (comment) Thanks to https://cloudcasa.io/blog/how-to-restore-velero-backup-data-without-velero/ this is how I fixed my issue:
This fixed the issue for me. I hope this helps someone too! |
|
Had the same |
|
Also facing this issue with a scheduled backups. Performing a manual backup and restoring from it works perfectly fine. This seems like a major bug is scheduled backups are not usable. Issue happens on 1.14.0, 1.14.1, 1.15.0 |
|
Also facing the same issue in restore with csi snapshot data mover |
|
i have the same issue when working with CSI and datamover. i tried to backup a namespace in clusterA and restore it in clusterB using velero and longhorn. the backup worked. but when i try to restore on the clusterB i got these issues: |
What steps did you take and what happened:
When trying to restore a backup I get the following error:
The restore command
velero restore create --from-backup velero-imdc-20231105205455 --include-namespaces rc-aimit-io --include-resources persistentvolumeclaims,persistentvolumes,datauploadWhat did you expect to happen:
The PV/PVCs would be restored.
The following information will help us better understand what's going on:
bundle-2023-11-05-23-09-42.tar.gz
Anything else you would like to add:
I was able to confirm the data is there by manually mounting the bucket using Kopia tools and restoring the files from there.
Environment:
velero version):velero client config get features):features: <NOT SET>kubectl version):The text was updated successfully, but these errors were encountered: