Veeam is one of the most innovative backup and recovery tools designed specifically for VMware and Hyper-V. They've also done a really good job of marketing this tool. In a matter of a couple of years, they've gone from "who's Veeam?" to the mindshare leader in this space. I'm not sure what they're actual market share is, and there are several other tools that are also making a name for themselves, but it's hard to think of a product that has more successfully captured the hearts and minds of their target market than Veeam.
They announced their vPower functionality at Tech Field Day in Seattle quite some time ago. To summarize, this is the ability to run a VM from their backup image of that VM. This opens up all sorts of different levels of functionality, such as instant VM recovery and automated, full testing of the viability of your backups of a given VM.
This is why I looked forward to their presentation at Tech Field Day 7. At first, I was not disappointed. They announced support for Hyper-V. Yay! They also announced further refinement of their vPower functionality. (They even gave me credit in one of the Powerpoint slides for some suggestion I made that they acted on.) They also hinted at a new version that is almost out, but wouldnt' really talk about it or show it. We definitely were not allowed to ask questions about it. Note to future Tech Field Day presenters: I can't think of a way to frustrate bloggers more than to tell them about a new version that you're not going to talk about, show us, or let us ask questions about. To make that matter worse, they kept hinting about the new version throughout the presentation, but then kept telling us we couldn't ask about it.
Where the wheels fell off the truck for me was when I brought up the fact that most Veeam customers use Backup Exec to back up Veeam. Another way to say that is that Veeam can't back itself up. This resulted in a 20 minute conversation during which I got quite riled up, while Doug Hazelmen kept looking at me like he had no idea why I had such an issue with this. You can watch the whole conversation here. It's from 1:24 to 1:45. He occasionally snickered, as if to say that the whole point of the discussion was ludicrious. At one point he actually said the statement that they can't back themselves up was "stupid." Yet he confirmed that the most common practice for Veeam customers was to use Backup Exec to back up Veeam.
Veeam data is stored in two places: the SQL database and the backup jobs directory. There is no way within the product to make a special backup of the SQL catalog so that it can be easily restored without creating a catch-22 situation. For example, one suggestion was to use one Veeam server to backup another Veeam server. That creates a catch-22 of having to restore one server before you can restore the other server. What if both servers are gone? Doug hinted that losing the SQL database just isn't that big of a deal because it's just job configuration information. You could just redo it if you lost it. Is this really a backup company talking to me?
The second part of their data is the backup jobs history. It has no catalog; everything that Veeam needs to know about the backups is stored with the backups. The question is: what happens if one or more of those files gets corrupted? What happens if some well-meaning admin looking for space deletes some jobs? What happens if a rogue administrator deletes all of them? As far as I could tell, Veeam has no way of recovering from this situation — which is why most Veeam customers use Backup Exec to back up Veeam.
Doug seemed to think that I was pushing for tape support. In a way, I was. Tape is still the least expensive way to get data offsite. In many organizations, it's the only way to get data offsite. They just have too much data to be able to afford a pipe big enough to replicate their backups — even if they have been deduplicated. That issue aside, I wasn't pushing so much for tape as I was a method for creating a backup of my backup. Files stored in filesystems get corrupted. It just happened to me today. For no apparent reason, a file whose modification time hadn't changed was telling me that it couldn't be copied. It was a movie file on an iMac. I can play the movie, but I can't copy the file. Weird. That's what files on filesystems do — and that's why we back them up. But the guys at Veeam just don't seem to get this, and that's why they frustrate me.
On one hand, I think the idea of a backup that can test itself in a totally automated fashion is completely awesome, and a lot of other areas of functionality are very impressive as well. On the other hand, them not understanding the issue I do have (and therefore not addressing it) is really frustrating. I hope we can work this out eventually, but they'll first have to stop calling what I'm saying "stupid." 😉
Continue reading →
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.
