Backing up TO an NFS server

[gerdawg]

Hi all!

I had a quick question about backing up TO an NFS server that I was hoping one of you can answer.

First and foremost I have a vSphere essentials package that I am looking to backup our Virtual Machines with veeam and have taken some considerable amount of time reading through the FAQ's on the site, other posts on this forum and a web demo by veeam today but I'm still left a bit confused as to how the backup storage device, veeam and different technologies for storage meld together.

What I am trying to do currently is use a FreeNas device as an NFS location to backup our virtual machines to through veeam. Basically what I am looking to accomplish is a quick down dirty way to get the virtuals out of vSphere using veam and stored into this NFS appliance however I am unable to choose it as a location to mount to for backups. From my readings on the forums it was stated somewhere that using NFS as a repository is NOT supported or recommended, however that said, in my demo today (unless I mis-spoke or was mis-understood) when I asked the question it was stated that you CAN backup TO an NFS appliance. If that is true, I am at odds on how to do it and wouldn't mind a little assistance getting that going.

To further my post, I have even tried to present the NFS share mounted in my vSphere environment as a datastore which allows me to use the storage location for replication but not for standard D2D backups.

Basically I'm wondering at this point if I need to present LUN's to the veeam server to make this happen and mount these LUNS directly through the veeam OS (W2K8 R2) using it's native iSCSI initiator and format the device then using NTFS?

I really wanted to us NFS as a quick way to present a backup location to veeam but will install openfiler instead if that's the desired path. I have tried to install the NFS client for W2K8R2 but that stops short since port 111 is in use by veaams NFS services.

My next question that I had was more in line with the "instant recovery feature". Am I correct in assuming that veeam installs it's own NFS server on the Windows 2008 R2 box to be used as an NFS datastore in order to publish backups directly to the vSphere servers? Is this how the feature truly works?

The reason I ask this is because my end goal is to save a bit of money for the company and re-use an MD1000 (DAS) storage device that we have already in house which happens to be full of disks and then have it directly presented to the veeam VM guest and used as local storage. My hope was to use this DAS as a local repo for the backup's and then using veeam's internal (NFS) publish out the backup files for instant recovery if ever needed. Does this sound like it would work, was that even the desired intent? If not, do I need to invest in another iSCSI device to share the backup datastore with the ESXi servers if our shared single array that we have today goes down?

Thank you sincerely in advance for any information you can provide to help me get this all sorted out in my head, it's appreciated!

[Gostev]

Hi, Gerry.

You cannot backup directly to NFS share, but you can backup to a Linux server where this share is mounted.

Basically I'm wondering at this point if I need to present LUN's to the veeam server to make this happen and mount these LUNS directly through the veeam OS (W2K8 R2) using it's native iSCSI initiator and format the device then using NTFS?

Yes, this is the second best approach after backing up to Linux.

My next question that I had was more in line with the "instant recovery feature". Am I correct in assuming that veeam installs it's own NFS server on the Windows 2008 R2 box to be used as an NFS datastore in order to publish backups directly to the vSphere servers? Is this how the feature truly works?

Correct.

The best way to use DAS as backup target is to use physical Veeam Backup server, and attach DAS to it. This would be a perfect config for vPower stuff.

[gerdawg]

Thanks for the reply Gostev. It makes perfect sense.

I do have one last question on the quote below:

The best way to use DAS as backup target is to use physical veeam Backup server, and attach DAS to it. This would be a perfect config for vPower stuff.

Is the reason for this due to the issue of a storage array going down (that also hosts the veeam VM) in which you wouldn't have a VM to restore to, or are there other reasons for keeping vPower/veeam off virtual and onto physical?

The reason I ask this is that I had intended to store the veeam guest os on physical disks on one of my vmware servers and present the perc 5e card directly to the guest OS for DAS. I have more than enough house power in that specific virtual server where it would actually benifit me over any physical server we have going on at the moment, otherwise I would again have to make another purchase. I had surmised that having the datastores local for the veeam guest OS would be nearly identical to having a physical machine dedicated to veeam but with the added bonus of being able to fault load some other servers in our cluster to this server in an emergency situation where one of our VMware servers went down. Likewise if our storage array went down, since the veeam server is on a physical disk (Local Raid 5) and tied to that specific VM server I would likely still have access to the VMware server hosting it and hence figured I could still restore my array when it's fixed.

I was also looking at the same scenario for one of our domain controllers. Basically I was looking to keep "everything" off of the shared storage and put a few things on local disk on a specific VM server in the event that shared storage went down without having to worry about keeping a physical server in place to buy that security.

Does what I stated above make sense, or are there other considerations to the quote above that I am unaware of and should be. Basically I'd like to do whatever is deemed the best practice and if there is something else I am overlooking from above it would affect my recommendation to management in regards to any purchases we might need to make to implement our backup solution correctly. This is the one area (especially now that everything is on shared storage) that in my mind has to be perfect so I am open to all idea's on the best way possible to approach this.

Thanks again in advance for your reply, it's appreciated!

[Gostev]

Is the reason for this due to the issue of a storage array going down (that also hosts the veeam VM)

Exactly. You need to make sure Veeam Backup server is available in case of any disaster in your VMware department. Otherwise, you won't be able to do any recoveries whatsoever. And of course, virtual backup server will be far more suspected to any issues with your virtual infrastructure. ESX hosts can go down, virtual networking can brake, storage (that physical disk with Veeam VM guest OS) can die along with the host, etc. making you backup server unavailable to run VMs from backups or do recoveries.

On the other hand, physical server with DAS is very isolated thing which is very unlikely to be affected by issues in VMware infrastructure. Of course, it is as likely to brake, but the key here is not to have them broken at the same time (which would likely be the case with Veeam running in a VM).

Also, physical server is the easiest way for you to leverage DAS (and this will give you very fast locally attached backup target).

If you had shared storage for your backups (iSCSI), that would give you more options. For example, you could have redundant Veeam Backup servers on different ESX hosts, and in case of disaster, very quickly connect backup storage to another Veeam Backup VM via in-guest iSCSI initiator.

But still, I would feel safer with physical backup server when it comes to VMware business continuity. Otherwise, it feels like an army marshal riding in one of the tanks right on a battlefield. Sure, very cool and convenient... but very risky endeavor, too... much better idea to have him sitting in HQ far behind the front line.