Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add disabled PV re-provisioning by StorageClasses option on restore #8287

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

clcondorcet
Copy link

@clcondorcet clcondorcet commented Oct 11, 2024

Thank you for contributing to Velero!

Please add a summary of your change

This PR addresses a specific disaster recovery use case:

When restoring a cluster after a disaster, PV may or may not have associated snapshots.
However, the underlying volumes from the CSI driver remain intact. I want to relink PVs with existing volumes instead of creating new ones. This PR propose a way to retrieve existing volumes without recreating them.

In my case, the PV has a Reclaim Policy Delete enforced by the StorageClass.
Velero currently does not restore PVs with a Delete policy and no snapshots, which makes sense for regular backup/restore scenarios but can be limiting in disaster recovery situations.

Proposed solution:

This PR introduces a new feature that allows Velero to restore PVs as-is when they meet the following conditions:

  • No snapshot is available.
  • The PV's StorageClass is listed in a newly introduced field in the CRD specifications called disabledPVReprovisioningStorageClasses.

This ensures that Velero can relink the PV to its existing volume and rebind the associated PVC, similar to how it restores PVs with a Reclaim Policy Retain.

Implementation Details:

This solution uses StorageClass names rather than PV names, as some CSI drivers generate random PV names.
Also, using StorageClass makes sense in this context because PVs sharing the same StorageClass generally have similar configurations.

This solution does not bypass snapshots. If snapshots are available, restoring from them is preferred as it is generally more reliable. However, this is open for discussion.

Does your change fix a particular issue?

There is no direct issue but I found two issues that are close to what I've added.

Please indicate you've done the following:

Signed-off-by: Clément Rostagni <clement.rostagni@s3ns.io>
Signed-off-by: Clément Rostagni <clement.rostagni@s3ns.io>
@BarthV
Copy link

BarthV commented Oct 11, 2024

Awesome! We are really interested in this annotation in order to recover all our existing volumes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants