Slow backup with large files?

I’m trying to work through some issues I’m having with various clients backing up and I think most of my issues are due to large Exchange databases. I noticed the following in the live log for a client. priv1.edb and priv1.stm are both about 3GB. This is on an SBS 2003 server. What is the delay between the png and .edb/.stm files caused by?

30.06.14 15:20 DEBUG GT: File “Pro_Plus_BB1.png” not found via hash. Loading file…
30.06.14 15:20 DEBUG GT: File “Pro_Plus_BB2.png” not found via hash. Loading file…
30.06.14 15:20 DEBUG GT: File “Pro_Plus_BB3.png” not found via hash. Loading file…
30.06.14 20:34 DEBUG No old file for “priv1.edb”
30.06.14 20:34 DEBUG GT: Loaded file “priv1.edb”
30.06.14 20:34 DEBUG No old file for “priv1.stm”
30.06.14 20:34 DEBUG Loading file “priv1.stm”
30.06.14 20:34 DEBUG PT: Hashing file “priv1.edb”

Actually it seems to have hung again. For about the last 5 hours the entry in the live log is a .doc file which is fairly small. Iftop on the server shows that client sending data at 1.3Mbps so it’s sending something but I can’t find what it is.

I just enabled logging debug messages on the client and restarted the urbackup service.
Once it was restarted the log on the web interface showed what was probably several hundred files which had been finished. It seems it stopped updating logs when it hit a 500MB file, that was the first file to show as transferred after the client was restarted.

The gap in the logs went from 01.07.14 02:54 to 01.07.14 07:01 and showed the client disconnected at 7:02

Would it be possible to have the status on the client display the file it’s currently working on and if it’s hashing, sending, or waiting on commands from the server? It would be a lot more informative.

That is the 1.4 download queueing in action. It will say “loading file X…” before actually downloading it. I’ll add a log message for long running file downloads…