x86 NAS as native target

[mc1]

Hi,

Having all sorts of problems sending a backup job to our readynas box. It is the slower nv+ so expected it to be a bit slow but this is the problem we get.

When running a single veeam job everythng is ok and we write at about 25MB/sec as soon as a second job starts both grind to a halt. I think the problem is with the Cifs Samaba server and general windows connectivity to the box as our ESX hsosts can write to an NFS share while the veeam jobs are running all OK.

To bypass windows I thought I would add the box as a linux machine and see if that helps. I have enabled ssh and conenct via putty and winscp but when I try to add to veeam I get a "timed out waiting for operation "(cd /tmp && perl...... error

Any ideas?

Cheers

Michael

[Vitaliy S.]

Hi Michael,

I'm not sure it is possible to add ReadyNas as an ordinary Linux server, because just enabling SSH won't help, as Perl is also required. Your issue reminds me the one that we had with Synology NAS.

So in order to make it work, I would recommend mounting your NAS device to any Linux box (RHEL, Ubuntu etc.) and then adding this Linux to the backup console, should work.

Thanks.

[mc1]

I managed to get this working. Obviously not supported but could help someone in the future. I havent done any speed tests yet.

You will need to install the SSH addin and access the box using putty

wget http://www.readynas.com/packages/readyn ... t2_all.deb

dpkg-deb -x perl-modules_5.8.8-7.infrant2_all.deb /

cp /usr/share/perl/5.8.8.7/usr/share/perl/5.8.8/Getopt/Std.pm /usr/share/perl/5.8.8/Getopt/Std.pm

Hopefully this will help someone in the future

[Gostev]

Thanks. May be this is not supported by ReadyNAS, but totally supported by Veeam and very neat too!
This definitely wins "Best Veeam Backup target" contest hands down

[chrisdearden]

I thought i'd give this a try but after downloading and extracting the /deb file I'm getting an error on the copy portion.
I dont appear to have a 5.8.8.7 folder under /usr/share/perl/ , just 5.8 and 5.8.8

any suggestions ?

[rct]

For information I managed to get this working on a Synology NAS.

What about using SFU to mount an NFS share to the Veeam server?
http://technet.microsoft.com/en-us/libr ... 63214.aspx

[Vitaliy S.]

It will work, however this will not allow us to agent-enable this repository for local synthetic full processing, so fulls will have to be processed over LAN (= worse performance). Our local processing agents can only be installed on Linux server, and with NFS share alone there is no place to install them.

[stelben]

I'm sorry to open this old thread but I ended up here after Gostev's latest Digest.

I'm probably asking an unnecessary question but I'm not afraid of doing it, unreveiling my novice-ness here:-)

With opening up SSH for the ReadyNAS are you trying to accomplish the Veeam BackupServer being able to push out a linux-agent?
Making the NAS-box able to hot-add the disks directly on the SANs?
If this is the case, that's must be the way to go for the backup strategies!

What about with the NICs in the NAS?
Does the NAS need direct access to the SAN AND to the Veeam backup server?
I'm thinking of network connectivity VLAN/subnet etc.

Also, in regards to Gostev's comment on the 1Gb-bottleneck...
Since the NIC on the NAS will stay the same (1Gb probably) this wont change.
If not the direct disk hot-add is the key where 1Gb/s iSCSI-chat is better than 1Gb/s-CIFS-chat...

Can you please shed some light on this to me?

Thanks

Jonas

[Gostev]

Both this thread and the digest are talking about target (backup repository) agent only. While SAN access and all is done by the source (backup proxy) agent - different thing, unrelated to what is being discussed here.

Target agent is used for things like synthetic fulls, transformation and so on. When the backup repository is not agent-enabled (such as in case of CIFS share), the target agent is started on the backup proxy, and all operations are done over the network, which is not optimal of course. Much better to do them locally on the box.

[thank]

I also managed to get this working with THECUS NAS. It is tested on N4200PRO (pending test on N5500). I think it will work on most of the recent Thecus NAS (same firmware file).

Brief Installation instructions:
1. Upgrade to the NAS to the latest firmware (current V5.02.02).
2. Install from this site http://www.fajo.de/main/en/thecus/modules (thank you John Falk for those modules) the following modules with this order:
a. ModBase1 (http://www.fajo.de/main/en/thecus/modules/modbase1)
b. Perl514 (http://www.fajo.de/main/en/thecus/modules/perl514)
c. FaJoSSHD (http://www.fajo.de/main/en/thecus/modules/fajosshd)
3. Configure FajoSSHD listening port to 22
4. ssh to thecus with username root and Password (your admin password). Type "cd /sbin" ; " ln -s /raid/data/module/Perl514/system/bin/perl";
5. Enable NFS on thecus and allow NFS access from the IPs of ESXi servers and B&R Servers.
6. Proceed with the usual Linux repository target installation from Veeam B&R console.

The performance seems good (48MB/s).

Hope this mini guide will help.

Thanassis Kappas
SYSTEMATICS

[captainflannel]

anyone have any experience with using a qnap device as a backup repository? We are in the market and considering synology, qnap, thecus or just just running FreeNas.
Thanks!

[captainflannel]

Also wanted to add peoples current experiences or thoughts when using Veeam Agent on some of these NAS devices. Many of the SMB lines only run an Intel ATOM cpu, higher ends use some intel core2duo and xeon etc. When using a NAS device + VeeamAgent, running Intel Atom processor, wouldn't this just create a bottleneck on the NAS cpu? I would suspect performance might not be any different then just going over the network when using something like an Atom for reverse incremental full backups. Or am I missing the benefits?

[Gostev]

Unlike source agent, target agent uses very little CPU resource, so no - Atom CPU should not be a bottleneck. With these low end NAS having just a few spindles, bottleneck is always the disk speed (especially when we are talking about reversed incremental backup).

[tsightler]

Using the agent means that you only have a single write stream from a network perspective. Without the agent you must transfer 3x as much data across the wire via the SMB protocol for reverse incremental. My experience is that this more than makes up for the additional overhead on the local CPU due to network traffic savings alone.

[captainflannel]

Thanks for quick replies. I'll update with our experience to share with others.