Hello all, I am not sure what is going on with one of my clients backups. The storage usage is getting ridiculously high and I am not sure what to do about it. I only have 5-6 users setup currently and it is at nearly 1tb, it does not seem as if my settings are taking effect or matter at all. I am currently backing up C:\Users, and I had symbolic links disabled because I saw it was taking “All Users” and for some reason redirecting it to C:\Programdata, yet with that off, it still is doing it.
As you can see in the pics below, it has been steadily rising at a high rate from one specific user. I tried to disable .pst and .ost as part of the backups, but in the 3rd image you can see that it just keeps doing it, my exclude portion looks as follows ".pst,.ost, *ProgramData*, *\All Users*, *\AppData*, *\Temp*, *\Public*, *\Default*". In the 4th pic you can see that the pst file is still being backed up daily as well. Even though ost and pst, as well as AppData is excluded. It seems as anything I do does not matter.
If anyone has any ideas, I would greatly appreciate it.
Thanks!
*Edt, it only let me post 2 links since I am new, so I just put the most important ones.
You might want to try restarting the client on that specific machine. That might clear up the .ost/.pst files still backing up.
Have you checked your day / time settings for both backup and cleanup? I noticed, by default, the cleanup times (3-4 am) were during the backup window I setup (1 am to 5 am). I am not sure if that would cause this, but it is worth checking really quick.
Thank you much for the reply, I know that her PC has been restarted several
times since the installation (back in July), so I am not quite sure what
else to try for her individually. Will reinstalling the client on that same
PC automatically associate her backups with her client again since it is
the same PC hostname?
I will check my cleanup and backup times, everything is default though, I
have not changed any of those settings.
Not sure what the default backup time is. (1-7/0-24 ?) [Mine has been manually changed.]
If that client has been restarted since the changes were made, then it probably is something else, like:
General > Permissions > “Allow client-side changing of settings” – make changes via client
Client Settings > “Separate settings for this client” – make changes via server, client changes above will override this!
So maybe something like above, where changes set via the client are overriding the values set via the server?
As for deleting the client and re-installing it. It may remove all settings, including the server information. However, depending on setup, you might be able to download a (PC) client specific client (installer application) to install and restore the same settings used prior.
Status > Download Client for (OS) > “Client Host Name”
I have a very, very similar scenario, creating a similar graph as shown above… maybe see whether the description below also applies to your backups:
Across each of my four clients’ backups (note: I deactivated image backups) I’ve noticed the same pattern:
an initial full backup which has a similar size as the actual file base
all subsequent incremental backups have the exact same size (about a third of the original - vastly bigger than any potential changes to the file base, though…)
selecting full backups subsequently creates new instances of backups with the exact same size as the incremental backups.
Not all your excluded directories are correct; meaning you have Program Data\ and \AppData\ (It probably works, but my OCD is kicking in looking at it). I would say fix those to match all the way across to prevent that from biting you if that is an issue.
IT IS THE WRONG SEPARATORS. I don’t mean to shove it down your throat or call you out on it in a harsh way, but (,) commas are not the correct separators. (;) semi-colons are the correct separators. I’ve done the same mistake about five times when I had to remake my urbackup server, and each time it did not work until I used a semi-colon as my separator.
There is probably something else, but that is the first thing that jumps out at me.
