More TotalSize reporting problems in API

[pwinkeler]

As I am working on calculating the total throughput of our collection of repositories I realize that I am completely blind to the amount of data that is transferred as part of failed job tasks. Please change this habit of doing so right away: even when a job task fails it is still very important to know how much data was transferred!

[pwinkeler]

For the job session tasks that result in Success or Warning, the TotalSize field is described as:

Code: Select all

Size of all restore points produced by the corresponding backup job

which already makes no sense as the field is returned as part of a session task, not the whole job. But when you look at the data, you can see that it represents the size of the VM's VMDKs, NOT the size of the restore point at all! I need the size of the restore points produced by the tasks in a job session

[veremin]

Take a look at /backupfiles/id resource, it should contain information you're after - BackupSize & DataSize.

The documentation will be corrected soon. By the way, you can submit feedback directly to the technical writers team, leveraging "send feedback" button (any page on the help center, bottom right).

Thanks.

[pwinkeler]

Thanks Vladimir - your suggestion of looking into the /backupfiles/id resource is one I pursued somewhat only to discover that for reverse incrementals for example it reports the size of the most recent file in the backup chain which is a full. Even if the amount of data transferred was actually a delta (which could be computed by looking at the delta just before it). But all this is silly. Plus, it doesn't tell me how much data was transferred in failed jobs. I am pretty sure, based on the detailed text logs I see on the proxies and agents that the information I need is available at some point. Just hoping it will make its way into the reporting database real soon as I very much need it.
And if it is going to be implemented, it would be crazy not to add in a reference to the target repository!

[veremin]

With reversed incremental mode the described behaviour looks expected. To get needed information you can either query the size of latest increment or subtract .vbk sizes (before and after the latest session). Thanks.