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 progress #21
Comments
Idea: store per-restore log file to ???. Add |
We now have the Pulling over some details from the comments on #20, it would be possible to store the number of items in a backup on the backup metadata, which would help with restoring when the entire backup is being restored, though doing a selective restore would still need to do some filtering. I like the idea of some generic 'progress' struct that applies to both backups and restores. |
Is it worth considering using Kubernetes |
That would make sense to me. A restore/backup could generate an Depending on how much information we want to report and when in the restore process, we could potentially used the |
It wouldn't work quite like that. The events could contain data such as An alternative that doesn't use events is to periodically update some field(s) on the restore's |
Is the I don't think we should store an explicit list for progress for the exact reason you mentioned. |
Adding a suggestion to this issue. Can the "ark get restore " command output that a non kube-system namespace did not restore because the namespace already existed and contained the pods to be restored? |
@jhamilton1 we wouldn't show that in |
Revert "Fixes logger configuration for restore plugins"
Similar to #20, do something similar to periodically update the progress of a restore.
The text was updated successfully, but these errors were encountered: