Incrementals doing full backups

For some reason one of my clients is doing big full backups on incrementals.
(see image below)
they still say "Incrementals = YES " on the Web GUI, but every 5 hours the used space keeps increasing.
Im 100% that data is not changing.
How do I troubleshoot this? it is eating my HDD space.

1 Like

Even if it was changing the probability that the size would always be the same would be so low that it would likely never happen.

There is something going on, but I dont know what.
Its been like that since May 7 when I did the first backup.
All other clients on this installation are just fine, doing incrementals and they should.
I have not clue on what is happening here.

Have you uninstalled and reinstalled the client yet?

Nope, but I could, i guess.
Let me try that

I just tried it, removed the UrBackup, and then reinstalled it again.
Same thing, incremental keeps using lots of HDD space.
Images below showing the incremental backup at 21:32 with the same size that its been reported for the last few days, and also an image with the logs from this last backup. Notice the backup time was 34 min, and this client is on the internet, sitting on a 1.5 Mbits uplink. so, basically 19.5 GB would have taken more than 30 days to upload, not 34 minutes. So, Im assuming whatever is happening, it happens in the server, and not on the client, because the client is not uploading those 19.5 GB for sure, I was looking the “Activities”, and it took those 34 minutes to completed.

Ops, I found another client on the same server doing the same thing, incrementals are eating HDD space, see screenshot below. And Im sure that user is not modifying 6 GB every 5 hours, those are old Video files).


When i have issues like this i login on the urbackup server in ssh then use “ncdu /urbackupfolder/” or “du -hs /urbackupfolder/*” if ncdu isn not availlable
Then i inspect the actual on disk usage. Sometime i end up adding some folder to ignore during backups.
Look in details as i remember ncdu show “@” for soft link and “H” for hard link, theses dont consume additional space.

I think the transfer/used size shown depends on which web UI part you look at.
It display the on disk usage or the actually transferred size or the size which would have been transferred if you were in raw mode transfert instead of hash mode.

The logs says it actually transferred 21 MB in 34min, so i guess that 's the time for hashing everything, comparing the hashes on the server then transfering a few files.

Update: I realized that those two clients have Outlook with personal mailboxes, and they have PST files that are “touched” all the time, so I thought that might have to do with this.
Therefore, I added an exception for *.pst and now the incrementals has regular size. They are tiny, just with the small changes on other documents etc.
I did the same on both clients, and it works fine.

Soooo, there is something going on backing up PST that are in use, and I need to back those as well.
I read on this forum and there were some threads about it, but I dont know exactly how to fix it in my case.
Im running UrBackup server on a FreeNAS jail.

Any advise for me?

Currently only Linux btrfs can store such differences directly (reflink support).

With ZFS you’d have to rely on ZFS block level dedup. Do some research before you enable that.

That might fix the utilization in the backend.
But the web GUI will still show that a lot of space is consumed on each incremental right ? And the statistics will also show that correct ?
I think that will get users confused and will make the reports unusable I think.
Is there any other way to deal with this ?

One more thing, the incrementals dont take long, they take just a couple of minutes, sometimes 10 minutes (those two clients are on the Internet and their uplink bandwidth is 1.5 Mbit , obviously the clients are not transferring the whole PST on each incremental.), but the incremental sizes on the gui are 6 GB on one client and more than 19 GB on the other,
Something on the UrBackup server side is causing to show a big size every time.
Am I explaining this properly? the incrementals are taking a lot of space, I think due to PST being used, but the actual backup time is very short so I think the client is doing what is supposed to be done and the problem might be on the server side.

I’ve noticed a similar issue. What happens is that URBackup transfers only the changes in Internet mode but seems to save a copy of the entire file (because it has changed) to keep the backup image consistent otherwise you’d have some custom format that keeps track of changes.

It’s not a huge problem, if anything, you can probably just exclude that file (since it’s a copy of a mailbox that’s supposedly somewhere else).