The bahavior is likely driven from the fact that files are not scanned for changes in their entirety before the backup. As the backup runs, more files might be added for backup, which causes the estimates to adjust. The final size will not be reported until the backup completes (or some time close to that point).

Indeed. As the backup neared completion, the total file size incremented up to a value slightly higher than what the OS reported and the progress bar jumped up to match what was being reported at the right-hand end of the bar. But the value for size in the Info section remained out of whack until the very last. I don't think any harm was done.

This seems cosmetic to me. But it is a UX thing. Maybe a little better labeling would help. And progress feedback becomes kind of important in a SOHO environment when you are dealing with biggish backups and smallish upbound bandwidth.

Maybe CBB should invest in some UI tweaks in the next version cycle. Don't get me wrong, this isn't (to me) something that would drive a decision on whether or not to use the product. It just looks a little discombobulated.

I don't disagree with what you're saying. It's a bit of a "Is some information better than none?" We could simply run the backup and report exactly which file(s) are in-process and leave off the estimates. But I know we'd get complaints that some would want to know how long the backup is going to take. We also have customers asking for a full scan at the start to know more precisely what and how much data will be backed up, and I am pretty *certain* that if we did that, many customers would not like the extra up-front processing time.

I know we have an open item to try and improve the information during backup / restore and I will add your comments to the internal thread for discussion.

Thanks for your feedback.

Sounds good.

Progress feedback is really important, especially where cloud storage is involved. I don't suppose it needs to be terribly precise. I've seen a bunch of backup programs with more or less the same problem: people try to parse out precise information about how far along the backup is from whatever is there, no matter how imprecise it might be. Human nature, I guess. They need to know what they need to know. Thing is, I haven't seen anybody do a great job of making clear the precision or lack of it in the available information. So, viewed in that light, you've got a clear playing field.

I realize this is an old thread, but it's still pertinent.

I'm seeing similar behaviour. The problem is that there just isn't any indication what the progress bar and its percentage is supposed to represent. In the example above, it seems the true % complete is closer to the 86% (28.55 / 32.83) so why not just have the progress bar represent that %?

If not that, then what does the progress bar represent at a glance?