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.
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
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.
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