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
Feedback on actual backup data I/O #1033
Comments
Thanks for raising this issue explicitly. I'm aware of the problem, and it'll be address when I come around to reworking the archiver code. I'll then build a new reporting framework so we can have better stats. |
Something similar to Obnam's summary would be nice:
|
This just came up in the IRC channel. I'm wondering if there's anything that can be put into place prior to a new reporting framework, but which the framework can take advantage of. |
It looks like all the interaction between restic and the backend happen through a Repository type: https://godoc.org/github.com/restic/restic/internal/restic#Repository I don't know the life cycle of a Repository but it seems reasonable to me that a single invocation of restic might talk to the same Repository for two or more logically different tasks (e.g. backup AND prune), even if that's not the norm. So as an interface, it makes sense to me that what we'd want are like a Session type, so that bw usage can be apportioned to the appropriate session. A couple ways to do this occur to me:
I'm leaning toward the last one myself. I don't think switching Session types midstream would buy us anything; just make a new Repository instead. Below the covers, all the Backends would need to be modified to use the Session to create custom net.Conn types. This is fairly trivial for the backends that are HTTP clients, since http.Transport has facilities for that, but it wouldn't shock me if there are less flexible backends. |
Er, that should read "toward the third one". |
I have a working implementation. It's a little rough though.
|
FYI, I'm currently reworking the archiver code, let's wait until that is done. |
This commit removes the bandwidth displayed during backup process. It is misleading and seldomly correct, because it's neither the "read bandwidth" (only for the very first backup) nor the "upload bandwidth". Many users are confused about (and rightly so), c.f. #1581, #1033, #1591 We'll eventually replace this display with something more relevant when #1494 is done.
Since restic 0.9.0 (?) when specifying |
Output of
restic version
How did you start restic exactly? (Include the complete command line)
What backend/server/service did you use?
S3
Expected behavior
Restic should output statistics about data actually sent (and possibly received) in addition to processed data. Could be live feedback, could be a summary (rsync style), could be both.
Example:
Actual behavior
Restic outputs progress based on data processed but lacks progress on data actually sent. When evaluating restic as a backup solution I had to do some third party monitoring to estimate the actual savings and eventual bandwidth cost. As it is it gives the initial impression it does a full backup every time.
Steps to reproduce the behavior
Do a backup.
The text was updated successfully, but these errors were encountered: