Wow, long title. But first, a little introduction.

So I’ve said this numerous times to many people at Veeam but it has no really changed much, and why should it? Veeam hasn’t really had any viable competition until recently. I mean, there are many vendors out there who do kinda the same things but either they hadn’t solved the things that was wrong with Veeam or else they had some giant show stopper of sorts. A perfect example for me is TSM (now Spectrum Protect) for Virtual Environments. They had solved the scaling issues of Veeam but it had a giant caveat which was that the job had to be defined in a single 256 character string containing the retention, exclusions, inclusions of vms, clusters and alike. Okay, got a little sidetracked, back to the subject at hand.

So what is the issue with Veeam?

To explain this let’s skip backwards two years or so. Back to the good old days before ReFS was there to save the day and make our backup merges fast. Back to when there was no way to scale beyond a single repository other than making multiple jobs. Back when you couldn’t restore a vm from a job where a merge process was going on. Back when the only way to efficiently manage all this was by having a bunch of jobs with a bunch of repositories and them having some scripts running to evenly distribute things. Combine that with the requirement to build a platform that scaled to ingesting 3-4000 VMs every night while also being able to boot roughly 20% them the next morning if a storage array decided to have a bad day. You see where I’m going with this.

Back then, I remember starting to read about version 9.0 and I remember thinking that Scale-out Backup Repositories would solve my issues with scaling the storage backend and that the Per-VM Backup Chain would solve my issues with lockings when doing merges. The only thing that was then left was to find a way of scaling the underlying storage infrastructure to be able to cope with the merge processes and the potential booting of 20% of the vms. That was solved pretty easily, we bought ScaleIO. Moving on.

So then what happened. Veeam decided that those features were to be placed in the enterprise plus package. For those of you who don’t know the service provider programs for Veeam this represents a roughly 3x increase in price, thus making the entire thing much to expensive. I only needed the standard package since my use case was simple, I just wanted an image level backup of my VMs every night, nothing fancy.

So what is then the actual issue?

If you’re thinking scaling, you’re wrong. As of 9.0, Veeam fixed that issue and as of Windows Server 2016 with ReFS (with the initial bugs fixed) it wasn’t really that difficult. The actual issue is Veeam’s inability to distinguish between features that provides value to the end customers and features that provides me, the user/administrator, with the ability to efficiently manage and scale the platform.

So let’s ask the questions.

  • Will my customer accept a 3x increase in cost per VM (before storage consumption) because I need to scale the platform? No.
  • Am I willing to take on the extra cost per VM in order to save some time on managing the infrastructure. No. Party because of the fact that I would loose a bunch of money per VM but most importantly because the features are simply not worth it.

So what should Veeam have done?

Well, service providers are different than enterprises. VMware knows this so they created separate packages with different feature sets for us. Veeam on the other hand hasn’t really caught on to this (at least not officially). What I said to my local rep was that some features needs to be given to away for free in order to facilitate growth and to keep the customers. The SOBR and Per-VM Backup Chain are perfect examples. These are things that provide no value to the end users what so ever, so why have them be an issue for the middleman (the service provider).

It is in Veeams interest to give their service providers a platform that is easily scale-able so that we can focus on the main goal, to protect our customers (preferably with Veeam products from Veeams point of view). Veeam didn’t agree with this so that forced us to look elsewhere.

Look elsewhere?

So as I said it the beginning, Veeam didn’t really have a lot of competition, at least not from products that was looked at as being smarter than Veeam. We’ve looked at a few of them and we still stuck with Veeam because it was easy and fitted our use case well.

But at around 2 years ago, Rubrik was launched. Some months later, Cohesity came out. Both of them offered great solutions that fitted our needs. That being, simple to manage, simple to scale, built entirely with APIs from the ground up and many other nice things. We ended up going with Rubrik, why is a subject for another blog.

The thing that I wanted to point out here was that if Veeam had “just” fixed the issue, we probably wouldn’t had looked at the other options out there as seriously, which would have meant that our primary image level backup platform would have been Veeam.

If you boil it down, the facts are that currently we’re backing up roughly 2000 VMs a day on the Rubrik platform, which means that Veeam is missing out on 2000x “the price per VM per month” which adds up to a lot of money. We still haven’t moved a single managed Veeam customer to the platform (due to missing features from Rubrik which will arrive in Q4 2017) and when that happens the number of VMs a month will go towards 4000 pretty quickly. Worse yet, Veeam allowed a competitor to get a hold of a pretty valuable reference. They could probably do without the money, but reference customers tends to be the basis of getting new customers.

Anyways, just me two cents.