I like to try and save my employer money when possible. I am of the opinion I would be doing them a disservice if I didn’t examine and evaluate a product that we paid for. Our company decided to take the plunge and upgrade all of our licensing to vSphere Enterprise Plus. There is a new backup/data protection product that was introduced with this recent release. Here is the technical definition of VMware Data Recovery from the administration guide:
VMware® Data Recovery creates backups of virtual machines without interrupting their use or the data and services they provide. Data Recovery manages existing backups, removing backups as they become older. It
also supports deduplication to remove redundant data.
Data Recovery is built on the VMware vStorage API for Data Protection. It is integrated with VMware vCenter Server, allowing you to centralize the scheduling of backup jobs. Integration with vCenter Server also enables virtual machines to be backed up, even when they are moved using VMware VMotion™ or VMware
Distributed Resource Scheduler (DRS).
Sounds pretty good right? You get a backup application (with de-dup!) that could possibly displace your primary method of backups built specifically for VMware? I did a little digging in the community and was disappointed to learn that vDR is not exactly an enterprise product. A lot of the feedback from other VMware engineers was “it’s a 1.0 product and is designed for a small installations”. The maximum supported virtual machine backup configuration is 100 virtual machines.
I decide to check it out for myself and see if it was a fit for our environment and might possibly alleviate some of our backup problems. Our primary site is rather large, but we are now implementing vSphere at our smaller satellite locations and this might be a fit for a smaller office configuration.
The installation was quite easy, VMware has provided another great virtual appliance that can be downloaded from their website. After you import the virtual appliance via Virtual center and assign the host a static IP address, you then need to install the VC plug-in so you can manage your newly installed appliance.
After I ran through the installation and configuration I was disappointed to discover that I couldn’t get VDR to launch. I kept getting prompted for authentication credentials which was odd. I thought maybe I had incorrectly set something up so I went back and reviewed the administration guide. Upon closer examination (RTFM) I discovered that vDR doesn’t support Virtual Center running in linked mode. To my dismay, we are running in a VC linked mode in anticipation of a Site Recovery Manager implementation. Our remote sites are managed by our primary site Virtual Center to save costs. I discovered a work around by pointing the VC client to the ESX server that is managing the vDR appliance. This would only give me access to backup other virtual machines hosted on the same ESX host so I could continue my testing. I hope this is something that future versions of the product will address and fix.
Once you launch the vDR console, you are immediately prompted by a configuration wizard to begin setting up your environment. Here are the following steps in the order they are presented:
- Select your Virtual Machines to backup.
- Select your destination (CIFS share, attached vmdk, or RDM).
- Select your backup window.
- Select your retention policy.
All of these are straight forward and don’t require much discussion. The only step I found a little confusing was the retention policy. Personally I would have preferred something a little more technical than “Few/More/Many”.
The retention Policy radio buttons are pre-defined settings and will change the policy details below. Change the buttons and you can see the variables change and what each setting will mean in terms of your destination data storage. Use caution here as each vDR appliance can only support up to 1TB in data store size, with a maximum of two stores.
The underlying backup technology behind vDR is the new vStorage API (Not VCB), it takes advantage of a new feature called change block tracking. After the first full backup is performed, Change block tracking examines the virtual disk being backed up and only backs up the differences from the first backup. This means less backup traffic going across your network.
I selected a CIFS/Windows share at our disaster recovery site to perform the backup testing. The test share was a ~600GB, 5+1 (10K) of locally attached SCSI storage on a HP DL380. I selected a couple of Windows virtual machines to test with and kicked off the backup jobs. Below is a screenshot of the reporting window for vDR (sorry for all the censorship).
The jobs seemed to run pretty slow in general, but completed successfully without errors (the error listed above is because of my linked virtual center configuration). In my opinion the reporting interface is lacking some details. I would have liked to have seen what throughput I was getting during the backups. The only way I could see the throughput was by monitoring the windows host that was housing the data store. I would have liked a more detailed task status, so I could tell what was going on through out the backup operation. Data de-duplication ratio would have been another great detail to see. This could help determine the total backup and estimated completion time of each virtual machine, which is another variable I found to be missing.
There are two approaches to restoring data using vDR, the first method is a full system restore. This method will recover the entire virtual machine, system state and all corresponding data. When performing a full system restore you can restore the data to an alternate esx host, data store, and decide if you wish the network interface connected or not. I even found that you can change the virtual disk node, and select an alternate SCSI path to recover your disk path too.
The second option is a file level restore (FLR), which typically most people would tend use on a more regular basis. Unfortunately the vDR console can’t recover individual files without some additional configuration. You need to install “VMwareRestoreClient.exe” executable on a virtual machine, which then will give you the ability to browse your data store contents and select individual files to recover. I anticipate that we will see the FLR components get rolled into the vDR console in a future release.
VMware Data Recovery lacks a lot of critical pieces that an enterprise backup application should and needs to provide. The product is a great start for smaller VMware implementations, but even at that I could see it quickly being outgrown. Here are the areas I would love to see improved on in future releases of the product:
- Need support for linked Virtual Center’s. Personally I could use this product at some of our smaller locations but can’t leverage vDR since we are running in a linked mode.
- Need to support larger capacity of virtual machines. 100 virtual machines is not enough, the product needs to scale to support a larger VMware implementation (not necessarily Enterprise).
- Need support for larger data stores. 1TB is not a lot of space when you are going to be backing multiple virtual machines up and retaining their data for longer periods of time.
- Need support for more data stores per vDR appliance. Again this goes back to scale, storage growth is exponential in our current environment.
- Support for a global vDR manager. I would love to see VMware develop a central master or parent vDR console that would allow you to manage your children appliances, and the data stores that they manage.
- Single console for both full system restores and file level restores.
VMware Data Recovery comes with all versions of VMware vSphere except for vSphere standard. This is a great entry level backup solution with de-duplication included. I am excited to see the product develop into a more mature product that can scale with some bigger environments. I also feel that including vDR in the standard version of vSphere would only help the SMB market embrace virtualization at a higher adoption rate.