Server fills /Tmp and hangs

Well, my backups have come to a halt, literally.

I wanted to replace my Windows Home Server with an OpenMediaVault Server.
Initial testing was with some small disk drives.
Initial testing of backups from my three Windows PCs worked fine, no problems.
Once I had all the other pieces of the puzzle in place, I felt I was ready to make the switch.
So, I swapped out the small disks and replaced them with a 60GB SSD for OS and apps.
and a 1.5TB raid 1 data disk.
Well here is where it went down hill.
Oh, 2GB of memory in server.
UrBackup would be handling a backup, and gradually filled up the /TMP directory (1GB 1/2 of memory is the default).
Once this fills up, the backup just hangs.
SO, OK, maybe it needs more for some reason since the disks are bigger.
I bumped the memory to 8GB.
Didn’t help, just delays the hang when the 4GB for /TMP fills up.
Backups are being saved on the large data disk.

Here is a df -h output:

[list]Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 55G 1.9G 50G 4% /
tmpfs 4.0G 0 4.0G 0% /lib/init/rw
udev 4.0G 192K 4.0G 1% /dev
tmpfs 4.0G 0 4.0G 0% /dev/shm
[color=#FF0000]tmpfs 4.0G 4.0G 0 100% /tmp[/color]
/dev/md127 1.4T 348G 958G 27% /media/eee15d09-a294-4b09-abac-458fe7bf06fa[/list:u:36fyhjc3]

Can’t figure out how to display the output in columns, so it is kinda messy. But you get the idea with the %100 being under the used column.

Does anybody have any idea why UrBackup is filling up the /TMP space?
I could give it a bit more memory, but I doubt that would help.

tia

Hi,

this is by design: UrBackup first copies the files to a temporary location, then processes the files/data and copies it to the final location.

This is of course a bad idea if /tmp is on tmpfs and thus in memory. (For image backups every client needs at least 1GB memory there otherwise it deadlocks)

The way to avoid this is setting UrBackup to use a different temporary location via setting the TMPDIR environment variable on linux.
e.g.
export TMPDIR=/media/striped-vol/tmp
start_urbackup_server

with the Debian package you can set the tmp dir in /etc/default/urbackup_srv

Thanks for the information.
I will give it a try.

Hey, first of all: Nice piece of software, keep up the good work. :)

I have the same problem like z06vette, my temp directory runs out of space, then urbackupserver hangs.
Except i already pointed to another temp directory in the file /etc/defaults/urbackup. This temp-directory has bout 600GB of free space, but when i image-backup my 1TB Harddisk, the temp directory runs out of space.
Image-backing up the 128GB SSD works fine.

So i guess to make an image of a 1TB Harddisk i need at least 1TB of free temp-space? How does it behave if i backup the 1TB HD as a file-backup?

Is there a way to change this behaviour, because its kinda strange to put in a 1TB/2TB HD just for temp-space :roll:

For the image backups you need at least 1GB tmp space per client. The temporary image file data is chopped up into 1GB pieces. Are you sure it is hanging and not writing the image data to the .vhd file (watch if the size changes)?

If you have a 1TB file you would, however, really need 1TB tmp space.

Changing this behaviour would be easy for the image backups and hard for the file backups.

Well it is doing something, theres no network traffic, because there is no more free space on the temp-disk.
When i look the running processes with “top” i see urbackup_srv thats uses 4-10% CPU and a “jfsCommit” that uses 100% CPU.
The temp-disk is ext4 and the backup destination disk is JFS, so i guess there is something going on.

So how does it work, i fills up the temp-dir until there is no more free space, the it begins to write data on the backup-disk?
Or does it fill up the temp-dir, because data is writen faster there than it can write data from temp to backup?

[quote=“qnetalien”]So how does it work, i fills up the temp-dir until there is no more free space, the it begins to write data on the backup-disk?
Or does it fill up the temp-dir, because data is writen faster there than it can write data from temp to backup?[/quote]

Second case. After creating one of those 1GB files it starts writing out the image data. The vhd file writing is a little bit inefficient too, I think.

Ok, thanks for the info.

VHD writing indeed seems to be a little slow, the network transfer is finished since 2 hours but urbackup still isn’t finished with the image.
It shows a an active process in the Urbackup webinterface which is at 100% but won’t go away (because its still writing in the background).
On the client side the icon is red and says “no actual backup”, before it was hanging at 100% for quite a time.

I tested today what z06vette tried to do. I made am 8GB /tmp directory in RAM (i have 16GB im my server) and pointed urbackup_srv there. I made a file backup and two image backups.
The file backup ,about 100gb small and big files, finished without problems. The image backup from the 128GB SSD (~100GB used) ran without problems too, and was pretty fast. 22min, thats about 75MB/s.
While the backup was ongoing the ram-temp drive was never full, there was a maximum of ~4GB in there.
Then i started the 1TB HD image backup, for the first hour everything stayed like before. But after 52% of the backup, the temp drive filled up with data, the network traffic went down to a few kb/s and suddenly urbackup_srv wasn’t doing anything.
The webinterface was still responsible, and the backupprocess visible on the server and client side. But there was no more nettraffic, no CPU usage and no HD-writing.

This is just for your info uroni, i was in the mood to do some testing :)

Thanks! Now I know for certain there is some issue there I will try it, as well. You don’t by chance have a (debug) server log file of that session? Also: How much free space was on that 1TB drive?

No sorry, i did not make any debug logs. The 1TB disk is nearly full, there are ~100gb free space.

Having the same issue when running a image backup from my laptop on client/server version 1.

Backup is extremely slow, /tmp fills & everything grinds to crawl.

Moving the tmpdir to larger drive just causes 94x 1GB files to be created but the .VHD is only 64GB after 20 hours of the backup and only completing 50%.

Did not see this issue on the previous version.

I’m looking into this, but so far I did not have any luck reproducing this issue. Do you have the server logfile, by chance? Even an warn/error level one would help me exclude certain causes.