HotAdd Transfer Method

Thanks.

Just to clarify the functionality, the VM Backup Host reads the full VMDK in SAN transfer as this is going to MSDP it also deduplicates the data. So this time of this full vmdk read across the SAN is something I am keen to reduce due to the size of our VM estate.

I was lead to believe with HotAdd the HotAdd VM would also read the full VMDK over the SAN, but with Client Side Deduplication enabled it would only send deduplicated data to the VM Backup Host, if this is a 10G LAN connection, then this maybe faster than SAN transfer in cases?

If not using HotAdd then I would need more physical VM Backup hosts, which would SAN transfer from ESX to Backup Host but then LAN transfer into the existing MSDP.

Hotadd uses one of the VMs, so it cannot do SAN transfer. Hotadd does LAN only.

Hotadd is useful in NBU 7.1 when there is no physical Windows backup host available.

Detailed info about hotadd in the VM Admin Guide: http://www.symantec.com/docs/DOC3663

Make sure you are following best practice and not doing more than about 4 snapshots per each datastore at a time. You can set this in global settings for the vm backup host (I think..drawing a blank on exactly where).

Also, there are some fixes for VMware backups in 7.5 if you are interested in an upgrade.

but with Client Side Deduplication enabled it would only send deduplicated data to the VM Backup Host, if this is a 10G LAN connection, then this maybe faster than SAN transfer in cases?

VMware Backup Host read full vmdk in hostadd mode, too. Be sure VMware Backup Host is the host which read vmdk. It seems that you called  the host you used as VMware Backup Host in SAN transport method now. And it is also the media server, I suppose.

Definition of VMware Backup Host(say Proxy) is as above - the host which read data from VMware world. In hotadd method, it must be VM. This VM read full vmdk directly from datastore, and put it into NetBackup world.

You can enable client-side deduplication in hotadd, but it only reduces data tranfser from Proxy to media servers. It does not reduce amount of data read from datastore, and does not ensure the reduction of backup time. Time of backup may increase because CPU and memory resources on hotadd VM is typically less than physical host prepared for MSDP, so dedup operation takes more time to complete.

Here is a picture of SAN transport and hotadd transport.

In my reply to your private message a couple of months ago, I explained the following:

The overall VM backup time of the entire environment will not be shortened if you simply replace 1x physical MSDP VMware backup host with 1x VM HotAdd+ClientDedup backup host, especially when the HotAdd backup host will have to go through an extra step of having to send its processed(dedup'd) data via LAN to the MSDP.

By simply replacing that with the other, you still only have one host to handle the deduplication processing.

It then follows that if you increase the number of hosts to spread out the deduplication workload, the overall backup time could be shortened.

How does one increase the number of VMware backup hosts that handle dedpulication, without having to deploy more physical hosts?
A: Why, to make use of the ESX hosts' processing resources, of course. That is if you are happy to use some of the ESXs' resources for this purpose.

How does one make an ESX host perform deduplication jobs for NetBackup during VMware backups?
A: Deploy/designate a specific VM on the ESX host as a VMware backup host, use HotAdd transport, and also enable ClientDedup.

Suppose you now have 1x physical MSDP and 3x HotAdd+ClientDedup backup hosts on separate ESXs, you now have a total of 4 hosts that share your NetBackup deduplication workload.

Suppose it used to take 6 hours for a single backup host (the physical MSDP) to backup 100 VMs, now with 4 backup hosts it could take less than 6 hours if you spread out the backup workload by assigning 25 VMs each to each of the backup hosts.
You now have 4 hosts processing the deduplication simultaneously that contribute to helping to finish backing up the 100 VMs quicker than when there was only 1 host doing everything.

The backup time won't scale linearly all the way down to 1.5 hours because of various overheads, such as the LAN transfers between the HotAdd hosts to the MSDP, the dedup ratios, the processing capacity of each of the ESX running the HotAdd VMs, and the I/O capacity of the Datastore where all the data is come from.

Regardless of whether it is SAN or HotAdd transport, the vmdk snapshots will still somehow have to be transported IN FULL from the Datastore to a host running NetBackup components.
Just because HotAdd is deployed, it does not mean that the Datastore will be magically sending out less data.

Yes Rusty I am using resource limits set to best practice.

Thanks Yasuhisa, what you have explained is what I was specifically trying to confirm, the process of data transfer.

RLeon - Hello, thanks for your input. A discussed previously, yes I am looking at putting HotAdd's in each of my VM Clusters or on each ESX host in the larger clusters, I want the HotAdd's to take care of the dedup on the client side and then send the data to media servers. So rather than 2 VM Backup Hosts, I would have 10 etc HotAdd's to do the dedup and the VM Backup Hosts would just be used as Media Servers to write to MSDP. This is where the time saving would be, however if we have to use SAN, then I will need to add in more physical VM Backup Hosts.

Thanks all for you input.