QNAP as Linux repository

[lucius_the]

Tried it today (using QNAP as a Linux repository) so just a quick report back. It works ! Pretty easy to set it up, too.

I hit a couple of issues:
- free space is not reported properly on this repository
- I'm getting "swap memory usage too high" warnings on the NAS, with "VeeamAgent304fb" process being responsible for swapping. This is a small NAS, used for offsite copies only, obviously needs more RAM (I used 2 concurrent tasks, maybe reducing to 1 could help, will try)
- in my test it was also about a third slower than SMB. But network is reported to be the bottleneck, so maybe it's just link is being used, as I tested during working hours.

Couldn't find a workable solution for free space reporting though. I only found old posts, where Perl used to be installed manually, with examples on how to modify it's code to report free space for a chosen datastore. Found no info yet, on how to make it work with the QNAP provided Perl package. But QNAP can send me a alert when storage is low on free space, so there is some workaround for this.

Thanks for the suggestion ! This looks fine. It would probably work better on the bigger NAS boxes with more CPU and RAM, I'll have to try.

[Gostev]

Yes, reducing concurrent tasks to 1 will definitely improve the RAM situation.

[lucius_the]

I did a NAS firmware upgrade yesterday, just to see if I get problem afterward. It was just a minor version change upgrade, I wasn't far behind at all (I updated the NAS not long ago, maybe a month or so).
It stopped working - offsite copy job failing with error "can not connect to target backup repository".

When trying to reconfigure the repository I get "Failed to start PerlSoap protocol". Tried rebooting the NAS, stopping/starting Perl, reinstalling Perl. Didn't help.

At some point when I went to repository properties I saw a different error saying something about the user couldn't chroot to it's home folder.
I found the checkbox to enable "home folder" for all users on the NAS box - that did the trick. It's working again.

[lucius_the]

Unfortunately, I won't be able to use this for the bigger NAS boxes (the primary backup repositories) at one site, due to specific network setup.

I have two vSphere nodes, each connected to the NAS directly via a 10 GBps link (using two SFP+ passive DAC cables). I can only use this high speed connection from the Veeam proxy VM-s, that run in each node. When I'm adding an SMB repository I can point it to use the Veeam proxy to access it, so it uses the connection through the proxy and can access the share through that high speed link. Unfortunately I can't do such a thing when adding a Linux server. Veeam server wants a direct connection to it, no option to choose a proxy.

My vSphere essentials licence don't allow for a distributed switch, I also have no 10 GBps switches (expensive stuff) so this complicates things. In the end I can't use a 10 GBps link in combination with a Linux repository target, as the Veeam Server itself is on a third box, separate from the two vSphere nodes and is not in the same network segment where the 10 GBps link are. Pity. It works for SMB though, and iSCSI.

EDIT: I could try monkeying around with the hosts file on Veeam server and Veeam proxies, perhaps. That would make my setup a bit more complicated and less manageable, but could work... maybe worth a try.

[lucius_the]

Monkeying with the hosts file on Veeam Server and both proxies did the trick.

But I notice some other, new issues on my NAS boxes with this setup - both the big NAS box one and the smaller one: as soon as Veeam agent process (running on the NAS) starts doing health checks or anything more heavy the NAS, the NAS starts behaving crazy and alerting of fan failures. On both NAS boxes. Never had a fan failure on any box before. After the job finishes it comes back to itself. Or after I restart a NAS. This happens on both NAS boxes.

Also, the main backup job failed with "Unable to apply retention policy" and "Failed to start client agent on the host, operation timed out" messages. On the bigger box (Core i3, 8 GB RAM) the CPU was practically idling during the job, plenty of free RAM as well.

Retrying the job finished it successfully, but during the job, the NAS again started going crazy with "fans failing" and than came back to itself after the job finally finished. Again, CPU idling, plenty of free RAM during the job.

I'd have to call this setup unstable and I'll have to go the iSCSI route, with all that it brings along.
Pity, as this looked promising.

[JPMS]

I would have a look at the fan control on your QNAP.

As you say, it is unlikely that there is actually a problem with the fans. The standard setting is automatic fan control. My guess is that the speed is linked just to CPU temperature (which will remain low as there is little CPU use). The hard drives are in heavy use though and I wonder if they are getting too hot triggering the fan failure warning.

I would try setting them to manual and choosing a high setting and retesting. It might make no difference but is worth a go!

[lucius_the]

Hi, JPMS.
No, I gave it up. HDDs were measuring between 30-34 C - this is the first thing I've checked when I saw warning that all fans have failed. I've never seen this "fan failure" before. As I said it happens on both NAS boxes (different QNAP models) as soon as the agent starts doing something. Quite strange. On one box the fans info get back to normal when the job finishes, on the other only after I reboot it. I can't tell if the fans were spinning or not as I was doing this remotely.

Switched to iSCSI, now I get free space reported properly, I also get multipath with failover, as iSCSI supports that. So I'm going to stick with that. No more fan failures occuring after I moved away from agent on the NAS thing. I uninstalled Perl as don't need in the box anymore, maybe it had something to do with the issue. Who knows. I didn't read logs on the box, didn't really explore the problem in depth. I just went away from that and switched to iSCSI. Did a multi-TB Active Full job afterwards. Zero issues so far.