40 gig file Backup 400+gig in size

general discussion
1

I have a network of 15+ computers we are backing up. All windows clients use the cbt client 2.1.19-cbt
I have one of these windows clients that I am doing a daily file backup on these locations and a weekly image backup of whole system.

C:\Users\username\Favorites
C:\Users\username\Desktop
C:\Users\username\Emails
C:\Users\username\Documents
C:\Users\username\AppData\Local\Microsoft\Windows Live Mail
C\FTPFileUploader

Weekly image backup works great but on this system alone the 42.2 gigs contained in the above directories shows as 401.59 gig backup. Every day. The physical hard drive that this filesystem is on is only 232 gigs in size.

File backup takes around 16 hrs for that client.

here is log from that client showing yesterdays backup
Starting scheduled incremental file backup…
Change block tracking active on volume c:
Scanning for changed hard links on volume of “c:”…
Change block tracking active on volume e:
Scanning for changed hard links on volume of “e:”…
Indexing of “Favorites” done. 1 filesystem lookups 7 db lookups and 0 db updates
Indexing of “Desktop” done. 1 filesystem lookups 57 db lookups and 0 db updates
Indexing of “Emails” done. 1 filesystem lookups 2 db lookups and 0 db updates
Following symbolic link at “C:\Users\chip\Documents\My Music” to “C:\Users\chip\Music” confirms symlink backup target “.symlink_Music” to “C:\Users\chip\Music”
Following symbolic link at “C:\Users\chip\Documents\My Pictures” to “C:\Users\chip\Pictures” confirms symlink backup target “.symlink_Pictures” to “C:\Users\chip\Pictures”
Following symbolic link at “C:\Users\chip\Documents\My Videos” to “C:\Users\chip\Videos” confirms symlink backup target “.symlink_Videos” to “C:\Users\chip\Videos”
Indexing of “Documents” done. 2 filesystem lookups 2724 db lookups and 2 db updates
Indexing of “Windows Live Mail” done. 14 filesystem lookups 52 db lookups and 11 db updates
Indexing of “FTPFileUploader” done. 1 filesystem lookups 5 db lookups and 0 db updates
Brandan1: Loading file list…
Brandan1: Calculating file tree differences…
Brandan1: Creating snapshot…
Brandan1: Deleting files in snapshot… (85)
Brandan1: Deleting files in hash snapshot…(85)
Brandan1: Calculating tree difference size…
Brandan1: Linking unchanged and loading new files…
Waiting for file transfers…
Waiting for file hashing and copying threads…
Writing new file list…
All metadata was present
Transferred 401.653 GB - Average speed: 60.1001 MBit/s
Time taken for backing up client Brandan1: 16h 20m 42s
Backup succeeded

I am pretty confused on this issue and not sure what to do.
Server is verson UrBackup 2.2.11 running on Ubuntu 18.04 and the raid 10 that the backups are stored on is formatted as BTRFS. Client confirms that CBT is enabled on the partition that these files are being backed up from.
All other clients are backing up correctly except 1 that is windows 2003 R2 32bit I will address that in a separate post

2

I guess the easiest way to find out what it is loading is to look at the live log of the backup while it is running (on the server web interface).

3

I’m getting this with a Linux (Ubuntu) mail server… 8.19TB reported usage for that one client. Pretty impressive when it’s backing up to 2TB drives. All other clients show up as expected sizes (no others run Ubuntu - they’re all Debian, with one Windows 2008R2).

Has done that since the very first backup - where ~70GB of used space on the mail server showed as about 700GB used. I’ve just made a mental note to divide that specific server by 10. But it does bugger up the pie graph a bit :stuck_out_tongue:

4

ok I will take a look at server log and see what it shows and report back.

As to the size difference in reporting I figured that was a combination of compression and using cbt that reported full size, not size on disk. I have the same issue. I have a 15 tb raid 10 array that data is stored on that is BTRFS. Actually size on disk according to filesystem with df -h is about 7tb but in the urbackup interface it is reporting 30TB in size backed up.