VMware Data Recovery 1.2 released

Because of the news of the release of update 2 for VMware ESX 4.0, you may have missed the news about the release of VMware Data Recovery 1.2 on June 10th. The vDR team announceses it with great expectations: “While it is only a dot one increase in terms of version number (don’t ask, long story), all the minor changes that we implemented really do add up to a major change.”

The big new features are:

  • a file level restore client for Linux virtual machines
  • ability to run up to 10 vDR appliances per vCenter instance
  • ability to fast switch between the deployed appliances via the vSphere Client plug-in.

And miscellaneous vSphere Client Plug-In user interface enhancements including:

  • Be able to name a backup job during creation
  • Additional information about the current status of destination disks, including health and the degree of space savings provided by the deduplication store’s optimizations
  • Information about the datastroe from which virtual disks are backed up.

The biggest problems I’ve had my customers weren’t related to any of the things mentioned above. Customers are complaining about instability of the backup jobs. Every morning starts with the question: Did my backup ran or not? Other complaints are maintenance tasks hanging forever and therefore not allowing backups to be made and snapshots not being cleaned after backup.

 

Resolved issues

 

What I’m looking for is the list of issues that have been solved. For the complete list of resolved issues look here: http://www.vmware.com/support/vdr/doc/vdr_120_releasenotes.html and see below for the most important ones I found in this list:

The Backup Appliance Crashes When Backing Up Certain Disk Configurations. Virtual machines can have disks that are not multiples of single megabytes. For example, it is possible to create a disk that is 100.5 MBs. Normally, disks created using the vSphere Client are always a multiple of one MB. Some virtual machines that included disks whose size was not of multiple of one MB caused the backup appliance to crash. These disk sizes are now handled properly.

This being an issue is new to me but also explains why some P2V-ed VMs couldn’t be backed up until we re-P2Ved them in a different way.

Backups Failed to Complete As Expected. In certain situations, backups would fail to complete as expected, and no subsequent backups would occur. This issue has been resolved.

Although this is the biggest issue I constantly ran into with customers, there is little explanation on what was causing this, only real world practice will tell if the issue has been resolved now.

Looking at the list of known issues in this 1.2 release, I see one issue that you should especially pay attention to:

Imported Backup Jobs Backup All Disks. It is possible to create backup jobs that back up a subset of all disks in a source virtual machine. If such a backup job is imported into Data Recovery 1.2, the backup job behavior changes so all disks are backed up. To resolve this issue, modify backup jobs, restoring their original settings.

In other words, when you are now running vDR 1.1 and use the connected backup disk for vDR 1.2, it may occur that backup jobs for VMs that do not backup all disks, now will include a full VM backup.

 

CIFS changes

 

I also did a quick run comparing the administration guide for vDR 1.1 and vDR 1.2 and found that things have changed with CIFS. In the v1.1 admin guide on page 13 you can read that VMDK or CIFS based deduplication stores of up to 1TB have been tested. In v1.2 this has been changed to 500 GB on CIFS network shares (page 9).