OADP 1.3 CSI restore compatibility boundary when original StorageClass is unavailable
0 reputation · 21 Jul 2022, 20:38 UTC
Context
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.
Constraint
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.
Open decision
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?
