Temp Buffer Question

I have a question about the functionality of the “Temporary files as image backup buffer” option within UrBackup.

Currently, Windows 7 (the UrBackup server) is running in ESXi on a RAID 1 datastore.

Would it be beneficial to install a drive dedicated exclusively for backup buffers? Would a 160GB 10k drive be sufficient for this? The computers being backed up will be larger than 160GB each.

Thanks.

It would be sufficient, if no client has a file larger than 160GB that is backed up. For images it is okay if they are smaller. It depends, but it probably does make only sense if the RAID 1 datastore is much slower than the disk you want to add, i.e. you’re using something like deduplication or compression on the backup storage.

Thanks for the quick response Uroni.

I am using the temp drive now and everything is working great. The only thing I’ve noticed is that the transfer from the buffer drive to the final storage location is very slow, around 1MB/s.

Is this by design? The buffer drive isn’t full and no other backups are currently running.

I am about to put UrBackup into production and this is the only question I have left. Thank you for creating this wonderful project! It’s exactly what we’ve been looking for.

It reads and write to the buffer drive simultaneously. This causes some seeking, which may slow it down, compared to writing it directly.

I’ve still been unable to surpass 1.1Mb/s transfer speeds.

Reinstalled the server and the clients, same performance. I am running client 1.1.2-1 and server 1.2-1. When I was testing a previous version, transfers were running around 30Mb/s.

UrBackup is using a NAS for its storage. Can transfer files to and from the NAS from the UrBackup server host around 70-90Mb/s. I only experience the performance issues when transferring directly within UrBackup

Is there some kind of log you can check for me? To my knowledge, nothing else has changed on the UrBackup server besides the actual version of the server. Perhaps I have something improperly configured along the lines.

Thanks, I appreciate all the help!

Some questions to bisect this issue:

  • Which earlier server version did not have this issue?
  • Are you sure the bottle neck is temporary storage -> final storage and not client -> temporary storage ? (I.e. is a lot stored on the temporary storage during backups) For the second case: Client 1.2 has the “hashed” image transfer mode. This may slow it down. Disable it in “advanced” on the server.
  • The temporary storage volume is local and the final storage volume is remote?

I just reinstalled the server earlier today and I did not enable the temporary drive, as a way to eliminate certain variables.

When the transfer speeds were fast, I was running v1.1.1-1

I should note that the server was installed with the 37.3MB exe installer. Maybe I should try the x64 .msi installer.

[quote=“zidvbelju”]I just reinstalled the server earlier today and I did not enable the temporary drive, as a way to eliminate certain variables.

When the transfer speeds were fast, I was running v1.1.1-1

I should note that the server was installed with the 37.3MB exe installer. Maybe I should try the x64 .msi installer.[/quote]
Thanks. Between 1.1.1 and 1.2 the new “hashed” transfer mode was enabled (Disable via advanced) and not much else (Speaking of image backups).

The installers contain the same files, so this should not matter.

[quote=“uroni”][quote=“zidvbelju”]I just reinstalled the server earlier today and I did not enable the temporary drive, as a way to eliminate certain variables.

When the transfer speeds were fast, I was running v1.1.1-1

I should note that the server was installed with the 37.3MB exe installer. Maybe I should try the x64 .msi installer.[/quote]
Thanks. Between 1.1.1 and 1.2 the new “hashed” transfer mode was enabled (Disable via advanced) and not much else (Speaking of image backups).

The installers contain the same files, so this should not matter.[/quote]

Sounds good, thanks for the reply.

I will disable hashed transfer mode and see how the backups run tonight.

Set all the transfers to raw instead of hashed. From what I can see, it looks like the backups are running even slower now (500-600KB/s).

Very strange. I will install 1.1.1-1 today and see how that functions. At this point, I still think there’s a configuration problem somewhere on my end. Just can’t think of what it would be.

I should also note that I have the UrBackup server service running as a domain user that has permission to the network share. Perhaps the issue may have something to do with that? Maybe I should run the client service under the same domain user.

The slow transfer speeds apply to image backups and file backups.

Installed 1.1.1-1, same problem.

I’ve been moving random ISO images back and fourth between the NAS and the UrBackup Server hard drive (CIFS); no performance problems are experienced. The slow transfer speeds are only experienced when transferring files through UrBackup.

Tried a bunch of different configurations with software/hardware. Really has me stumped.

UrBackup uses a buffer of 4096 bytes when copying files. This could be easily increased for the file backup part, but not for the image backup part.

Anyway, if it was fast with 1.1.1 and now isn’t it is probably in connection with some samba/cifs performance issue.

Did some packet tracing today.

The performance issues seem to be active during the transmission between the client and the server, not between the server and the NAS (unless the connection between the server and the NAS sets the transfer speed).

Still looking into this.

EDIT- Perhaps this is an issue with the maximum number of user connections that Windows 7 allows (I think it’s 10?). I am going to install UrBackup server on 2008 R2 and see how that works out.

Installed UrBackup on linux, on the same ESXi machine. Had the transfers going at 30-50MB/s.

Same exact client machine has been used for all testing. So there is definitely something going on with the Windows CIFS sharing. I feel like I’ve tried to eliminate a bunch of different variables. I thought Windows CIFS was pretty straight forward but I may be missing something.

The only reason I was going to install the server on Windows was to take advantage of the compression. I am wondering if it’s even worth it.

Didn’t you say the connection between UrBackup client and server was the bottleneck? UrBackup doesn’t use cifs, it uses its own method of transfering files and images.

You can get compression on Linux via fusecompress – maybe even if you mount a remote folder.

[quote=“uroni”]Didn’t you say the connection between UrBackup client and server was the bottleneck? UrBackup doesn’t use cifs, it uses its own method of transfering files and images.

You can get compression on Linux via fusecompress – maybe even if you mount a remote folder.[/quote]

It seemed that way from my testing, but it isn’t conclusive. For now, I will be stickicking with Linux. The original plan was to use a Linux server anyway; the NTFS compression doesn’t seem that major. We have plenty of storage space available so I am fine with the current setup.