Hi everyone,
I’ve been running UrBackup for two or three years now.
I have almost 200 clients backup up, comprising of a mixture of local and internet clients.
I am using server version 2.3.0 beta, in a FreeNAS jail, and it runs better than all the previous versions.
I have noticed that the jail has grown massively over the years. It is not well over 4TB.
I had thought that maybe it was a massive database due to all the file hashes etc.
I just checked the database backup in the backup storage path and it’s about 60GB.
Could I have 4TB of logs or other temporary files?
You could try ncdu (ncdu-x /yourmountpoint/ )if that exists on freenas, but it may take long and exhaust the memory. Its kinda like windirstat in windows , but commandline.
But it may be the easiest t have a rought idea of where the space is gone.
As i said , you will get a rough idea, because it will be thrown off by urbackup space economy features and sparse files.
But if you have for example a big log file somewhere it will still be shown as a big file, so that still help.
Also maybe try stopping everything, and umount the volumes and check if there s not files in the mountpoint folders. Theses files get hidden when you mount something there and in the normal case you can not see them.
If you can’t umount the folders, you can also check that by using a bind mount (ex: if you mount sdb=/var/data in sda=/ , then bind mount / in /tmp/test, then look at /tmp/test/var/data/ , this will show files “overmounted” in /var/data/, that were actually using space in sda and not sdb)
Haa also maybe look for snapshots in lvm/btrfs/zfs
I suspect it is my /tmp folder. I’m calculating the size now.
I have been using the Temporary files as file backup buffer: and the same for image options for a long time. I used to have many seg faults with previous server versions and I think they have left behind many thousands of temporary files each time.
Is it safe to stop the server process and flush out the /tmp folder?
I’m emptying it now but it’s taking a very long time. Will report back.
After about an hour it’s down to 3.6TB and still going.
The definition of /tmp/ is temp stuff that doesn’t need to survive a reboot.
Often , /tmp/ is actually located in memory, so just rebooting cleans it.
If these returns nothing, files may be in the root partition and will survive a reboot, so you need to manualy delete them (like you are doing)
df -h | grep /tmp
mount | grep /tmp
Session files and whatever reside in /tmp/ , so better reboot just after, you ll see a few files there just after the reboot.
Urbackup save some files for debug in /tmp/ when it can t get the metadata or whatever.
And yes, theses need some manual cleanup.