Design question Veeam Repository

[StefanSpecht]

Hi,

Im just trying to find the best design for Veeam in our environment that has NFS storage.

I planned to install
- 1 VM for Veeam Management Console
- as many VMs for Veeam Proxy server as needed to meet our backup window. (Virtual Appliance mode, hotadd)
- Create one backup job for about 15 VMs

Now Im unsure about the Veeam Proxy server. I considered some options
1) Install as VM
a. Mount backup storage as iSCSI LUNs directly to the Windows Repository server or
b. Use VMDKs as backup destination

2) Install physical Repositorie(s)
- Mount iSCSI LUNs to the Windows repository

I think 1b would not be a good solution, because encapsulating my backup files into an extra layer would make things more complicated in the case of a failure.

The only advantage of 2 (in comparison to 1a) I can see, would be a better performance, because traffic don't need to go though ESXi network stack....
If all VMs would fail, bacause of a failure on production storage, my virtual repository server would not be affected, because running on 2nd Netapp filer (backup storage).

Our environments looks like follows:
- 10 ESXi Hosts in a Cluster
- 2TB NFS Datastores for VMs (NetApp)
- ~ 250 VMs (Used space ca 14TB)
- Separated NetApp Filer for Veeam backup data (nfs, iscsi, cifs)

[dellock6]

Hi Stefan,
there is a third way also: since NetApp can expose storage directly via CIFS, you can register it as a new veeam repository (CIFS share) and only have virtual proxies running in hotadd mode inside your cluster. You can save in this way on physical repositories. On the other side, you need to choose backup mode accordingly, since data processing is done by the proxy, so for example on reverse incremental, data will move back and forth between virtual proxy and repository.
Also, you cannot install the PowerNFS role on a CIFS share presented by a nas, so you Veeam central server would need to become your PowerNFS service itself.

Physical proxies in this case would be worst: they are far from the production storage, and having nfs there is no way to use direct san access, so data will flow to proxy before beeing elaborated (dedup, compression....). Proxy in general needs to be as near as possible to production storage; with NFS, a hotadd method is the best.

Luca.

[Vitaliy S.]

Now Im unsure about the Veeam Proxy server. I considered some options
1) Install as VM
a. Mount backup storage as iSCSI LUNs directly to the Windows Repository server or
b. Use VMDKs as backup destination

2) Install physical Repositorie(s)
- Mount iSCSI LUNs to the Windows repository

I guess you're referring to repositories configuration rather than proxies since you've stated that you're planning to install as many VMs for backup proxies as possible, right?

Here is an existing topic describing all pros and cons of option "1b" in great details, but you've already got the main disadvantage of it.

Me personally, I would suggest to proceed with 2nd option assuming you have a spare physical server to use as a backup repository (should be better for vPower based functionality).

Thanks!

[StefanSpecht]

I wrote "Now Im unsure about the Veeam Proxy server"...but you're right Vitaly, I meant "Repository Server". Sorry for that confusion.
Luca, thanks for the idea with the CIFS shares. I will try it out in our test lab. But the fact that I can't use it as a vPower server is not optimal.
At the moment my preference is also a physical server. We have an old DL385G6, 4x quad-core, in spare. That should give me a good vPower performance.

Should I create one big iSCSI Lun (40 TB)? Or more smaller LUNs?
One big LUN would be the easiest, of course...but I have concerns that, if I have problems with this LUN, ALL my backups are affected...

Thanks, Stefan

[Vitaliy S.]

Stefan,

Yes, single LUN would be the easiest option, though again you're spot on , putting all eggs in one basket is not the best approach you may want to proceed with. To be on the safe side, I would recommend to use one LUN and make sure you're offloading these backup files to another location. In this case you will also be protected from a NetApp device failure.

Thanks!