Veeam B&R Config Re-eval w/ Server Refresh

[itfnb]

Howdy!

I've got a server refresh coming up this year, and since I'm basically OCD, I like sorting through all the details before buying. I'm trying think through a few implications as I spec out our new hardware and would love some thoughts from the Veeam B&R angle. I'll try to keep it short, but like I said...I like details.

CURRENT SETUP = two Dell R720s as the main production cluster and a third older R710 as the "utility" host that has our Veeam VM and a few other odds and ends. All are on vSphere 5.5. The production hosts' storage is a 3PAR array and the utility host uses internal storage + a larger direct attached storage + HPE SAS tape library. The utility server also has a Fibre Channel connection to the 3PAR, but its FC HBAs are passed to the Veeam VM via DirectPath I/O. It may be goofy, but it really does work well for us.

NEW SETUP = Three "first class citizens" with 3 R730s. All three hosts will be configured the same except for one which will also include local storage to host Veeam and its repositories off the SAN again. I want to be able to use the third host with the 3PAR to help load balance our other VMs and give us more flexibility for things like a host failure, patching, etc...hence the "first class citizen" part.

That said...

*What should I do about my direct SAN access to Veeam? Have an additional HBA card in that host dedicated to DirectPath I/O?
*If not, what would performance potentially look like with using Hot-Add instead?
*Buy a 4th new host and dedicate it to Windows Server on bare metal to Veeam?

I don't really want to keep the R710 because even with my third new host "multi-tasking", the R730 will be so much faster than the almost 8-yr-old server it'd be replacing.

Thoughts? Did I ramble enough?!

Thanks!
-Jim

[DGrinev]

Hi Jim,

All three hosts will be configured the same except for one which will also include local storage to host Veeam and its repositories off the SAN again.

Are you going to store your backups inside the virtual disk on the VMFS or you will reformat one of the SAN LUNs to NTFS?

Are you using storage snapshots, as I can see you have 3PAR on board?

*If not, what would performance potentially look like with using Hot-Add instead?

It depends on different parameters, you should compare the numbers in the lab yourself, but usually Hot-add mode is comparable to Direct SAN.

A dedicated physical server for Veeam is necessary only if you are planning to use Direct SAN Access mode or you might have some security regulations, other than that feel free to go with a virtual server (it would be easier to restore it in case of the DR situation).

Thanks!

[itfnb]

*Yes, we store our initial nightly "backups inside the virtual disk on the VMFS". It's on the internal RAID10 storage in its host and off the SAN. That is formatted as one VMFS that is dedicated to the Veeam VM.
*Yes, we are using storage snapshots and Direct SAN Access. 3PAR > FC switches > FC HBA > R710 > vSphere DirectPath I/0 (pass-through) > Win Server 2012R2 VM > Veeam.
*Can I do storage snapshots with Hot-Add? I couldn't find an answer in searching the forum or KB. The storage snapshots is a much bigger deal for our nightly replication jobs since their duration is hours instead of minutes. This Veeam server is the Source Proxy and the Veeam server at our DR site is the Target Proxy for those jobs.

*Our nightly backup job of 35 VMs with about 100GB of incremental change takes about 20 min. right now. I just want to make sure Veeam processes don't take a step backwards as I make the rest of my vSphere environment more flexible.

Thanks!

[foggy]

*Yes, we store our initial nightly "backups inside the virtual disk on the VMFS". It's on the internal RAID10 storage in its host and off the SAN. That is formatted as one VMFS that is dedicated to the Veeam VM.

Then here's a good reading for you.

*Can I do storage snapshots with Hot-Add?

No, backup from storage snapshots is an alternative way of data retrieval, as opposed to traditional transport methods.

[itfnb]

Then here's a good reading for you.

That doesn't seem to end with anything very conclusive...no? I mean...you even support HPE's StoreOnce VSA...and though it looks like the transport data to the StoreOnce VSA would be CIFS...since it is the VSA, would its underlying data not be on VMFS if your'e using the vSphere flavor? https://www.hpe.com/h20195/v2/getpdf.as ... 374ENW.pdf

UPDATE: Yes, if you're using a host's internal storage, it would be VMFS: "StoreOnce VSA is supported on VMFS3, VMFS5 and NFS datastores. StoreOnce VSA is not supported on Raw Device Mapping (RDM)." http://h20566.www2.hpe.com/hpsc/doc/pub ... cale=en_US

No, backup from storage snapshots is an alternative way of data retrieval, as opposed to traditional transport methods.

I'm still a bit fuzzy. Are you saying that Backup from Storage Snapshots is a FOURTH kind of transport method, or that it's built upon Direct Storage Access...or something else?

I guess I could look at carving up my roles between a Veeam server VM and a proxy/repository with Direct SAN Access on bare metal...

[foggy]

I'm still a bit fuzzy. Are you saying that Backup from Storage Snapshots is a FOURTH kind of transport method, or that it's built upon Direct Storage Access...or something else?

Yes, think of it as of fourth transport method, which uses direct access to the storage but reads data from storage snapshots.

[blithespirit]

Backup from storage snapshots utilises the snaphot capability of your storage array to reduce the time the VMware snapshot is in place, it is great if you have VMs with lots of change over short periods of time such as when a vm is being backed up. The longer a VMware snapshot is held the longer it takes to merge back after it's finished with the backup. BfSS saves this by taking a storage snapshot after VMware takes it snapshot, VMware then releases its own snapshot, the storage snapshot is then mounted to the proxy "Directly" and the backup is used from that source. "Supported integrations only", if your change rates are small there is little benefit from using storage snapshots as VMware has little to do anyway.

Hotadd is another transport best suited for virtual proxies, this let's VMware take the snapshot and mounts the snapshotted vmdk file to the proxy as an extra drive (similar to directSAN) it then backs up direct from the mounted disk. In 9.5 there is a great performance improvement using this method with advantages as Foggy mentioned such as highly available proxies or mobile proxies.

If your using virtual proxies it would be best to use this method as your directpath is not resilient in the event you lose a host.

Leave your transport mode on your proxys set to automatic and it will try to find the best mode available if you stick to directpath, just it case it ever moves hosts

[Delo123]

Maybe a notebook with a few notes with things you want to archieve wouldn't be too bad.
Also the risks involved should be noted:
- backup to a production node
- backup to internal storage which is "only" readable within Vmware
- using directpath for backup
- GFS? Offloading?
- When needing 20 minutes for backup, the used transporttype shouldn't be among your first worries.
- have a good look at resiliency and think about what do in a real DR case.