Backup to NFS

[Bunce]

Hi All,

Starting to test VBR and looks pretty good so far. Planning to use replication to our DR site as well as backups to a local NAS (we run an EMC AX4 for our primary iSCSI storage). vSphere4 - 3 hosts.

While the NAS (QNAP) can be exposed as an iSCSI target, its not overly reliable on the QNAP's and an NFS target offers better flexibility and management for our purposes.

From what I've seen so far, VBR doesn't seem to offer NFS as a native backup target? This seems a little suprising given how useful NFS is for backup destinations these days. With our previous backup software (esxpress), we simply pointed it to the NFS share and it was ready to go.

Am I right in that in order to backup to an NFS share I need to create a VMDK disk in the (virtual) VBR server, locate it on the NFS share and backup to this disk using VA mode? This seems to add additional 'layers' which may slow performance (eg Windows TCP stack, vmdk/ntfs conversion, etc). and add additonaly steps in order to get to the the raw backup files if we needed to extract it manually..

Given how crucial the backup window is these days I'd imagine we'd want as efficient a backup target as possible with minimal overhead.

I'm only new to VBR so may well have missed something - so wondering if anyone can point out a recommended route? I'd have thought if our esx cluster could 'see' the NFS share (destination) as well as the iSCSI storage (source) then we would be able to back up to it directly, or am I still thinking in 'esxpress' mode?

Thanks in advance,
Andrew

[Vitaliy S.]

Andrew,

We do provide support for NFS as destination targets, storage must be mounted on ESX host or Linux server (don't forget to add it backup console), after that you will be able to choose it as destination. Also you may try to use Microsoft's native utilities to present NFS share to your Windows Server, where Veeam Backup is installed.

Also please have a look at our Evaluator's Guide, which has some best practises and recommended steps you should take to successfully perform backup of VMs.

Thank you!

[Bunce]

Thanks for your reply.

I've added our VC into the server tree in VBR and can see all our hosts and storage (includinig iSCSI and NFS targets).

When creating a job, on the 'Backup Destination' screen, I select one of the hosts. I can view the properties of the host, but I get a timeout error when I click the 'populate' button to list the storage targets.

When I expand, "Path to Folder" I see a big list of folders.. Is the NFS share meant to be displayed in here? (sorry I'm a Windows guys)

[Vitaliy S.]

That's ok, you should see a NFS share as a mounted folder under your ESX or Linux node, which you've added to backup console.

[Bunce]

At the root of the node along with all the other folders in the 'Path to folder' dialog box?

[Gostev]

Please clarify, did you mount this NFS share to a Linux host, or to ESX host as datastore?

[Bunce]

Hi Gostev.

Its mounted to each of the ESX Hosts via VMKernel ports on the vSwitches. It appears available to all hosts in VCenter just like all other storage (iSCSI, Local, etc)

Cheers,
Andrew

[Vitaliy S.]

Andrew, could you tell us please if you are able to see your NFS datastore if you browse your ESX host to vmfs\volumes folder?

[Bunce]

Hi - sorry for the delay. Yep - its in there and if I select this folder manually in the tree then the backup succeeds.

Is this the correct way to select the NAS storage as a destination for backups? I assume this in effect 'ties' the backups to that particular Host, which I assume means I should also tie the VBR VM to the same host to keep the traffic 'local'?

[Vitaliy S.]

Andrew,

You may also choose your NAS device as destination storage by pointing to its IP address for example. If you're running VBR server in the a virtual machine try using Virtual Appliance backup mode, in this case Veeam uses SCSI hot-add capability of ESX to attach disks of a backed up VM to the Veeam Backup & Replication VM. In this mode, VM data is retrieved directly from storage through the ESX I/O stack, instead of going through the network stack, which improves performance.

Thank you!

[Bunce]

Hi VItaly - I've been using Virtual Appliance mode.

The question I'm asking is *where* do you specify the IP address of the NAS as the destination in the backup job properties? The only way I've been able to backup to the NAS is to mount it via one of the hosts and select the \vmfs\volumes\ folder..

I guess I was expecting to see something similar to the following:

1) Enter Backup Job Name
2) Select Backup Mode = Virtual Appliance
2) Select source VM's
3) Select Destination Target -> Type=NFS -> Enter IP of NAS
4) Specify advanced backup properties / retention policy / etc

Thanks again,
Andrew

[Gostev]

Andrew, you specify the IP address of the ESX or Linux server that your NAS is mounted on in the Add Server wizard. Then the server would appear in the Veeam Backup Servers tree, as well as in the selection of available targets on the Backup Destination step for backup job, and you will be able to pick it.

[Bunce]

Ok so we're not backing up directly to the NFS server from the VBR VM, we have to proxy it through a particular host meaning it's always going to be tied to that host (and will presumably fail if that host is down).

And the method I'm currently using of selecting that host in the backup job properties and then navigating to the vmfs\volumes\ folder to located the NFS server is the way to go.

I just need to start thinking in a different way to how esxpress worked. We previously specified the IP address of the NFS server, the helpers started, mounted the VMDK to backup and sent the backups directly to the NFS share.

Thanks for your assistance.
A

[Gostev]

If your NAS allows CIFS operations (which virtually any NAS existing offers), you can specify IP address as destination directly on the Backup Destination step, by simply typing in \\IPaddress\Share - without having to tie this to any host.

[Bunce]

Yup - the QNAPS offer NFS, CIFS, FTP, ISCSI, etc.. but I would have thought CIFS would be the least performant of them all. FTP was quite quick when I tested it with esxpress from memory.

I'll do some tests and see what type of throughput we get on each.

Cheers,
A

[Gostev]

You should consider using iSCSI if it is available... you can mount backup storage LUN directly to Veeam Backup VM (using Microsoft iSCSI Software Initiator), it will appear as a local volume to OS and you can just select that as destination.

On a related note, what model is your QNAP NAS, just for my information.

[Bunce]

The model is TS-809U-RP. Unfortunately the iSCSI implementation on the QNAPS are buggy. We are however using iSCSI on our primary storage (EMC AX4).

The QNAP's also allow automated 'backups' of NFS shares to external media (eg attached USB HDD) which provides an additional option for off-site storage. They don't support performing this from iSCSI partitions.

Lastly, we prefer the increased manageability of NFS as you can quickly & easily 'get' to the raw backup files compared to block storage, which we feel is very important in restore situations.

Overall, I don't really see the advantage in using ISCSI as a backup target over other methods as long as their read/write performance is acceptable. I'd initially envisaged placing the NAS server on the storage VLAN along with the EMC SAN, giving the VBR VM a vNIC on this network, and using VA mode to backup directly to the NAS via NFS, thereby keeping all traffic on the storage vlan (mounted VMDK and destination NFS mount directly from VBR VM).

However it appears the only way to get to the NFS share is via the host (and therefore through SC) unless I install an NFS client in the VBR VM, mount the share directly and hope that the VBR software can see it?

That said, the speeds so far using VA mode are quite good so my initial concern about VBR not 'supporting' concurrent backups is alleviated - its now just a case of ensuring that 'it-just-works' without any obvious points of failure in terms of dependencies, and performance implications on other components (SC, Network, etc).

Next step is testing the replication features as we would like to replicate our VM's to our DR site in addition to local backups to the QNAP.. Any obvious implications with running a backup followed by a replication of the same VM? Is the order in which this occurs important in terms of CBT?

Thanks again.

[Gostev]

No implications around backup followed by replication, this question is actually covered in FAQ
By the way, we do support concurrent backup jobs; but you are right - in many cases they are simply not necessary.