jump to navigation

VDR Disaster Recovery Experiment June 23, 2011

Posted by audiomatron in Virtualization.

One of the greatest advantages of virtualization is the ability to not simply backup data, but to backup entire servers, because after all, in a virtual environment, servers are actually just a collection of files. This makes for a very quick way to restore entire virtual servers in the event of a disaster. There are several ways to do this, many of which come in the form of very robust software packages that leverage APIs within vSphere to very quickly backup, de-dupe, and restore virtual machines.

There is one piece backup software for VMWare that is awesome. I want it. However, I nearly had a heart attack when my vendor gave me the quote. I am a small business IT admin, after all. Unfortunately, most of the backup software is not sold at a small business price. Not to fear, though, all hope is not lost. For you see, all versions of vShpere from Essentials Plus (the one I have in my production environment) up come with VMWare Data Recovery (VDR).

VDR, while not as robust as some of the other options out there, provides an excellent way to backup virtual machines, especially considering the price!

Since the first time I heard about VDR, which was at a session on VDR at VMWorld 2010, I had wondered how a recovery from a complete meltdown might go. I was re-watching the VMWorld session on VDR, and the presenter mentioned that you could take a VDR destination with some backups on it, and restore it to another vSphere environment. Naturally, I had to try it. Here’s how it went:

I started by creating a VM in my production environment. The VM was a basic Windows 7 VM that I copied some data (in this case, pictures) to. My goal here was to back this VM up, and restore it in my test environment – an environment that is completely foreign to my production environment. Next, even though I already have an active VDR appliance in my production environment, I decided that, in the name of keeping everything clean and separate, I would set up a new VDR appliance. This is done by the following simple process:

1. Download the .iso for VDR. Mount it with a program like Poweriso.

2. If you haven’t already, install the plugin in your vSphere client on your local machine.

3. On the .iso is an OVF template for the VDR appliance. From your vSphere client, go to File -> deploy OVF template.

4. You will be presented with a wizard. At first it will prompt you for the location of the OVF template. In my case this was H:\VMwareDataRecovery-ovf-i386.

5. Follow the wizard through the creation process. The default options will do.

6. Power on the newly created VDR virtual appliance.

Now that my new VDR appliance was up and running, I needed a destination for my backup jobs. This can be either a CIFS share, or a .vmdk attached to the VDR appliance – the latter is recommended. So, I right clicked the VDR appliance, clicked edit settings, and from there I added a .vmdk the was appripriately sized to fit the VM(s) I wanted to back up. After creating the new .vmdk, I had to restart the VDR appliance so the appliance would see it. Next, from the vSphere client, I opened up VMWare Data Recovery from the home screen. From there, I connected to my new VDR appliance.

Under the configuration tab, under Destinations, we can now see the new virtual disk listed (unmounted). Select the virtual disk, and click mount.






Afterwards, the Virtual disk should be available to VDR as a destination.

Next, under the Backup tab, I created a new backup job, selecting only my test VM as a source, and the new virtual disk as a destination. I made sure not to give it a time window so that it would not back up on any sort of schedule. I then ran the job by right-clicking the job in the backup job list.

After the job was finished, I was ready to attempt the recovery on the test environment. First, I used Veeam fast SCP, pointed at both my production vCenter server and my lab vCenter server to copy the .vmdk where the backup of my test VM was now stored from the production environment to a datastore in the test environment. It is worth mentioning that you supposedly have to unmount the .vmdk in order to copy it. That did not work for me, as I actually had to shutdown the VDR appliance.

Once the .vmdk was copied, using the same method as described earlier, I created a VDR appliance in my lab environment, attached, and mounted the copied .vmdk to the new VDR appliance. Once in VDR in the vSphere client, under the restor tab, I could now see the restore points for my test VM that I backed up in the production environment.

However, I was asked whether I wanted to import the config from the other appliance. I answered yes. This hosed my VDR appliance, so I created a new one, attached the .vmdk, and this time answered no to that question. Now it was time to attempt a restore.

The restore wasn’t as straight forward as I had hoped, so I have provided some pictures to illustrate the process. If you’ll look at the picture on the right, you’ll see the restore points listed. Click the check box with the date of the restore point you want to restore. In this case there was only one.

After selecting the restore point, at the top and to the right of where the restore points are listed, click restore. You will be presented with a wizard. The first screen is the source selection. Verify that you have the desired source, and click next.

The destination selection is a little tricky (or maybe it is just tricky for me..).

Hover your cursor over the name of the VM and click the drop down arrow like this:








From the drop down menu, select your cluster. Do not click next yet. Now you need to select the destination datastore. This is what that looks like:








Just like selecting the cluster in the previous step, there will be drop down menus to select the destination data store for both the VM and its .vmdk

Click Next, and click restore. In my scenario, the restore did not take too long. After the restore completed, I was able to successfully power on the VM. It is worth noting that I had to edit settings on the VM and connect the NIC in order to get networking to work in the VM. Now, my VM was up and running on a completely new and foreign environment.

So What’s Next? Why did I do all of this?

Now that I have evidence that this will work, it is my hope that I can set up an ESXi host in one of my company’s remote offices along with some storage as a destination for VDR. See, VDR de-duplicates and uses change-block-tracking, so while the first backup is a total full backup, the subsequent backups should be very tiny. Theoretically, I should be able to do a full backup onsite, then take the destination to the offsite location and continue to back up my VMs. This would provide an excellent way to completely recover from, say, a natural disaster. All of our critical systems are virtual, so this could prove to be better than our current offsite data backup.




1. Virtualization – One Year Later « who made ME an expert anyway? - August 11, 2011

[…] Also worth mentioning is the experiment I did to test the disaster recovery capabilities of VDR. You can read about it here. […]

2. Mark Breaux - August 30, 2011

How is your backups to offsite VDR going? I currently backup my data using CDP so that I can have granular restore but I use VDR for full image backup. What kind of NAS are you using? thanks for the input.

audiomatron - August 31, 2011

The offsite VDR backup didn’t work out so well. We only have 1.5Mbps T1 pipe to our remote location. I backed up a few VMs onsite to a SnapServer NAS and took it offsite, but the integrity check got nowhere close to finishing after an entire day, so it wouldn’t have been practical. However, I just attended a session today at VMworld about VDR, and they now have the ability to schedule an integrity check. If i could get the integrity check to finish in the span of a weekend, I might be able to pull it off. As for what I’m using for a destination for my onsite VDR backups, I’m using regular ol’ CIFS shares on a Windows box, but I hope to get something better soon – preferably something iSCSI or NFS so I can backup to a vmdk.

3. Rosalind - July 7, 2014

It’s hard to find your website in google. I found it on 13 spot, you should build
quality backlinks , it will help you to rank to google top 10.
I know how to help you, just search in google – k2 seo

4. Sandra - September 12, 2014

Finally i quit my regular job, now i earn decent money
on-line you should try too, just search in google – slabs roulette system

5. Freda - September 14, 2014

I read a lot of interesting posts here. Probably you spend a lot of time writing, i know how to
save you a lot of work, there is an online tool that creates high quality, SEO friendly articles in seconds, just type in google – laranitas free content source

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: