PaddyX1
1 Nickel

VADP Backup Limitations

Hello,

I am reading VMware Integration Guide for the 7.6 SP2 RA. I do not understand why there are so many limitations, after waiting 2 years for Networker to support the vStorageAPI.

For example:

- File-level recovery is supported only on VMs that have a Windows operating system with the NTFS-5 file system.

- Note: When Changed Block tracking (CBT) is enabled, incremental and differential backups are supported only for Windows virtual machines, and all attached disks must be NTFS file systems.
- Note also that CBT-based incremental backups are always file based. Image level recovery from a CBT-based incremental backup is not supported.
- VADP-Proxy is only running on Windows
- For non-Windows VMs: If using traditional NetWorker client-based backups along with VADP image based backups for the same VM client, ensure that the browse policy for the client-based backups does not exceed the frequency of VADP image based backups. This practice is recommended because the indices of client-based backups may have to be removed prior to image-level recovery. ==> this seems to be a critial bug and doesn't exists with VCB-backup NW < 7.6.2 !!!
.
It seems that all this limitations are founded at EMC Networker not vStorageAPI. Other Backup solutions does not have these many limits. Are there any plans to correct this in the near future (maybe GA Version)?
Tags (3)
0 Kudos
10 Replies
AllanW1
2 Iron

Re: 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:

  • Integrated with vStorage API for Data Protection (VADP)
    • Option to leverage change block tracking (CBT) feature –reduces backup processing
  • Single Step VM Recovery

    • Same/different VC/ESX server
    • Original or new virtual machine
  • File Level Recoveries (FLR) from image backups
  • Single NetWorker VADP/FLR proxy options
    • Physical or virtual server
    • NetWorker Storage Node support, including with DD Boost
    • Windows Server 2008 R2, Windows Server 2008 or Windows Server 2003 OS support
  • Data Domain DD Boost or Avamar Grid deduplication backups

To reply directly to your concerns:

  • File level recoveries for Linux VM image backups is under development for both NetWorker and Avamar

  • Additional platforms for VADP proxies are under development for both NetWorker and Avamar. For NetWorker, support for Linux proxies is planned. For Avamar, support for Windows proxies is planned, along with support for the latest Windows operating systems with FLR proxies

  • The recent NetWorker 7.6S P2 RA Refresh Build and the upcoming GA release added improvements for Linux/UNIX VM’s, including better support for VADP and in-guest backups for the same VMs

  • Changed Block Tracking (CBT) support is good, but there is still some work to do in this area. One thing to consider is the use of NetWorker Dedicated Storage Nodes with DD Boost on the VADP Proxies. Our QA team is currently benchmarking this configuration and based upon the great DD Boost performance we are seeing with other applications, expect great VADP performance as well.

We appreciate your comments as they do have an impact on product direction.

Thanks,

Allan & the NetWorker Team

0 Kudos
rich641
1 Nickel

Re: VADP Backup Limitations

Allan

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

Manually having to update each virtual guest is painful!

Thanks

Richard

0 Kudos
rich641
1 Nickel

Re: VADP Backup Limitations

I realise we have a utility to update this, my real question is when will this utility be integrated into NetWorker.

Thanks

0 Kudos
AllanW1
2 Iron

Re: VADP Backup Limitations

Hi Richard,

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

Thanks,

Allan

0 Kudos
felixrising1
1 Copper

Re: VADP Backup Limitations

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!

0 Kudos
NetWorkerPM1
1 Nickel

Re: VADP Backup Limitations

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

evilensky
2 Bronze

Re: VADP Backup Limitations

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!

0 Kudos
felixrising1
1 Copper

Re: VADP Backup Limitations

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.

0 Kudos
Highlighted
PaddyX1
1 Nickel

Re: VADP Backup Limitations

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?

0 Kudos