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

Restore of existing resources is too slow #6845

Closed
sseago opened this issue Sep 19, 2023 · 0 comments
Closed

Restore of existing resources is too slow #6845

sseago opened this issue Sep 19, 2023 · 0 comments
Assignees
Milestone

Comments

@sseago
Copy link
Collaborator

sseago commented Sep 19, 2023

What steps did you take and what happened:
Restore of existing resources is too slow

In a test scenario with 31k Secrets in a namespace backup, restore takes longer when resources already exist:
restore into new namespace: 52 minutes
restore with all resources existing (existingResourcePolicy=none): 52 minutes
restore with all resources existing (existinResourcePolicy=update): 1 hour, 18 minutes

By using an informer cache with the dynamic client, we are able to cut restore time in half for the second case, and drop 2/3 of the restore time in the third case:
restore into new namespace: 52 minutes
restore with all resources existing (existingResourcePolicy=none): 26 minutes
restore with all resources existing (existinResourcePolicy=update): 26 minutes

This should be a configurable server/install option, enabled by default, as there may be certain edge cases where use of the informers results in Velero using too much memory.

Associated implementation is here: #6723

Environment:

  • Velero version (use velero version):
  • Velero features (use velero client config get features):
  • Kubernetes version (use kubectl version):
  • Kubernetes installer & version:
  • Cloud provider or hardware configuration:
  • OS (e.g. from /etc/os-release):

Vote on this issue!

This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

  • 👍 for "I would like to see this bug fixed as soon as possible"
  • 👎 for "There are more important bugs to focus on right now"
@sseago sseago self-assigned this Sep 19, 2023
@sseago sseago added the 1.13-candidate issue/pr that should be considered to target v1.13 minor release label Sep 19, 2023
@Lyndon-Li Lyndon-Li removed the 1.13-candidate issue/pr that should be considered to target v1.13 minor release label Sep 20, 2023
@Lyndon-Li Lyndon-Li added this to the v1.13 milestone Sep 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants