Skip to content

restore: Add progress bar to 'restore --verify'#4989

Merged
MichaelEischer merged 1 commit intorestic:masterfrom
plant99:progress-bar-for-restore-verify
Aug 15, 2024
Merged

restore: Add progress bar to 'restore --verify'#4989
MichaelEischer merged 1 commit intorestic:masterfrom
plant99:progress-bar-for-restore-verify

Conversation

@plant99
Copy link
Copy Markdown
Contributor

@plant99 plant99 commented Aug 8, 2024

What does this PR change? What problem does it solve?

This MR introduces a progress bar to the restic restore --verify flow when verify is in-progress. Earlier, there was no output when files were being verified.

Was the change previously discussed in an issue or on the forum?

#4795

Checklist

  • I have read the contribution guidelines.
  • I have enabled maintainer edits.
  • I have added tests for all code changes.
  • I have added documentation for relevant changes (in the manual).
  • There's a new file in changelog/unreleased/ that describes the changes for our users (see template).
  • I have run gofmt on the code in all commits.
  • All commit messages are formatted in the same style as the other commits in the repo.
  • I'm done! This pull request is ready for review.

@plant99 plant99 force-pushed the progress-bar-for-restore-verify branch 4 times, most recently from 0f028fd to 32640eb Compare August 10, 2024 08:00
@plant99
Copy link
Copy Markdown
Contributor Author

plant99 commented Aug 10, 2024

@MichaelEischer please review :)

Before you do, please advise on the following:

  1. I tried to implement it the way LoadIndex shows progress.
  2. I think the actual restore progress bar which uses restoreui.NewProgress is better, and better compatible with the --json flag.
  3. Do you think the way I've implemented now is enough, or should I try doing 2? The change if involving restoreui.NewProgress would have a larger footprint, and thus I have avoided it for now.

Copy link
Copy Markdown
Member

@MichaelEischer MichaelEischer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

3. Do you think the way I've implemented now is enough, or should I try doing 2? The change if involving restoreui.NewProgress would have a larger footprint, and thus I have avoided it for now.

The answer depends on whether we want the progress bar to also work for JSON or not. For just text output the current approach would be good enough.

To add JSON support, we essentially have two options. We could extend newTerminalProgressMax to actually support JSON progress bars (maybe with a format similar to progress_percent from borgbackup). The other option would be to extend the restore progress UI. But that has the big downside of requiring yet another handcrafted progress implementation.

So I'm leaning towards starting with newTerminalProgressMax and separately adding JSON support.

@plant99 plant99 force-pushed the progress-bar-for-restore-verify branch from 32640eb to 82dad5b Compare August 11, 2024 06:33
@plant99
Copy link
Copy Markdown
Contributor Author

plant99 commented Aug 11, 2024

Thanks @MichaelEischer for the review and the feedback on the implementation

  1. I've made the changes you suggested in this PR
  2. I'll also make a draft on adding JSON support to newTerminalProgressMax, I'll make an issue about this soon.

Copy link
Copy Markdown
Member

@MichaelEischer MichaelEischer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just had another look at how the maximum for the progress bar is determined and noticed that the current approach can't work, see below for details. No idea how I've missed that yesterday.

)

if p != nil {
numFilesVerified := uint64(res.sn.Summary.TotalFilesProcessed)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just had another look and we'll need a different way to determine the number of files to verify. Just restore the same snapshot twice, then you'll end up with something like the following:

verifying files in output
[0:00] 0.00%  0 / 1 files verified
finished verifying 0 files in output (took 0s)

This is rather confusing as the progress will never reach 100% in most cases. Or even worse, just restore an old snapshot without that metadata and restic would just crash.

What could work is the following. In RestoreTo there's a res.trackFile(location, updateMetadataOnly) call. At that place the restorer could also count all files that are not updateMetadataOnly updates. Then RestoreTo could return that number similar to VerifyFiles.

That will also remove the hacks that were necessary to make the tests work.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the catching this, and the guidance!

I've updated the code as per your suggestions.

Please review again when you have the time :)

@plant99 plant99 force-pushed the progress-bar-for-restore-verify branch 2 times, most recently from 5f64cc2 to c9a5594 Compare August 11, 2024 20:12
@plant99 plant99 force-pushed the progress-bar-for-restore-verify branch from c9a5594 to f1407af Compare August 11, 2024 20:27
@plant99 plant99 requested a review from MichaelEischer August 12, 2024 19:29
Copy link
Copy Markdown
Member

@MichaelEischer MichaelEischer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks!

@MichaelEischer MichaelEischer added this pull request to the merge queue Aug 15, 2024
Merged via the queue into restic:master with commit 36b5580 Aug 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants