After running a check on my freshly installed web-ui, I can see the current size/number of revisions for each repository:
Nice! But when I click on the “Checked” link next to the scheduled check job (this one:
Then I see that a comprehensive table with the size of each revision (and more) so that I wonder how I can get this historical information displayed in the graph. Is it possble?
If you want to see revisions over time, then I think you just need to keep running daily check jobs
I don’t think the web UI assumes that the number of revisions currently in the storage for some past date is the same thing as how many actually existed on that past date. Because of pruning, trying to use what’s currently in the storage for historical data isn’t necessarily accurate.
This is one of my small gripes about the Web UI… the graphs are nice 'an all, but they’re only pulling small pieces of information out of the check run - and if you skip those check runs, the data goes missing in those graphs - there are gaps.
The current graphs are useful, to an extent, but I’d like to see more graphs pertaining to the insights that check -tabular actually provides. i.e. live information related to the new and unique chunks that go into the incremental backups on a particular storage.
I don’t know the best way to represent this information, but there is a good deal of information in those live stats. And even though they would constantly change after new backups and prunes, seeing those graphs/statistics change along with it would be helpful in understanding how efficient the de-duplication is working in a Duplicacy storage.
I wonder if a TreeSize/KDirStat/WinDirStat/WizTree diagram could be generated, showing the chunk usage of all snapshots with different shades representing age and various colours representing shared chunks or chunks unique to each snapshot.
Okay, that makes sense. To be more precise: it makes sense that we can’t extrapolate the total storage that was used in the past from today’s data. But the size of individual revisions (snapshots?) doesn’t change, right? So it should be quite possible to show how the size of a snapshot (backup?) developed over time, based on current data. The only thing that will change if revisions are deleted is the resolution of the graph (i.e. there will be fewer data points) but the data points themselves will always be accurate, right?
I think it would be valuable to have this kund of graph.
Now back to the total storage size, which is, of course, also valuable to see but as you rightly point out, we cannot pretend that what we get from a current check command is an accurate representation of actual storage size historically. Thus, it should not be the same graph. But wouldn’t it make sense to show this data in a separate graph (or rather: a separate line in the same graph)?
Reason 1: If you don’t have “real” historial data, it is better than nothing. (And if you never pruned, it is even accurate.)
Reason 2: If you do have “real” historical data, the second line (based on current data) will give you a nice comparison to see the effects of pruning.
And I guess @Droolio is offering a third reason (de-duplication efficiency) that I hadn’t thought of:
Or, well, as I think about it that seems to be yet another graph. In any case, the bottom line is:
The size of individual revisions isn’t shown anywhere, though, is it?
I think this assumes that users are only backing up once per day. If I create 2 revisions today, each with 50GB of unique data, a check job today would show I’m using 100GB. Let’s say I prune one of those revisions before I ran my first check job tomorrow. Now with your suggestion it’ll look like my backup was only using 50GB today instead of 100GB.