Test driving VMware Data Recovery (vDR)


One of the most important things next to virtualizing all those physical servers is backing them up and restoring them. This of course is not a great feat with virtualization since basically the servers are now a group of files. There are and have been for some time full featured backup/restore products out there in the market but Vmware has released their virtual appliance “Vmware Data Recovery” currently at version 1.0.2 with vSphere4 Advanced, Enterprise, and Enterprise Plus. I was actually impressed at how functional and the ease of setup with the product at version 1.x.

So, I will probably do a video on this but pretty much you will need to:

  • Download the appliance and vdrfilerestore.exe from Vmware.
  • Import the product into vCenter.
  • ***Note: Make sure that the bios has the correct time. I ended up with backups in the future because the time was wrong.
  • ***Note: I also updated the virtual hardware to version 7.
  • ***Note: Since the appliance is CentOS5, I changed the guest OS to RHEL5, and resize the appliance to my needs (cpu/mem).
  • Install the VDR plugin.

Once this is done you will see the new feature button added to the vCenter Home area under “Solutions and Applications “. Click in this area and you will have to add the vDR appliance either using the name or dns name. ***Note: DNS resolution and network connectivity is key. I had a few issues like (error- 3948) which prevented me from doing backups which were all resolved by fixing the network. Make sure that the vDR appliance can communicate with your ESX hosts. The look and feel is no different with your objects on the left and information on the right. At first I thought it was too plan being used to using CA Arcserve.

So before setting up a backup job you’ll need to setup a destination location. This location is were your backups are store in a dedupped and none recognizable format. So don’t expect to see *.vmdk files in plain sight to do restores. The datastore can be either a local volume (vmdk) or NFS location and you can add them as needed. I tested with both the local volume and a windows share with successful results. The network share was slower than the local volume for backups and restores. When backing up to the local volume unless you have a dedicated datestore you have to take into account the added i/o which could affect other vm guests when backups are running.***Note: I haven’t tested this yet but there is no reason you could not replicate the dedup destination to a remote site for disaster recovery purposes since the destination location used by vDR is recognized by the vDR appliance. Your then giving an option to import the information to the new vDR appliance for restore purposes.

Setting up a backup job was simple. You can select the entire environment to backup or just one vm guest then add the destination, backup window, and retention policy. The jobs can be edited later plus you can also right a vm guest and add it to a new or current job plus remove it from a job.

The simple breakdown or process of what happens when a backup is performed is that the vm guest has a snapshot created, the vDR appliance reconfigures itself and attachs the vmdk that it’s going to backup to it’s virtual hardware, the vDR dedups the data and saves it to the destination you choose, then the vmdk is removed from the vDR, and lastly removes the snapshot.

Restores are pretty easy as well. You can either right click the vm guest or use the Restore tab. A good to have feature is that the option for a “Restore Rehearsal” can be performed. This allows you to restore the entire vm guest with the option to rename and reconfigure in vCenter without downtime of the original just to make sure the restore process would really work. You can select the restore point from the gui from different points in time all the back to your retention limits.

There is also the ability to restore at the file level. At this time it is experimental. I have seen post were others have had issues but it works well for me. You have to run the “vdrfilerestore.exe” in a command prompt which the correct switches “vdrfilerestore.exe -a <vdr server>” from the vm guest that you want to do a file level restore from. You are prompted to select the restore point, then it mounts the restore to a drive letter in the OS of the vm guest. Then you basically browse the drive and copy what you need. Once you are done, the drive can be unmounted from the command prompt. See this in action here.

I’d like to see the ability to mount a restore point from vCenter to any vm guest i choose to do a file level restore. Sometimes data is not needed to be restored to its origin. I’d also like to see more reporting information around how much deduplication is saving me or the % of deduplication per job and historically. And the addition of Alerts so that I could either send emails or run a script when a job fails would also be nice. Overall though, I think Vmware has done a good job with this virtual appliance in version 1.x.

1 comment

Add yours

Comments are closed.