Undefined Description of problem:
PodVolumeRestore CR status gets modified after restore is marked as completed. This causing lot of automation to fail. Attached CR status output below, refer to completionTimeStamp.
Restore status :-
status: completionTimestamp: "2025-10-27T08:13:54Z" hookStatus: {} phase: Completed progress: itemsRestored: 14 totalItems: 14 startTimestamp: "2025-10-27T08:13:35Z" warnings: 1
PodVolumeRestore status:-
status: acceptedTimestamp: "2025-10-27T08:13:48Z" completionTimestamp: "2025-10-27T08:14:02Z" node: ip-192-168-52-54.ec2.internal phase: Completed progress: bytesDone: 104857640 totalBytes: 104857640 startTimestamp: "2025-10-27T08:13:55Z"
Version-Release number of selected component (if applicable):
Velero 1.1.7.0
How reproducible:
Always
Steps to Reproduce:
1. Deploy an application having multiple PVC
2. Trigger fileSystem backup with kopia. Wait until its get completed
3. Remove app namespace and trigger restore. Observe the restore and PodVolumeRestore completionTimestamp field.
Actual results:
Restore CR is marked as completed while PVR is still progress
Expected results:
Restore should be marked as completed after all PodVolumeRestores are completed.
Additional info:
$ oc get restore -o yaml -n velero test-restore apiVersion: velero.io/v1 kind: Restore metadata: creationTimestamp: "2025-10-27T08:13:35Z" finalizers: - restores.velero.io/external-resources-finalizer generation: 6 name: test-restore namespace: velero resourceVersion: "6786" uid: 932e6400-d9e0-4df8-bd04-329ffd7fdcee spec: backupName: test-backup excludedResources: - nodes - events - events.events.k8s.io - backups.velero.io - restores.velero.io - resticrepositories.velero.io - csinodes.storage.k8s.io - volumeattachments.storage.k8s.io - backuprepositories.velero.io itemOperationTimeout: 4h0m0s status: completionTimestamp: "2025-10-27T08:13:54Z" hookStatus: {} phase: Completed progress: itemsRestored: 14 totalItems: 14 startTimestamp: "2025-10-27T08:13:35Z" warnings: 1
$ oc get podvolumerestore -n velero test-restore-g4j8f -o yaml apiVersion: velero.io/v1 kind: PodVolumeRestore metadata: creationTimestamp: "2025-10-27T08:13:36Z" generateName: test-restore- generation: 6 labels: velero.io/pod-uid: 3ddc9879-cd05-49a1-a722-a0db6903f145 velero.io/pvc-uid: 8f7deb41-82d2-4587-b612-962938adfb8d velero.io/restore-name: test-restore velero.io/restore-uid: 932e6400-d9e0-4df8-bd04-329ffd7fdcee name: test-restore-g4j8f namespace: velero ownerReferences: - apiVersion: velero.io/v1 controller: true kind: Restore name: test-restore uid: 932e6400-d9e0-4df8-bd04-329ffd7fdcee resourceVersion: "6839" uid: 50c94750-a200-40ef-8b53-1803f42aefed spec: backupStorageLocation: default pod: kind: Pod name: mysql-588447b469-p27nk namespace: ocp-mysql uid: 3ddc9879-cd05-49a1-a722-a0db6903f145 repoIdentifier: "" snapshotID: 30b0522101c920b130feb0962badf224 sourceNamespace: ocp-mysql uploaderType: kopia volume: mysql-data1 status: acceptedTimestamp: "2025-10-27T08:13:48Z" completionTimestamp: "2025-10-27T08:14:02Z" node: ip-192-168-52-54.ec2.internal phase: Completed progress: bytesDone: 104857640 totalBytes: 104857640 startTimestamp: "2025-10-27T08:13:55Z"