UPDATE: This review is for version 2. I have posted a review of version 5.
I acquired a trial copy of Altaro Backup for Hyper-V, which enables all features for 30 days. The version I tested is 188.8.131.52. You can find its product pages and download links here. The super-short version of my review: this product has a lot of potential and would be a good choice for single-host systems run by small IT departments, but needs some more time to bake for anything larger.
- Relatively inexpensive, depending on alternatives being considered
- ReverseDelta technology
- If backing up a VM with SQL or Exchange Server, databases are committed
- Easy to use
- Restore VMs as a clone or to a different host
- 2 VM free version
- Installs only to the Hyper-V host; lacks a remote console
- Cluster-awareness is severely limited
- Trial requires registration
- Disk targets only
- Needs far more available space than will actually be needed for backups
Initial installation did not go well. For testing purposes, I designed a Windows Server 2008 R2 virtual system named “svbackup1” and added it to the domain. I installed Altaro on it, which was lightning fast with the only changeable option being the install location. When I accessed the console, it complained that I didn’t have any Hyper-V hosts. I looked for some way to target it to either of my cluster units. I poked through the documentation, which is easy to follow but not geared toward the highly technical (pro or con?). It never stated it outright, but through inference alone, I discovered that both this product and its management console must be installed directly to the Hyper-V host(s). That alone disqualifies it as a serious contender beyond small markets. You should never install applications to parent partitions (with the exception of tools used solely to manage the parent partition and/or its host hardware) for two reasons:
- Security: In many organizations, senior administrators are the only ones with direct access to servers while junior administrators or even help desk staff are made responsible for managing backup systems. Giving junior staff direct access to core hosts for the purpose of working with backups is a bad idea for the organizations that don’t outright forbid such practices.
- Resources: Locally installed applications will contend for memory and CPU resources with the guests. Altaro appears to be lightweight, but it’s very bad practice.
I installed to a Hyper-V host and tried again. After I got the console to open, it saw all the VMs on that host in the top pane. After a few moments, it then showed all the VMs on my other host with a message that I had to install Altaro there to work with those VMs. I did this. I then used its guidance to designate a “Backup Drive”, which is the target location for backups. The only option is to backup to disk, and it can be a local path or a UNC. It was at this point that I ran into the first UI clumsiness. When I was done, I expected an “OK” or an “Apply” or even a “Finish(ed)” button, but found a “Select Backup Drive” button instead. I’d already selected a backup drive; what I wanted to do was let the application know that I was happy with my selection and was done. This obviously isn’t a show-stopping issue, but this is one of several minor UX problems that make the application feel like it could use some more time in the polishing room. After that, it helpfully gets you to the right place to start setting up your backups. I clicked the User Guide link and was greeted with a message that it couldn’t open the CHM file (it didn’t say why, but the reason is that I’m using Hyper-V, not a full installation of Windows Server). It has a link for Support which is similarly useless in this situation. Since I had removed my test VM, I had to copy the CHM file to my desktop before I was able to access the documentation.
Setting up backups is pretty simple. You pick the VMs you want to make available for backups on the “Select Hyper-V Guest VMs” screen, which makes them available for configuration on the “Backup / Restore Guest VMs” screen. The scheduling options are very slim; you get to pick which days of the week and that’s it. You can set up different backup schedules for the same guest, but you still can only pick from days of the week. Since this isn’t a tape-based technology that benefits from grandiose schemes like GFS, this is probably not a crippling limitation.
The next option screen for backups is the “ReverseDelta” tab. Most previous disk-based systems calculate deltas; the original file is backed up and then individual changes to that file are tracked. If a restore is run, the original file is brought back and the changes are “played back” to arrive at the condition of the file as it was at the time the selected backup occurred. ReverseDelta works on the idea that you generally want newer, not older versions of the file, so, as its name states, it is the reverse of the traditional delta method. Altaro claims this tends to make restores quicker, and I have no doubt that they’re correct, but it would be tough to measure the total savings impact.
The next backup configuration tab is “Version Maintenance” which should be changed to make it more obvious that this is where people looking for retention policy settings should go. The settings are not as granular as I would like; you have to pick a time length (some people prefer total number of backups) and the list of choices is pretty short with a maximum of 2 years. You’re also required to indicate a maintenance time; it runs independently of the backup. This seems to be more trouble than convenience.
The last tab for backup configuration involves backing up anything in the virtual CD/DVD drive.
After setting up the initial VMs to test with, I went ahead and kicked off a manual run. As expected, it placed the CSV for the VM it was backing up into “Redirected Access” mode. As unexpected, it placed the CSV for the other VM I had selected into Redirected Access mode as well, even though it was running the backups sequentially. This behavior could have a measurable negative impact on VM performance during backups and needs to be changed.
The first thing the backup did was run a volume shadow copy operation, then it errored out with a message that the target didn’t have enough space. I would have liked for it to have made that determination before the relatively lengthy wait for the VSS operation (I acknowledge that it might not be possible), but the error status was true enough. The drive I’d created had less total space than what is allocated to the guest VMs I’d selected. Altaro did not tell me how far short I was. That’s OK in a controlled test environment with only two VMs being backed up, but it would be nice for it to report how much additional space I need. After failing on the VM that really was too big, it also decided to fail out the VM that wasn’t, which is also a recipe for problems in larger environments. I expanded the size of the target disk and waited. The console indicated it would try again, but gave no indication as to how long it was planning to wait (Hello, UX guys? Give me a countdown, and make retries configurable, please). I gave up after a few minutes and started it manually again. This time it began and ran without a problem. One of the VHDs is a 250GB fixed drive using about 10% of its capacity, and Altaro backed up the whole thing, which is the behavior that I expected but is mentioned here because others might find it surprising. Altaro is backing up the VHD, not digging inside to decipher allocation tables for slack space reduction.
Partway through, I LiveMigrated the VM to my other host. Altaro kept plugging away at the backup without even a hiccup. Very nice! After the backup completed, I tried to do it again, but then it complained that the VM had been relocated to another host. It appears that you either have to go through the trouble of ensuring your VMs are always on the same hosts when backups run, or you’ll have to set up a back up job for each VM on all hosts, and to do that you’ll have to migrate it to each one first. If that’s what you choose to do, you’ll have to deal with one error message per VM per backup cycle on each host that wasn’t running that VM at the time its schedule came up. While you can set up the notifications to only send error conditions, you cannot separate out this particular error. This is the second deal-breaking situation for me. If you don’t allow e-mail/log notification of errors, a senior administrator will have to manually verify each backup each day. If you do allow notifications, then you have to deal with getting multiple failed notices each day, which almost always results in actual error conditions going unnoticed.
I did not test the restore process, although I did examine the restore screens. You can restore a VM right back to the place it came from or you can restore a clone (different name, different VHD location, and an option to disable virtual NICs to avoid collisions). Under advanced options, you can mount a backed up VM to restore files from it. It does not simply browse into VHDs; you must select an entry from the back up list. You can import a backup from another host, presumably in the event that you are replacing a failed Hyper-V host, but also potentially useful if you run the backed up files off to tape for long-term storage. I did not see anything in the documentation indicating this latter usage is possible, so I’d definitely test it if such functionality is desired.
I also did not test the “Fire Drill” feature, although it looks quite interesting. This is basically a test of your restores complete with a reminder feature.
The final component is labeled “Reports” but it is very Spartan. It is little more than three displays of line items. You cannot export anything. The errors are kept separate from the successes. To be used seriously in an enterprise environment, this section will need UX attention and expanded features. I logged in to look at this section again, and the error section had been removed. I don’t like that at all.
After the manual backups completed, I left it alone for the night to see how the scheduled backup would work. It failed due to space issues again. Since the program doesn’t say how short I was, I can’t be certain, but I believe that because it doesn’t have enough room for 100% of the data, it failed the entire job, even though one of the VMs being backed up would have changed less than 1% and there was space to hold 50 times that amount. This means you’re always going to have to maintain a lot more free space than you’ll actually use just to keep this software happy. Whether or not that’s a deal-breaker for your organization will depend on how large your VMs are.
You may notice that I listed “Agentless” under both the Pros and the Cons sections. The only pro is that you don’t have to push out agents to servers or worry that they’ll consume a lot of resources, but agents usually aren’t that much of a problem anyway. The cons are that an agent would be nice on the hosts so that the whole console and application didn’t have to run on them. Agents could be useful on guests in cases in which the VSS readers/writers don’t work for whatever reason, causing Exchange or SQL databases to remain uncommitted; an agent could notify the guest OS or applications that a backup had occurred.
Pricing for Altaro is reasonable, depending on what you’re comparing it to. If you had to pay to backup each individual guest using traditional backup applications, Altaro is almost undoubtedly cheaper. If you’re looking at other options for backing up Hyper-V hosts, your pricing comparison will vary.
Overall, I think Altaro has a lot of potential and I hope to see them develop it further. If your shop allows those who manage the backups to access your Hyper-V hosts and you’re running a single host or have no clustered hosts, I would definitely place this on your consideration list. However, its shortcomings in an environment with clusters and/or tiered administrative staff are just too great for me to recommend it for any other purpose at this time.