You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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"
The text was updated successfully, but these errors were encountered:
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
):velero client config get features
):kubectl version
):/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.
The text was updated successfully, but these errors were encountered: