Determining VMware Data Recovery’s Use Case

Rate this item
(0 votes)

With the recent news that VMware will be phasing out VMware Consolidated Backup and make the vStorage API for Data Recovery (VADR) the business continuity and full virtual machine backup enabler of the future, I want to better understand where VMware Data Recovery (vDR) fits in a virtual infrastructure today. This post outlines my notes as I explored both features and limitations of vDR in order to help explain how, where and when the product can be leveraged.

vSphere Editions needed for vDR

A great place to start is by understanding what licensed versions of vSphere 4 vDR can be used with. Using VMware’s vSphere edition comparison table you can clearly see that vDR is only available for use with the Essentials Plus, Advanced, Enterprise, and Enterprise Plus versions.

Although vDR is available in the Enterprise and Enterprise Plus editions, the limitations described in the next section present some design challenges for deploying vDR in larger environments.

Disclaimer: I am a systems engineer for Veeam Software.

Special Considerations For Using vDR

The following list of vDR limitations was taken from the VMware Data Recovery 1.1 Administration Guide:

Data Recovery does not support:

  • vCenter Server in Linked Mode.
  • IPv6 addresses. IPv4 addresses are required for the Data Recovery appliance.
  • NFS is only supported if the share is presented by an ESX Server and the VMDK is assigned to the Data Recovery appliance.
  • Hot adding disks with versions of vSphere that are not licensed for hot add.
  • Restoring linked clones.
  • Data Recover can backup linked clones, they are restored as unlinked clones.
  • Backing up virtual machines that are protected by VMware Fault Tolerance.
  • Backing up virtual machines that use VMware Workstation disk format.
  • Backing up virtual machines with 3rd party multi-pathing enabled.
  • Raw device mapped (RDM) disks in physical compatibility mode.
  • Data Recovery has been tested for use with:
  • One backup appliance for each vCenter instance.
  • Each backup appliance protecting up to 100 virtual machines.
  • VMDK or CIFS based deduplication stores of up to 1TB.
  • Up to two deduplication stores per backup appliance.
Not being able to backup VMs using FT or 3rd party multi-pathing, being limited to backing up only 100 VMs, and being restricted to only one vDR appliance per vCenter instance are some examples that push the solution to be most appropriate for the Mid (depending on how Mid is defined) to SMB customer. This is consistent with VMware’s marketing message around vDR and the vSphere editions designed for the mid to SMB companies as well.

Also from the Admin Guide, the following description about the 100 VM limitation clarifies the design restrictions further.

“Each Data recovery backup appliance can protect a total of 100 virtual machines. It is possible to create backup jobs that are configured to protect more than 100 virtual machines, but the backup appliance only protects 100 virtual machines and any additional virtual machines are omitted. It is possible to protect more than 100 virtual machines by installing additional backup appliances, but different backup appliances do not share information about backup jobs. As a result, it is possible to establish unintended configurations. For example, two Data Recovery backup appliances could be configured to protect a folder containing 200 virtual machines, but it is likely that some of the virtual machines would be backed up twice and some would not be backed up at all.”

What Can vDR Do In The Right Use Case?

So, if you manage one of the specified editions of VI 3.x or vSphere 4 from a single vCenter hosting less than 100 VMs  there are some great features to take advantage of.

vDR is a virtual appliance that integrates with vCenter / VirtualCenter. The appliance can be managed via a web interface or directly from the vSphere Client via a plug in. In either case the functionality is GUI based and straightforward.
Data Recovery can concurrently back up a maximum of eight virtual machines, and concurrently restore a maximum of eight virtual machines.
Backup jobs can be scheduled enabling “set it and forget it” functionality
For virtual machines created in vSphere 4.0, the Data Recovery appliance creates a quiesced snapshot of the
virtual machine during the backup.
The backups use the changed block tracking (CBT) functionality on the ESX hosts.

If the VM has been upgraded to use virtual hardware version 7 CBT is enabled by default
Check if CBT is enabled via the ctkEnabled value in the Advanced Settings section of the VM’s hardware properties. Set it to “True” to enable CBT

VSS is supported at various levels depending on which Windows OS is installed. See the following table from the Admin Guide:

[image]

vDR leverages VMware’s own deduplication technology to save storage space consumed by backups.
vDR has out of the box retention policies that pre configure back up jobs based on the retention cycle needed. As mentioned earlier, retention periods also enable “set it and forget it” functionality of backups.

Based on the CBT, dedupe and the retention policy features, VMware recommends that a vDR repository be created equal to the total space consumed by all VMs – not the total virtual disk space, but the actual disk in use sizes.

Backup targets can be a CIFS share, a RDM off the vDR VM, or encapsulated within a secondary VMDK assigned to the vDR VM.
vDR enables File Level Restores (FLR) via mounting indexed restore points as a volume on the computer with the FLR .exe installed
vDR can verify the successful back up and restore of any VM with a Restore Rehearsal feature. A new VM is created based on a backup as opposed to overwriting the original VM. The new VM name contains “rehearsal” and the vNIC is not attached when powered on.

updated 050110 – added bullet about CBT enabled by default in VMs with hardware ver 7 and added disclaimer of my employment at Veeam
Last modified on Thursday, 16 July 2015 18:52
Data Recovery Expert

Viktor S., Ph.D. (Electrical/Computer Engineering), was hired by DataRecoup, the international data recovery corporation, in 2012. Promoted to Engineering Senior Manager in 2010 and then to his current position, as C.I.O. of DataRecoup, in 2014. Responsible for the management of critical, high-priority RAID data recovery cases and the application of his expert, comprehensive knowledge in database data retrieval. He is also responsible for planning and implementing SEO/SEM and other internet-based marketing strategies. Currently, Viktor S., Ph.D., is focusing on the further development and expansion of DataRecoup’s major internet marketing campaign for their already successful proprietary software application “Data Recovery for Windows” (an application which he developed).

1 comment

Leave a comment

Make sure you enter the (*) required information where indicated. HTML code is not allowed.