Question
OADP 1.3 CSI restore compatibility boundary when original StorageClass is unavailable
Rahul Atlas
0 reputation · 21 Jul 2022, 20:38 UTC
101.4K views
Loading…
0 reputation · 21 Jul 2022, 20:38 UTC
OpenShift API for Data Protection (OADP) 1.3 and later uses the Velero CSI plugin to back up and restore persistent volumes through CSI volume snapshots. The restore path expects the original VolumeSnapshotClass and its backing storage class to exist in the target cluster.
When the original StorageClass is absent — for example during cross-cloud disaster recovery or storage migration — Velero does not remap the VolumeSnapshotContent to a replacement class. The restore fails with "storage class not found" errors, and the resulting PVC remains in Pending state. No built-in flag or ConfigMap currently automates this translation.
The project has not settled on whether to introduce a restore-time StorageClass mapping mechanism (such as a ConfigMap or CLI flag) or to keep the behavior explicit to avoid silent data-placement changes. CSI driver capabilities also vary: some support cross-zone snapshot restore, others do not.
Should OADP provide a supported StorageClass mapping feature for CSI restores, or is manual VolumeSnapshotContent editing the intended workflow? How should hook failures during a partial restore be surfaced when no automatic rollback occurs? What verification steps are recommended to confirm data integrity after a cross-storage-class restore?
32775 reputation · 22 Jul 2022, 01:37 UTC
As of OADP 1.3, there is no supported restore-time StorageClass mapping mechanism for CSI snapshot restores. The Velero CSI plugin binds the restored PVC to the StorageClass recorded in the snapshot path. If that class is missing in the target cluster, the restore fails or leaves the PVC in Pending. The de facto intended workflow today is manual: recreate a compatible StorageClass with the same name (matching provisioner and parameters) before the restore, or patch the restored PVC/PV specs afterward. Cross-driver snapshot restore generally does not work — snapshot handles are provisioner-specific.
Velero's non-CSI restore path supports resource modifiers and storage-class mapping via ConfigMap, but the CSI plugin restores from VolumeSnapshotContent objects that embed the original storageClassName and driver name. The PVC created during restore references that class directly; Velero does not rewrite it. If the class is absent, the PVC cannot bind. Editing VolumeSnapshotContent or statically binding a pre-created PV bypasses safeguard checks and can produce a volume that binds but contains wrong or empty data if the snapshot handle is mismatched.
When a restore completes with hook failures, the Restore CR status shows PartiallyFailed with per-item errors in status.errors and status.warnings. Velero does not roll back already-restored resources. Operators must inspect velero restore logs <name> --details and the Restore CR to identify failed hooks, then manually clean up and re-run the restore. A restore marked Completed can still have hook failures logged as warnings — check both the phase and the logs.
redhatoc get pvc -n <ns> — must be Bound, not Pending with \"storageclass not found\" events.VolumeSnapshotContent.snapshotHandle and driver name against the target cluster's CSI driver before any manual remap.Which CSI driver (provisioner name) created the original snapshots? Cross-driver snapshot restore is generally invalid; if the target cluster uses a different provisioner, you must use file-system backup (restic/kopia) instead of CSI snapshot reuse.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.