Can current backup and replication technologies for virtual environments compete with old-fashioned backup solutions...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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.
I've toyed with PHD Virtual Technologies' esXpress since 2005. I remember one of the first releases that ran inside the ESX 2.5 Service Console with the DOS-based graphical user interface (GUI). Today, esXpress is offered as a virtual appliance with a Web-based GUI and virtual backup appliances that perform the meat of the work to back up virtual machines. Recently the Mount Arlington, N.J.-based company released version 3.6.7, which I tested for this review.
A virtual appliance has a couple of advantages: The requirements are easy to meet, and little installation of the backup tool is needed. The same goes for the appliance esXpress uses: You download it as an Open Virtualization Format (OVF) file and then import it into VMare's vCenter. The next step is to boot the appliance and set the desired IP address -- and that concludes the simple installation.
The first appliance to install is the esXpress GUI. This is how you connect your Web browser for management. EsXpress also features a deduplication appliance for saving storage on backups. Essentially it is the same OVF you import, but during configuration you set it to become a deduplication appliance. You can use these appliances as one method of installing esXpress; the manual also offers another installation method for small environments. It is possible to install only two RPMs in the service console of your ESX hosts and run esXpress manually from each console. Since the esXpress GUI and deduplication appliance each only need 1 GB of RAM and 8 GB of storage, I would use the appliance even in smaller environments, since it makes management much easier.
For backup operations, esXpress creates a virtual backup appliance that consumes 256 MB of RAM and 3 GB of disk space. A VBA is a virtual machine (VM) that is created by esXpress per host. Depending on the estimated backup load, there can be one to 16 VBAs per host for the Enterprise license, or a maximum of four for the Pro license. By using VBAs, during backups all load is placed on these VBAs and not inside the service console.
I like the fact that esXpress comes as a virtual appliance and the way the VBAs work. For this review, I haven't tested raw performance and compared it with other products, but esXpress seems fast when doing backups. Since the backup process runs through the VBA VMs, it is easier to monitor performance of your environment during backups and you can rest assured that it will never slow down your console and make your host unmanageable, which is a big plus.
The esXpress interface
The first connection to the Web interface presents you with a wizard that guides you through setting up your basic configuration. After the wizard finishes, the main GUI is straightforward as far as configuring hosts, backup targets, licenses and so on. When working with the deduplucation module, you have a second GUI that indicates which backups have been made using the deduplication module. Both Web interfaces are simple. There are no fancy Web 2.0 doohickeys or pull-up, roll-over and fall-down menus, just straight point-and-click, which I like because it makes it very fast.
For some actions, such as creating special VM backup settings, you still have to use the DOS-like console in the service console of the ESX host. I had hoped that in this version of esXpress this was no longer necessary because I don't want my backup admins to touch the ESX console. Actually, I don't want anyone to use the VMware service console unless there is a major problem with a host.
After the appliances are up and running and IP addresses have been configured, the Web-based GUI is available, and you can configure the esXpress environment. The first time you log on, a wizard guides you through all steps of entering your license, configuring one or more target teams, connecting targets to the target teams, configuring the global settings and configuring host groups. The wizard enables you to perform backups after you've finished. But without further configuration, backup will include all the VMs on your configured hosts.
Creating backup jobs in esXpress is a different process from that in other products. First, note that you cannot find any VMs in the interface; there is no tree view of vCenter to click on VMs and create backup jobs. EsXpress is host-oriented instead of VM-oriented, which is an outdated view. You cannot group VMs together to have them backed up to the same location because locations are host-oriented.
A backup location is called a target. This can be an FTP site, a Windows SMB share, a Secure Shell (SSH) connection to a Linux host or a deduplication appliance. Several targets can be grouped in a target team, and a host is always connected to just one target team. Next, you can group a number of hosts together into host groups, which then share a common set of settings.
At the host group level, you can configure the following:
- Basic settings that configure VBAs (number of VBAs, number of CPUs per VBA, etc)
- scheduling settings to set frequency and backup window;
- selection settings to configure which VMs to backup;
- replication settings;
- destination settings to configure the minimum free space needed, compression to be used and naming of the backup folders;
- email settings; and
- advanced settings.
At the selection settings, where you may have expected a list of VMs or folders, there is a simple text box in which you can add a filter criteria to run a Linux egrep on the VM names; all matching VMs will be included in the backup. There is a second field in which you can enter a filter to be used to exclude VMs from a backup. At first glance, this sounds good. For my test, I used it to back up a few test VMs which I renamed to "BCK-" followed by their normal names.
But let's look at the bigger picture. Such a selection filter is defined at host or host-group level, which implies that you can only have one filter per host group. Since VMs don't stick to hosts but to a cluster, this also implies that it makes sense to keep only host groups on the same clusters, otherwise a VM would fall under one policy at one moment and another policy the next moment.
This seriously limits how you do backups. If there are VMs with different backup schedules within a cluster, you can't define them because such a schedule is host-based. You can't then set up a cluster so that test VMs are written to cheap storage once a week and production VMs are backed up daily.
The only way to establish different backup schedules is by making a connection to the service console and starting the local PHDPHD client. Here you can configure VM-specific settings and change the target for the backup, apply different schedules or configure any other setting. In my view, this is not the way to go. You'll lose all management control and should you change a target, the change will not replicate down to the VM and the backup will fail.
Schedules and quick backup
In the host or host group settings, a schedule can be defined that allows backups to be made between a specific start and end time. This means that esXpress determines the exact start time of each job as long as both the start and end time are honored.
The option to rename a VM by adding the xNOW tag to it -- which triggers esXpress to kick off an on-demand backup job – is great. After a few minutes, the xNOW tag is removed, which means the backup has started. Further, if you change the name of the VM to include "x0," the VM will be excluded from the backup, setting x22 will force the backup to occur at 22:00, and additional options can be found in the x_Commands manual.
There are three ways to restore a complete VM: a command-line restore, restore through the console menu and an automatic mass restore. As with the backups, it turns out that when esXpress is put to the test, it is best to use the console instead of the Web-based GUI which, in my opinion, makes is less suitable for enterprise environments. But restoring through the console is simple, as is navigating through the menu.
You would first choose the Restore menu andthen choose to restore through the ESX console for a VMDK or choose to restore the vmx file only. Select the desired file and start the restore. When restoring a VMDK that is on a PHDD backup (deduplication) target, it will first download this backup to the local Virtual Machine File System (VMFS) volume and create an empty VMDK in which the backup will be imported. During this time there will be an opening in the firewall of the ESX host limited between the PHDD target and the host.
To perform a file-level restore, you connect to the Web interface of the deduplication appliance and go to the FLR tab. Here you can easily browse to the VM and the specific date on which the backup was made and browse through the files that have been backed up. Then select the files you want to restore and press "Save as .ZIP". The files will be gathered into a zip file and downloaded to your local computer. From here you open the ZIP and restore the files to the VM.
For a few simple files there is nothing wrong with this option, but it becomes more of a problem when doing a large file restore. I used about 25 GB of pictures to test the backup and restore. In this case, this means I will first download the file set as a zip file to my local computer and then upload the files again to their original location. Since even in large enterprises not all desktops are equipped with 1 GB NICs, it is quite a load on the network to first download and then upload 25 GB.
A better option is to log onto the VM on which files should be restored and immediately download the files. But this method may pose a problem. First, my test VM ran Windows 2003 SP2 and Internet Explorer 6. Apart from the fact that you might not be able to access the deduplication Web interface from the server network, IE 6 uses the C-drive as temporary location when downloading files. Downloading a huge backup file can quickly fill up the C drive of the server, which requires you to first move the temporary location of IE 6. And even then, if you change the download location to the disk on which you want to restore data, it might not work because the disk might not have enough room to hold the downloaded .zip file plus the restored data.
Email reporting is extensive. The daily backup report shows why VMs are skipped (e.g., they don't match the filter), and it shows the backup speed and sizes. Not only is the report shown in the email, but it's also attached as a PDF.
In the esXpress deduplication GUI, you can see data on performed backups, but this includes only those backups that have gone through the deduplication module. In other words, this set of backups may not include all backups that have been made. If you made console backups to a different target, it will be hard to find the location of the backup.
EsXpress produces quite a lot of logging info. If you want to know what went wrong in a backup or why, no backups are being made at all, you will find it in the logs. But the key word is find since it is hard to find the correct log file. The esXpress GUI action log reports on how host configuration went. The esXpress deduplication appliance has a daemon log, a delete log, a verify log, an updates log and n SMB log. You will find more detailed logging when you connect over SSH to the GUI appliance and the deduplication appliance. If that is not enough, you can also access the PHDPHD console in the service console of each host and see even more logging. This is where a common Linux problem pops up: You are sure the error is reported in the logs somewhere, but where do you start looking?
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.