Veeam showed us their Backup and Replication product, Version 7.
Now, Veeam is a virtualisation centric company. They deal with multiple hypervisors, but they don’t deal with physical.
Veeam knows this, and does this deliberately. Doug Hazelman made this clear in his presentation.
So what’s to like about Veeam? Quite a bit, as it turns out.
The reverse roadmap was one of Doug’s slides. I love the reverse roadmap idea, for a few reasons.
Firstly, it means that the company checks up on itself. Looking at what you actually did, and when, is a great way to check on your progress towards your goals. If there’s a big difference between what you planned to do and what actually happened, you should know. Many companies are wilfully ignorant of this information, to their considerable detriment.
It highlights a kind of honesty about Veeam. They can’t put stuff up on a slide like that in front of an audience like Tech Field Day delegates if it’s propaganda and wishful thinking. They would get called out so fast it could be used to generate electricity.
Secondly, it plots a kind of trajectory that can help with planning the future. You can see trends over time (like presenting at Tech Field Day for major product launches), the spacing between big launches, and the clustering of features. You can use this explicit information, and also the whitespace around these datapoints, to estimate what the future will look like. You can use it as a sanity check on your future plans. Are you diverging markedly from the existing trajectory? Why? Is it necessary? Is it even possible? How?
Veeam have a free version! And it doesn’t suck!
It actually has all the features a smaller environment would need to keep their data safe. Smaller players are much more likely to be virtualised, because it saves on infrastructure costs, as well as making things more manageable.
Fast restore is really important for smaller organisations, because they tend not to have as much safety-margin with their own customers to play with as larger players do. If you only have two IT folk, and your order-processing system fails, they’re going to be flat out fixing that and therefore can’t help you find that email from Important Customer X from last week.
Huzzah! The number of times I’ve wrestled with integration issues with ageing backup software… well, I could tell you a tale or two. Mostly they’re held together with glorified shell scripts and gaffer tape anyway, so there’s no real reason not to have a decent API.
Being able to integrate a critical piece of infrastructure into the rest of whatever you have is such an important concept, I’m amazed it’s taken our industry this long to sort it out.
Roll on the American System of Manufacturing-ization of IT!
LTO3 tape format and above. It means you can stay entirely within Veeam instead of having to deal with another backup system to handle the tape side of things. That’s good.
The downside for now is that Veeam only support Windows supported tape devices. This is probably fine for smaller places, but anywhere with a lot of tape and something like an ACSLS server that manages the whole deal, well, it’s like to still be a complex mess to try to use Veeam backups and tape. Just leave it on disk.
Personally, while tape has some pluses (density, low-energy use when ejected, etc.) I vastly prefer on-disk storage for backups for a bunch of operational reasons. I haven’t formally run the numbers on it, but for long-lived systems with a lot of data, the operational management costs of failed tapes, lost tapes, drives malfunctioning, robot problems, and data-migration from old tapes (DLT anyone?) makes disk a much simpler proposition.
However, good on Veeam for listening to customers who wanted this feature. I just hope they’re careful to keep focussed on the virtual environment they’re so good at and don’t try to expand into competing head on against some of the wide-spectrum backup vendors. I’d be surprised if there would be enough ACSLS-using customers to make it worthwhile for Veeam to add that complexity into their codebase.
WAN Acceleration Built-In!
This makes backing up data from remote branch offices that much simpler. As @gostev explains in detail in his presentation, Veeam thought about this a lot, and have come up with a smart architecture for doing it. It some ways, it’s an accidental bonus due to the way Veeam manages backups and single-instance block storage in the first place. Veeam noticed how similar it is to WAN acceleration techniques, and so have added functionality to their product that is simultaneously super-useful, and completely technically aligned.
It just doesn’t make sense to back stuff up that hasn’t changed (and often never changes), and yet that’s what most backup products do. If you’ve already got 3 copies of the O/S in different places (because backup necessarily requires a certain level of redundancy) you don’t need to transfer that data again. You do need to make extra sure those 3 (or 6, or whatever) copies are kept safe, but that’s your classic risk/cost tradeoff.
Because of the size of the destination repository, you’re likely to get a major reduction in data transfer (and thus time!) for branch backups.
As I pointed out at the time, I think this is a new, third kind of backup beyond Full and Incremental. It’s a kind of Global Incremental, and I expect a lot more backup products to be including it as a matter of course in coming years.
There are some things that make me sad.
The lack of storage array support (only
3PAR HP StoreServ (neé 3PAR) and StoreVirtual (neé LeftHand)) and only for snapshots makes me sad. This isn’t really Veeam’s fault, and it’s more indicative of the utter failure of storage vendors to come together and support any kind of common API for manipulating their devices. Partly it’s because of the pace of change in storage devices (witness the explosion in storage startup companies in the past few years), and no one wants to tie themselves to some legacy API that limits your ability to add new and cool features.
Still ‘take a snapshot’ is such a fundamental concept that’s been around for so very very long that it just makes me grar that it’s always such a colossal pain in the ass to get backup software to talk to storage arrays. I mean, honestly, sort this shit out.
But I digress.
You can only have the REST API if you’re an Enterprise Plus customer. Because it costs more (and significantly more than free!) the smaller shops out there won’t be able to automate themselves as well as the bigger places.
Other features, like self-service and storage array snapshot integration, smaller players probably don’t need anyway. It’s just such a shame that one of the big drivers of innovation, an API, is denied to those who tend to be the most innovative users of these capabilities.
I think Veeam are doing themselves a disservice by only making the REST API available to the larger, and therefore slow-moving, bureaucratic, organisations. Give the API to a bunch of startups who run everything on virtual machines and watch what funky stuff they come up with that uses your gear. Which everyone else will then want, and guess what? You have to have Veeam to use it. Veeam is now more valuable.
Overall, Veeam are doing well for good reasons, and if your organisation is all or mostly virtual, definitely check their products out.
Update: Thanks to Hans De Leenheer @hansdeleenheer for correcting me on the storage arrays supported by Veeam.