VADP Backup Limitations

Hi PaddyX,

Thank you for your feedback on the VMware VADP support released with NetWorker 7.6 SP2. The support we’ve released has gone a long way to catching up with the features our customers expect for their VMware environments. In the NetWorker 7.6 SP2 release, we introduced these new VMware features:

Allan

When will NetWorker support automatically updating the CBT for each VM guest?

Manually having to update each virtual guest is painful!

Thanks

Richard

Hi Richard,

Let me do some research and I'll get back to you in day or two..

Thanks,

Allan

I'm also finding the new VADP limitations to be a step backwards from VCB. The biggest gripe is the new proxy must reside on a node that has access to the datastores, in our environment we use only Linux servers on standalone ESX Hosts within a DMZ infrastructure... where VCB allowed us to backup all the Linux VMs across all 10 ESX Hosts with a simple firewall change and one single VCB Proxy, now we are expected to create 10 Windows VADP Proxy servers, one on each ESX Host and create a bunch of firewall changes for each of the Windows VADP proxies. This is a major step backwards.

Internally we also run numerous clusters, so now a new Windows VADP Proxy server must be configured on every Cluster... another 8 VADP Proxies! So where we had 1 VCB before, now we need 18 VADP Proxies! Thats just nuts!

NetWorker's implementation of VADP uses underlying APIs from VMware that only support Windows today. This impacts NetWorker ability to support for Linux proxies. That's not to lay blame or accept blame, it's simply to help our users understand why the initial VADP implementation is exclusively weighted to Windows support. We are looking at options other than VMWare API to address market demand for Linux operability.

Changed Block Tracking (CBT) is an interesting discussion. Now that NW 7.6 SP2 has been available for a while we've learned that the market's expectation for this technology has less to do with the block based protection and more to do with consolidataing the changed blocks into an image for single-step recovery. In hind sight this makes sense - reduce the backup window and reduce the recovery window/steps. Still, this is not the use case we deisgned for and it will require engineering work to adjust NetWorker's implementation of CBT to satisfy the recovery use case.

With regard to the number of proxy servers I have more questions than answers. It's puzzling why it appears to take 18 VADP proxy servers to replace a single VCB proxy server, if all other variables are the same - # of VMs, ESX, clusters, etc. We have seen that VADP is inherently more efficient and flexible than VCB, and across the board we're not hearing of proliferation of proxy servers. Keep in mind that NetWorker's VADP implementation does provide for File Level Recovery (Windows) where VCB did not. This means you do have new configuration considerations to support backup/recovery options that weren't relevant with VCB. And certainly backup window and bandwidth are design requirements that can impact the number of proxy servers needed.

Best regards,

NetWorkerPM

Is this because you are working with a virtual proxy and hotadd transport mode?  nbd should be able to use ESX host networking to get you the files you need, without the need for a VADP proxy per un-shared datastore.

felixrising wrote: I'm also finding the new VADP limitations to be a step backwards from VCB. The biggest gripe is the new proxy must reside on a node that has access to the datastores, in our environment we use only Linux servers on standalone ESX Hosts within a DMZ infrastructure... where VCB allowed us to backup all the Linux VMs across all 10 ESX Hosts with a simple firewall change and one single VCB Proxy, now we are expected to create 10 Windows VADP Proxy servers, one on each ESX Host and create a bunch of firewall changes for each of the Windows VADP proxies. This is a major step backwards. Internally we also run numerous clusters, so now a new Windows VADP Proxy server must be configured on every Cluster... another 8 VADP Proxies! So where we had 1 VCB before, now we need 18 VADP Proxies! Thats just nuts!

Yeah, at first I was told that was the only way to do it, using hotadd or san... but subsequent research has shown that nbd/nbdssl should work like older VCB did..   I've been trying to get nbd/nbdssl working but with no success so far, time for a support call.

EDIT: I was just reviewing the "762_VMware_Integration_Guide.pdf" document which states: "The VADP proxy host must have access to all LUNs on the ESX server that is hosting the virtual machines".. which is where I got the idea that the VADP proxy must reside on the same host with access to the LUNs hosting datastores, that and a EMC Engineer indicated this to me in my initial discussions after having a Networker server fail unrecoverably. Its clear now that this refers to hotadd and san modes only, not nbd and nbdssl.

NetWorkerPM schrieb: NetWorker's implementation of VADP uses underlying APIs from VMware that only support Windows today. This impacts NetWorker ability to support for Linux proxies. That's not to lay blame or accept blame, it's simply to help our users understand why the initial VADP implementation is exclusively weighted to Windows support. We are looking at options other than VMWare API to address market demand for Linux operability.

Is this really true? As i unterstand, this was only a limitation of VCB which was a toolset based on Windows. VADP is rather an platform-independent VMware-API. The initial VMware Data Recovery Appliance was also based on Linux!?

Also it would be fine to support "File level recoveries for Linux VM image backups". This seems also supported by VADP (kb.vmware.com/kb/1021175). But as AllanW wrote at the top of this thread, this is already planned.

Is there any roadmap, when this features will appear in a future Network release?

Hello AllanW,

about a year is gone and Networker v8 Relase will be released in the near future. I have still the same questions. What has been changed regardings these features:

- File Level backup/recover on Linux-VMs

- Incremental Image-Backups

- Linux VADP-Proxy Support

- mixed "in guest backups" an VADP-Backups (still needed because File Level backup/restore ist not support on non-NTFS File-System)

Thanks a lot.