Wrong Backup size reported in "Backups" section

Server
1

Hi, i’ve noticed a huge discrepancy between the “Backup File” view and the disk usage.
Here is my setup:
Nas arm with debian os, urbackup server and client on same machine. The machine is called “Threepwood” on urbackup.
The FULL disk backup is listed as ~5MB, while should be ~95 gigabytes.
On the Statistics page i can see that a lot of space is being taken from the linux client that is backing up nas folders. All data seems to be there.
I have other windows clients that aren’t exposing that problem.

Here are some other technical info:
uname -a
Linux Threepwood 4.9.0-8-marvell #1 Debian 4.9.144-3.1 (2019-02-19) armv5tel GNU/Linux
UrBackup 2.3.8

cat /proc/cpuinfo
processor : 0
model name : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS : 1191.93
Features : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part : 0x131
CPU revision : 1

Hardware : Marvell Kirkwood (Flattened Device Tree)
Revision : 0000
Serial : 0000000000000000

Disk statistics view

1
1843×326 24.8 KB

Client backups; as you can see, the full backup size is listed as 3-5MB, while is 95GB.
2
21180×746 80 KB

3
31195×832 84.2 KB

2

Lots of other posts dealing with this, and cause is from multiple issues

3

Yes, i’ve seen that there are old threads (year ago) that mimics this issue.
There is a basic difference: in that threads, the difference is relatively marginal;
here there is a huge difference.
I have compiled urbackup from source, so i’ll be able to conduct some code tests, applying patches if needed.
Does anybody know if that size is computed from clientside? that could explain why windows clients shows ok and linux not.

4

As long as you’re looking at changes, how about computing several numbers:

  1. The size of the backed-up files (BUF) if they were all restored to a blank device.
  2. The storage actually used for the backup, including new files and link + database overhead.
  3. The change in BUF (higher or lower) since the previous backup. If this is computed as needed then deleted backups are automatically handled, but you’ll lose the chance to separately count deleted, added, or changed files.
  4. The amount of data transferred during the backup session, including hashes and control traffic. Optional to guess Ethernet & TCP/IP overhead, which inflates the size of small messages disproportionately.
  5. Clock time the Client was busy and time the Server was busy with this backup. Server threads continue after the Client is finished.
  6. Bonus: Server CPU time for this backup, excluding time spent servicing other clients but including I/O wait time, as an indicator of server resources used.

Some of these are already present, but it isn’t always clear what is being measured.