Advice Request -B&Rv8 on a VM, direct SAN mode, offsite copy

[v33@m3r]

Hello,

Most of my experience with Veeam is on physical servers, and am looking to roll out a non-standard config for some new hardware and need some advice.. (I'd like to put ESXi on the new backup hardware for flexibility and additional cluster capacity if needed in an emergency or during patching)

Here is the breakdown
-ESXi5.5 backup host with loads of local storage, with Veeam running as a VM on a local datastore on this host. (I'll create some VMDKS on the same datastore, attach these to the Veeam VM, format with NTFS, and the repositories will be hosted there)
-The ESXi host that runs the Veeam VM will be connected to an iSCSI SAN & LUNS using vSphere Software iSCSI initiator (dedicated iscsi vswitch, with 4 nics connected, Round Robin & multipathing).
-The Veeam VM will have a NIC that is added to this iSCSI vSwitch, giving it a route to the SAN, but windows will be using the Microsoft iSCSI initiator to log onto the LUNs to use Direct-SAN mode.
-The VMs will be backed up from the SAN, to the repositories on the VMDK files attached to the VM
-There will also be replicas sent to the local datastores. (Backups and replicas going to same hardware). If I leave ESXi on this new hardware, then I can send replicas to it, as I had no replicas before - just backups
-I'll also be looking to use the WAN accelerator option to copy the backups offsite to site B, to a similar ESXi host & Veeam VM with repository role on the remote site (but not replicating to site B)

Has anyone tried something like this or have any advice for me?

Thanks very much for your help

[Vitaliy S.]

Hello,

Everything looks good to me, except for these two statements:

-ESXi5.5 backup host with loads of local storage, with Veeam running as a VM on a local datastore on this host. (I'll create some VMDKS on the same datastore, attach these to the Veeam VM, format with NTFS, and the repositories will be hosted there)
....
-There will also be replicas sent to the local datastores. (Backups and replicas going to same hardware). If I leave ESXi on this new hardware, then I can send replicas to it, as I had no replicas before - just backups

Storing all your backups and moreover replica VMs on the same datastor/hardware cannot be considered as best practice. It is like putting all eggs in one basket, in other words, if something happens to your local datastore you will lose all your data (production and backups). I would suggest using some external storage for your backups and a separate host for VM replicas.

Here is a couple of links to read for further details > Don't Store Backups on VMFS...But why not? and Recommendations for backup storage, backup target

Thank you!

[v33@m3r]

Hi Vitaliy S,
Thanks for your input and advice - much appreciated.

I had a look at your really helpful links at the end of your post, and I can't see any reason why (in my scenario) I should not have my NTFS volume on a VMDK as opposed to just bare metal. I have one Dell R730xd with loads of local storage, and I'm going to put ESXi on it for flexibility. Veeam and the repositories will be on VMDKs stored on this server (obviously underneath this, there is a VMFS datastore, and underneath that, there is a local RAID array). I can see nothing online that says that this is slower (or less stable) than it would be if i put windows (bare metal install) on the box, and create my NTFS partition directly on the RAID array, and place my repositories on the volume

To address your points at the start of your post:
The ESXi host in question will be backing up the VMs from a SAN, so having the backups on the local datastore is allready 'Off-SAN'. (This ESXi host is also in a different Comms room)
I will also have a secondary copy job to send the backups offsite to a DR location, so as far as backup eggs and baskets are concerned, i should be covered .. would you agree?

The Veeam Replicas are also replicating the VMs 'off-SAN' to this local datastore in the second comms room. Unfortunately, I don't have another host to use solely for VM replicas on this site. If my ESXi host fails, i guess i'll have to rebuild it fast, but at least i would have the copies of my backups in an offsite repository.
If my SAN fails before i get a chance to get the Veeam replica jobs re-created and working again, i would be very unlucky, but I guess i can invoke DR!! (i also have SAN-SAN replication running to a DR Location over a VPN WAN Link)

Thanks again. Comments from anyone greatly appreciated

[foggy]

You seem to be covered in terms of "all eggs in one basket" concern, however having everything under a single host makes restore a bit longer (host rebuild is required).

[Vitaliy S.]

I can see nothing online that says that this is slower (or less stable) than it would be if i put windows (bare metal install) on the box, and create my NTFS partition directly on the RAID array, and place my repositories on the volume

I just wanted to save you time that would be required for installing ESXi host, if the primary host and backup server go down and you will need to do a restore. Accessing NTFS LUN from newly deployed backup server (for example, on your PC/laptop) will be much quicker.

To address your points at the start of your post:
The ESXi host in question will be backing up the VMs from a SAN, so having the backups on the local datastore is allready 'Off-SAN'. (This ESXi host is also in a different Comms room)
I will also have a secondary copy job to send the backups offsite to a DR location, so as far as backup eggs and baskets are concerned, i should be covered .. would you agree?

Yes, you should be covered from this standpoint.

The Veeam Replicas are also replicating the VMs 'off-SAN' to this local datastore in the second comms room. Unfortunately, I don't have another host to use solely for VM replicas on this site. If my ESXi host fails, i guess i'll have to rebuild it fast, but at least i would have the copies of my backups in an offsite repository.
If my SAN fails before i get a chance to get the Veeam replica jobs re-created and working again, i would be very unlucky, but I guess i can invoke DR!! (i also have SAN-SAN replication running to a DR Location over a VPN WAN Link)

In this case, you should be good to go with your plan, thanks for additional clarifications!