VMware vDPA [EOL] Reviews

With the release of vSphere 5.1, VMware has retired VMware Data Recovery (VDR) and replaced it with vSphere Data Protection (VDP). From my experience, there were not a lot of fans of the old VMware Data Recovery product, so this is a welcomed change. I decided to give it a spin, and see how it stacks up and what quirks there are in the first release.

Installation

The virtual appliance comes in three options that correspond to the size of the storage available to store backups: .5TB, 1TB, and 2TB. This sizing is a drawback as there is no way to increase the capacity of the appliance’s attached storage after installation other than adding another appliance.

The appliance can only backup to the attached VMDK, and it cannot backup directly to CIFS, etc. Of course, the CIFS space could be presented as an NFS share to the ESXi host(s) and then the VMDK stored on top, but this is rather kludgy.

Each vCenter can support up to 10 VDP appliances and up to 100 VMs per appliance (1000 total). It’s worth noting that this is the supported limit and not a hard limitation; VMware has not done testing beyond the aforementioned number and will not support more. vCenter 5.1 and the Web Client are required, but will work with ESX >=4.0 hosts.

There are some interesting aspects of the configuration:

• Password requirements: It requires an exactly nine character (no less, no more) password.


• DNS: Both forward AND reverse lookups must work.

Usage

Management is done through the vSphere Web Client, and is not possible through the classic Windows client. The interface is rather straight to the point with not a lot of flare or advanced features.

Deduplication is built-in, but only works within each appliance; for example, data backed up on appliance[n] will not be deduped against data on appliance[n+1].

When creating backup jobs, there is no built-in way to exclude certain VMDKs: it is all or nothing. Six concurrent backups can occur at a time. There is also no way to tell the job not to quiesce the guest, etc.

Only one backup per virtual machine can run each day, as there is no granularity for multiple backups per day. This may be a problem for some.

File-level recovery requires logging in to the appliance from the guest VM that needs the file restored. Individual files cannot be restored from the appliance in the same manner a full virtual machine can be restored. Compared to other products, this is a very different way to restore individuals files, and is rather inconvenient especially for Linux guests that don’t have a GUI. There is no way to restore from the command-line currently.

Overall

The actual functionality of VDP is solid on a great base with EMC Avamar’s engine, and it’s a good product despite the aforementioned. It is limited in what it can do in this release, lacking many simple features that are available in other products (selecting only certain VMDKs, multiple backups scheduled per day, better file level recovery, more granular options on jobs,etc). It is also missing the advanced functionality in other products (running from backup, catalogue of files, etc). It’s likely a great fit for many SMB environments that just need no-frills VM backups, but until it matures in certain areas it is probably best to stick with Veeam, PHD Virtual, or others for more advanced needs.