Can current backup and replication technologies for virtual environments compete with old-fashioned backup solutions that are mostly file-level backups? Our contributor decided to find out. van Zanten created a test environment in which he put four virtual server backup technologies (in no particular order): Veeam Backup and Replication 3.1, Vizioncore vRanger Pro 4 Data Protection Platform, esXpress 3.6 VMware Backup, and VMware Data Recovery 1.0, to the test.
This was not performance testing, so you won't see columns and reporting on statistics, but usage testing – after all, isn't that what it's all about? If an admin has trouble using a product, he or she will probably choose a different product.
The backup and restore offering known as Vizioncore vRanger has been around since 2006, although the Hoffman Estates, Ill.-based company has been around since 2002. Its latest release was 4.0 (tested version is 184.108.40.20676), and on Sept. 25, Vizioncore Inc. released its 4.1 version. Unfortunately I did not have time to extensively test the new release, so for full disclosure purposes it's important that you know the following review is based on the version number provided above.
VRanger installs on Windows Server 2003 or Windows Server 2008 on a physical host or inside a virtual machine (VM). Like many products, it comes with a Microsoft SQL 2005 Express database, but you can also use an existing SQL 2005 or 2008 database.
Installing vRanger is a very easy "Next, next, finish exercise." A big plus in the installation procedure is the option to perform a manual database install. If you choose this option, the program will present a list of five SQL scripts that you can copy and paste into your favorite SQL editor and use them to create the database and tables. I love this option, because more and more products use SQL database, which is good, but too often they need too many permissions for onetime tasks. By delivering the SQL scripts to my database administrator, I can have him perform this task instead of going into a long battle of granting me administrator permissions on the "holy" SQL database.
The vRanger interface is slick. It is easy to navigate and provides a clear overview of successful and failed jobs. Of the four tested products, I preferred the vRanger interface the most, despite its quirks. For example, when you right-click on an "on demand" backup job, there is no option to start the job. To start it, you have to click the Run button in the top menu. It would have been more intuitive to create this as an option in the right-click menu.
The graphical user interface (GUI) offered several pleasant surprises. One excellent feature is the ability to see the backup speed, a progress indicator and extensive logging on the running jobs in just one view. You can get this information from other backup offerings, but not as easily as in vRanger. That said, the reports of finished jobs do not include the backup speed information, which is strange.
Another nice feature is a calendar view of all your scheduled jobs: simple but handy. [image: vranger-001.jpg]
Configuring vRanger Pro
After you complete the installation, the startup wizard guides you through the most important settings. Adding a vCenter server is an important step. Using the same wizard, the credentials for ESX hosts can be entered as well. Another nice feature is the ability to enter a set of credentials for multiple hosts at once, which saves time when working with many hosts.
Aside from the obligatory email settings, a configuration tab enables you to configure the job settings. On this tab, you can configure several credentials: the maximum allowed number of tasks running on vRanger, maximum per logical unit number (LUN), maximum per host and maximum per repository. You can also configure the minimum amount of free space needed on the host, which allows for snapshot growth on the data store. This feature is well thought-out. [image: vranger-002.jpg]
VRanger performs backup and data movement through the VMware Infrastructure application programming interfaces (APIs). This includes tasks such as creating a snapshot or checking free space on a data store. Data movement is done via a binary injection of a process into the service console (COS). Essentially, there is a process on the COS that communicates securely with the management interface to receive instructions and report status. It is responsible for the movement of data from a VM into a repository, such as a Common Internet File System (CIFS) share.
Since ESXi does not have a COS, it is not supported in vRanger 4.0. Future releases should deliver support for ESXi and VMware Consolidated Backup.
Schedule and quick backup
When creating a backup job, a wizard starts that guides you through the backup process. In the selection pane, you first select the data center, resource pool, cluster and folder or VM of which you want to make a backup. Next you can choose between a predefined template (SQL server, file server or Workstation) or a custom job. These predefined templates make the difference between quiescing the guest or not. There isn't really that much difference between them and since it also influences the name of the backup job, I usually go for the custom option. Vizioncore told me that these templates are already in the current product but will become more functional with newer releases when more features will be added and the difference between the templates becomes more obvious.
Next, an overview of the folder or the VMs that will be backed up displays with the hard disks next to it. Here you can select which Virtual Machine Disk Format (VMDKs) files should be included in the backup. The next step is the options page. Here you have five different options to select or deselect.
- Back up powered-on machines only. I'm not sure what I think of this option. Normally it
is on by default, which means you'd back up only running VMs. According to the vRanger manual, the
default is set this way because a powered-off machine will not include many changes and, by not
backing up powered-off VMs you can reduce backup time and space. On the other hand, you never know
when a VM was powered off. Was the last backup just a few minutes before power-off or has it been
running almost a full day after backup? I would prefer to back up a VM -- whether it's running or
- Check destination for free space. VRanger checks the destination for enough free space
to see whether the destination has at least enough space to hold all VM-related files without
compression, since the results of compression can differ.
- Compress backed-up files. Self-explanatory.
- Update notes with the latest backup results. After the backup, the notes field of a VM
will be filled with the results of the backup. In my review of Veeam Backup and Replication, I
mentioned that I'm no fan of this option. In vRanger. the default is to write into the notes field.
You can change this default behavior for all new jobs in the Tools menu.
- Enable guest quiescing. Make use of the quiescing option provided in VMware Tools to use Microsoft Visual Source Safe (VSS) to clear the file cache before making a snapshot.
After this screen, you click through to the Retention Policy Selection. Here you set how many save points should remain available to be restored.
What vRanger lacks is a system to save a number of weekly, monthly and yearly backups, just as with file backups in the physical world.
In this screen, the space-saving technology can be selected. Choose "None" to perform a full backup each time the job is run. A differential backup is defined as all the changed data blocks from the most current full backup. An incremental backup is all the changed blocks from the most current full backup, plus any incrementals already associated with that full backup. From the full, differential, or incremental blocks, vRanger Pro can restore a VM or files within the VM so long as the parent disks still remain. That means you cannot restore a VM from only an incremental backup; it requires the parent full backup as well as any parent incrementals.
The following steps allow you to define a schedule for the job and to name which repository the data should be written to. You can write to CIFS or Secure Shell SSH File Transfer Protocol (SFTP) volumes. The last step allows you to select the users that should receive an email report after the job runs. Now you're ready to commit your backup job.
What I like about the interface is that I can easily check which jobs apply to which VM (or data center or cluster, etc). Select the inventory screen and expand all folders and see all VMs in vCenter. Now, by clicking on a VM, you immediately see which backup jobs the VM is part of. If, for example, you have a folder called "Backups" that contains five VMs and you have the entire folder in a single backup job, you can see this on the folder and at the VM level. If you now add or remove a VM to this folder in vCenter, the VM will automatically be added or removed from this backup job. This is a useful feature.In other words, , you no longer have to go to your backup solution to add this VM to your backup job.
There is one caveat here as well, however. When you create a backup job of a VM in the "Hosts and Clusters" view or in the "VMs and Templates" view, the job is also visible in the other view. But when you create a folder backup, the job is only visible on the VM in the "VMs and Templates" view.
Retrieving data is essential for backup products, and with Vizioncore vRanger you have a wizard to help you through the process of restoring data. Normally, when you restore a VM, you first select it in the "My Inventory" view and right-click and select "Restore." In vRanger you get the option "Restore VM name" when you right-click a VM. Sounds good, but when the wizard starts, it first presents you with a screen to name the restore job. On the next page, you again have to search for the VM you wanted to back up, which is a process that could be streamlined. When you don't right-click a VM, instead clicking on the Add button in the top menu bar, you can select "Restore Job." The same wizard starts, but now I wouldn't expect it to know which VM I would like to check.
After selecting the VM you want to restore, you will see a list of backups that can be somewhat difficult to understand initially. The list that is presented gives an overview of all backups made for all VMs in the past 30 days (this is a default setting, but it can be changed). [image: vranger-004.jpg]
The column headers may suggest that this is grouped per VM and repository, but when closing all details, it is clear that this is probably based on the job name, although the name is not displayed. Since the name is not displayed and when multiple jobs contain the same VM, it is difficult to discover which save point to restore. For example, when you separate SQL backups in to two jobs, one for the database disks, on for the OS disks, this is what you might see: [image: vranger-005.jpg]
After I find the correct backup or multiple backups to restore, I select them and press next. Should you have selected multiple backups that might conflict with one another, a warning is displayed in this next screen called "Destination Selection." As the title says, you select the destination location here. In the first line of each VM, you select the destination host and the primary data store. The primary data store is where your .vmx files will be stored. In the following lines you see the VMDKs, and you can change the data store per vmdk file.
The next screen is the "Network Selection" wizard. I like this feature because it gives me the ability to restore a VM into an isolated VLAN (I like to call it "Quarantine"). If you restore a VM but have the original still running, they won't conflict. The rest of the wizard is straightforward and soon you will find your VM restored. Be warned, though, that the display name of the VM will be exactly the same as that the original name. So renaming it is a wise idea if you plan to use it in comparison with the older VM.
File level restore
Performing a file-level restore is difficult because it's hard to find not located in an intuitive place and thus hard to find. To do a file-level restore, you go to the Repository screen, find the backup you want to restore and then right-click the backup and choose File-Level Restore. A wizard will start and you can now select the disks, folders and files in the left-hand pane. On the right hand, you can select the destination. This can be a disk local to the vRanger host, but can also be a network share. You drag the files or folders from left to right, and the restore starts immediately. Restoring NT file system permissions is no problem and doesn't require extra action. After the restore completes, click Close and you're done.
One feature of file-level restores with a lot of subdirectories that is extremely inefficient: You can't stop a running job. Or rather, you can technically, but not in a practical way. In my test, I had a folder with 55 subdirectories with 20 GB worth of files. When starting the restore by dragging all 55 subdirectories to their destination, I wanted to close the window and continue with other tasks. This isn't possible. When performing a restore, the restore window remains the only active window. If you want to close it, you first have to stop the job. Seems simple, but vRanger created 55 little jobs that had to be stopped one by one. This aspect of file-level restores in vRanger should be addressed, as it can be extremely inefficient for an admin.
Vizioncore vRanger also has a reporting section. In this section, you can create your own report to see backup and restore results. Creating your own report sounds cool, but it isn't. The wizard helps you through the report creation actually only helps you select the columns to be displayed and the time frame (in the past week, the past 30 days, etc). When your report is finished, it will provide a list, but no details on why things went wrong. The report provides an overview of things the good and the bad in a given period of time, but the customization doesn't really add anything. What I really liked was a report of the job log. In the "My Jobs" pane you can click on a job and see details and logs. These are really useful but there is no easy way to print them, other than to copy and paste into your favorite editor.
A great addition I found in the manual and wasn't aware of while testing vRanger: PowerShell scripting support. In the manual you'll find a list of supported commands that allows you to create a backup job, a repository, restore job, see the daily schedule and many more. I really like how PowerShell can be used to do these various tasks. But then again, you might expect it from a company that is working hard on its Virtualization EcoShell freeware desktop application that assists admins with PowerShell scripting.
Gabrie van Zanten (VCP) has been in the IT industry for 12 years. Currently he is a virtualization architect for a worldwide consultancy company and has designed and maintained virtual infrastructures for a number of customers. He has written articles for magazines and frequently publishes in-depth articles at his weblog, GabesVirtualWorld.
This was first published in October 2009