Slow QNAP Repository: Options

[nick3young]

Hi All,

I have recently had a support call open with VEEAM over very poor transfer speeds across our LAN to a QNAP NAS device located in another building (setup as a CIFS repository). They have given me two suggestions:

1. Install a second backup proxy located close to the QNAP device
2. Install some components on the QNAP and register it as a Linux repository on our main VEEAM server (though he pointed out that this isn't officially supported).

I would prefer the 2nd option because it will be cheaper (free). However, I cannot find a lot of useful documentation on how to get VEEAM to recognise the QNAP as a Linux repository..... and I am useless with Linux!

So I started thinking about the 1st option. There will be a cost but at least it will be simpler to setup and officially supported. However, I cannot find any guidance on what the spec of this server should be if it is just acting as a proxy. Would I get away with just using a standard workstation or would it need to be a monster with 32GB of RAM? I'm guessing the sensible answer would be that it depends on our environment, what we are backing up etc etc.... but could anyone provide me with some kind of rough idea? Would an i5 machine with 4GB of RAM be adequate for a VEEAM proxy?

Finally, if anyone has successfully set their QNAP up as a Linux repository I would be grateful for any advice.

Thanks
Nick

[homerjnick]

I backup our virtual estate to a QNAP TS-412U 12TB and across a 1Gb switch I get excellent performance without having to set up a Linux repository.

How is your virtual estate and the QNAP NAS connected at the moment?

Depending on your model of QNAP might it be network related? What transfer rates are you expecting and what transfer rates are you achieving?

[nick3young]

Here are some of the report details from some randomly selected copy jobs:

Note - times are given from 1st server starting to last server completing. The 'END' time is when the actual job reports itself as finished.

Backup Copy Jobs
Full 17:15 ---> 04:35 (END: 09:23+1 - 11hrs) (2.0TB 1.3x) 22/02/15
Incr 07:30 ---> 09:00 (END: 17:38+1 - 34hrs!) (167GB 1.6x) 05/03/15
Incr 17:30 ---> 18:58 (END: 09:11+1 - 16hrs!) (141GB 1.6x) 06/03/15

Backup Jobs
Full 20:00 ---> 10:46 (END: 10:46+1 - 14hrs) (2.0TB 1.3x) 02/05/14
Incr 20:01 ---> 21:32 (END: 21:32 - 1.5hrs) (110GB 1.8x) 11/06/14
Incr 20:01 ---> 23:16 (END: 23:16 - 3.2hrs) (130GB 1.7x) 16/12/14

The bottom three (backup jobs) are all processed on a single server - it acts as the VEEAM server, repository and proxy. The top three (backup copy) are processed on the VEEAM server, but the difference is, the QNAP is the repository for these jobs which is located in another building across two separate switches.

As you can see, the full jobs are comparable in terms of duration. In fact, the QNAP copy job is quicker. It is with the incremental where it struggles.

If you look at the timings of when the last server finishes backing up to when the actual jobs ends, there is a HUGE difference. For example, that middle incremental finishes on the last server 9am... but the job doesn't complete until 17:38 the next day!!! A whopping 34hrs for that job. I can only assume that this is because the QNAP, as a CIFS repository, cannot perform any processing?

Thanks
Nick

[foggy]

Nick, what are the full bottleneck stats for these jobs? Synthetic backup activity (which is most likely causing the slowness) is performed by a data mover agent installed on the repository server. In case of CIFS repository mounted to the proxy server, it is performed by an agent on the proxy, over network (which is not optimal, indeed), hence recommendation to set up an additional proxy server at the target side. Basically, it should at least meet the system requirements, however depends on the amount of tasks concurrently assigned to it.

Regarding using QNAP as a Linux-type repository, please review this thread.