Why I switched from Veeam to Nakivo: Deduplication!

I have been a happy Veeam customer for some years but after much consideration I made the switch to the Enterprise Edition of Nakivo Backup & Replication (http://www.nakivo.com).

It wasn't actually about the money, even though the Nakivo annual support and maintenance fees are in my case 22% lower than Veeam's (nevermind that Veeam's Enterprise license is 2k/socket and Nakivo's is 600/socket). It also wasn't about being able to deploy Nakivo on either my own Linux install or just straight up deploying the Nakivo Virtual Appliance. I still run Nakivo on Windows because we are a Windows shop and the extra Windows license doesn't break my bank. Lastly, it wasn't about multi-tenancy where I can give VM owners and easy way to restore their own VMs without that they have access to the restore of VMs which are not theirs.

Nope, none of the above.

I switched because I am saving a ton of disk space due to deduplication across all of my backups!

With Veeam deduplication only works per backup job. So if you want really high deduplication levels then you have to put all of your VMs into the same backup job. This is, of course, less than optimal and no one in their right mind actually does that.

With Nakivo deduplication happens on a per repository level, so all jobs that use the same repository are deduplicated. As you can imagine that results in significantly higher deduplication levels as many of those OS blocks only have to be stored once. Depending on whether you have like data across different VMs you will see additional deduplication savings as well.

Currently I am only running 18 VMs on Nakivo and I am achieving a 1:20 deduplication ratio between Windows 2008, Windows 2012, Ubuntu, Debian, and Centos. That's a lot of different OSes and patch levels among just 18 VMs. In the coming weeks I will move the 2008 machines to 2012 R2, and upgrade the 2012 to 2012 R2 for higher deduplication. Later this year we will migrate the Debians to Ubuntu and will discontinue the use of Centos. Dedup ratios should go up further. This is also the time to consider whether I will add all of the VMs to the same repository. Those 18 I am using now are on a 2 TB repository and I currently don't have a good feel for how quickly it will grow. I have about 50 VMs so I may create additional 2 TB repositories and just live with the fact that I lose out on some dedup, or I may create one gigantic VMFS datastore for dedup across 100% of my VMs.

It's not all rainbows and pink Unicorns, Nakivo doesn't have the Instant VM Recovery that Veeam provides where you can run the VM off of the backup file, which really was a handy feature, but still, over time dedup wins.

Isn't veeam supposed to be adding or already adding dedupe?

Thought 7 added it, may be wrong through

I'm on Veeam VSP so its $6 per month to backup a VM, damn good price if you ask me, can even add Veeam one for a couple bucks more.

k1pp3r said:

Isn't veeam supposed to be adding or already adding dedupe?

Click to expand...

Sure, Veeam does dedupe, per backup job. Veeam's design treats each job as an isolated silo and there's no dedupe across all jobs.

klank said:

This thread reads and smells like an advertisement.

Click to expand...

If me letting you know about a product that I use in production is an advertisement, then yes, this is an ad. Is this thread My VMware View Win7 Optimization Guide an ad for VMware View? How about this thread; vSphere 5.5 is out is is an ad for vSphere 5.5?

We talk about products and services here all the time. The whole point of this forum is to let others know what works and what doesn't. Nakivo works. There's always inertia that delays making a change. I don't work for Nakivo, I don't work for a VAR or Partner that sells Nakivo, I have zero financial gain from talking about it. I am simply an end-user who has been involved with Nakivo since an early alpha, and I finally years later decided to start using it. See my previous posts VM Backup & Replication for $1/socket and Nakivo Backup & Replication switch & save promo, also free NFR licenses.

I was happy with Veeam, but at some point I simply couldn't ignore that for my needs Nakivo is the better product and so I had to go ahead and make the change. This thread is to let others know why I made that decision so they can decide for themselves whether it's something that they may want to look at.

I think I'm going with SnapProtect for my next deployment but if they don't want to pay for all NetApp, Veeam would have been my next choice so this is good to know.

Not being able to boot off of the backup is deal-breaker for me, that's one of the best features of Veeam. Been very happy with the level of dedup that Veeam + Exagrid provides as well.

How has your job time been affected, is it as fast as Veeam 7?

Have you ever actually had to boot off the backup using Veeam in a real disaster scenario? I'm curious because people talk about the feature being there, but haven't really heard of anyone ever use it.

QHalo said:

Have you ever actually had to boot off the backup using Veeam in a real disaster scenario? I'm curious because people talk about the feature being there, but haven't really heard of anyone ever use it.

Click to expand...

I've never had to do it in a real DR situation, but I've done it for testing our DR plan. It works and then you can move the box back to production storage. I wouldn't recommend booting a ton of them up at the same time depending on what your backup storage is, but if you do a tiered approached, it works well.

ND40oz said:

How has your job time been affected, is it as fast as Veeam 7?

Click to expand...

I don't have really good data on this for all VMs because I am also changing VM storage around in preparation of a DataCore deployment, but I here are a couple examples of comparing apples to apples when it comes to where the VM is stored and how it's used, the for the Nakivo run there was an additional ~60 GB of data placed on it but it's close enough to compare.

initial seed run
vm1, 229 GB transferred with Veeam, took 2:02 hours, 31.96 MB/s
vm1, 292 GB transferred with Nakivo, took 2:19 hours, 28.56 MB/s

That's close enough to be in the margin of storage utilization at the time of backup etc., but read on why it's not as easy to compare the two when it comes to timing. Timing subsequent runs is a bit tricker because Veeam includes creating and committing the snapshot into the time it takes to run the job whereas Nakivo does not. For subsequent runs Veeam posts 10-12 minute durations wereas Nakivo posts 2 minute durations. The amount of data transferred for both softwares is roughly equal.

Both Veeam and Nakivo use Change Block Tracking, but Veeam deduplicates "in-line" on the source side as well as on the destination side. Conceivably there are circumstances where Veeam backs up faster if there is actual content to dedup in-line. I don't have a good example on when that could happen, perhaps if you don't use CBT? Nakivo only dedups on the destination/repository side, but can achieve higher effective dedup rates because of deduping the whole repository. Obviously both programs use compression as well and don't store empty/zero blocks.

There's one thing users need to be aware of though; With Veeam each backup job is a silo, tucked away in a specific folder on disk. So if you want to move a backup job from one repository to another it's just a matter of moving that folder and making edits in the job to reflect that move. With Nakivo you cannot migrate the existing data of a job to a new repository. Instead you can move a job to a new repository and you have to decide whether to keep existing data on the old repository or delete it. If you decide to keep it then it will be subject to the retention policy for that job. It does make sense that you cannot migrate the data because the data doesn't exist in isolated form as it's all deduplicated. It would take some effort to extract a current job from a highly deduped repository, but I suppose it's possible that they will add such functionality in the future if people ask for it.

To follow up on why I am posting all this; I have essentially been involved in "product development" for almost two years now. I am just some random guy on the Internet but the folks who make Nakivo have taken some of my suggestions, and the suggestions of other customers/testers, seriously and have interacted with customers/testers in such a way that makes it clear that our opinions are valued.

I have a stack of NDAs in my office and have often provided feedback to different companies, but not until I started to test for Nakivo did I get the feeling that what I wrote down actually mattered to the company that asked me to test stuff. Now that I think about it, I did get paid by Nakivo, I received a $20 Amazon Gift card for doing the Alpha Testing, so there's full disclosure for you.

Oh wow, are you not using parallel processing then? If you are, how does this product compare when you're utilizing it. I know going from Veeam 6.5 to 7.0, we cut our normal ~60 VM (2.4 TB allocated) backup time of 7-8 hours down to an hour and a half, just wondering if this has the same performance.

Does Nakivo have proxy appliances for offsite locations with a single pane of glass management for everything like Veeam or do you need to manage a backup server at each location?

I cant want for a hyper-visor based synchronous backup system that works like Zerto without needing snapshots. Surprised it hasn't been done yet.

ND40oz said:

Oh wow, are you not using parallel processing then? If you are, how does this product compare when you're utilizing it. I know going from Veeam 6.5 to 7.0, we cut our normal ~60 VM (2.4 TB allocated) backup time of 7-8 hours down to an hour and a half, just wondering if this has the same performance.

Does Nakivo have proxy appliances for offsite locations with a single pane of glass management for everything like Veeam or do you need to manage a backup server at each location?

Click to expand...

what kind of back end do you have for this?

fiber networks
SANs

what are you using to dump the backups too?
Curious as i have a VM deply going out i need to choose a backup solution for.

ND40oz said:

Oh wow, are you not using parallel processing then? If you are, how does this product compare when you're utilizing it.

Does Nakivo have proxy appliances for offsite locations with a single pane of glass management for everything like Veeam or do you need to manage a backup server at each location?

Click to expand...

The way I have it set up is that each VM has its own backup job and that backup jobs are not running concurrently. That's because in my case write operations to the repository send the SAN that hosts the repository into ~100 ms device latencies. However, if your storage supports it and you allocate enough memory to the transporter/director then you can absolutely run multiple jobs concurrently.

The equivalent of the Veeam Proxy is the Nakivo Transporter. You would deploy a transporter per remote site. This allows you to use the network acceleration (WAN acceleration), which reduces the data volume sent over the link at the cost of increased CPU load on the transporters. Network acceleration was a core feature of Nakivo at release whereas Veeam only added it in version 7, more than a year after Nakivo offered it in the same product space.

Nakivo management happens from the a single pane from which all transporters in your organization can be managed.

MrGuvernment said:

what kind of back end do you have for this?

fiber networks
SANs

what are you using to dump the backups too?
Curious as i have a VM deply going out i need to choose a backup solution for.

Click to expand...

We use commvault for all of the stuff at our main location since we have a few physical boxes that have stuck around, but for all of our remote locations, we've been using Veeam with a local proxy and a local backup repository.

For this one, we have a NetApp dual controller 2240, using NFS for storage over 10GbE. It backs up to a Exagrid EX7000 which has the optional 10GbE card. We're moving a bunch more systems into this site and when all is said and done we'll have roughly 100 VMs that will be backed up nightly with about 6TB of disk allocated to them.

Thuleman said:

The way I have it set up is that each VM has its own backup job and that backup jobs are not running concurrently. That's because in my case write operations to the repository send the SAN that hosts the repository into ~100 ms device latencies. However, if your storage supports it and you allocate enough memory to the transporter/director then you can absolutely run multiple jobs concurrently.

The equivalent of the Veeam Proxy is the Nakivo Transporter. You would deploy a transporter per remote site. This allows you to use the network acceleration (WAN acceleration), which reduces the data volume sent over the link at the cost of increased CPU load on the transporters. Network acceleration was a core feature of Nakivo at release whereas Veeam only added it in version 7, more than a year after Nakivo offered it in the same product space.

Nakivo management happens from the a single pane from which all transporters in your organization can be managed.

Click to expand...

So I assume you can put a backup repository at the remote site on the same subnet as the transporter and backup directly to it instead of bringing it over a WAN link?

Is there any reason that you would have to do separate jobs for all of your VMs? Can you just stick them all in the same job and have them process concurrently provided your storage/transporter supports it? Usually I keep everything in the same job except some Windows boxes that need to do things like truncate SQL logs, they get their own Veeam job with application-aware image processing enabled.

Also a Veeam user here, definitely going to check out Nakivo. Thanks for the heads up on this.

ND40oz said:

So I assume you can put a backup repository at the remote site on the same subnet as the transporter and backup directly to it instead of bringing it over a WAN link?

Click to expand...

Sure, if your source and repository are local to the remote site then you don't need the WAN link, the transporter will just take care of everything locally, though the director needs access to the transporter so there does have to be networking in place to make that connection.

ND40oz said:

Is there any reason that you would have to do separate jobs for all of your VMs? Can you just stick them all in the same job and have them process concurrently provided your storage/transporter supports it?

Click to expand...

There are a few reasons for having separate jobs; different VMs have different retention requirements, some VMs have confirmation/warning/error emails sent to different responsible parties in addition to sending them to the vSphere admin, some VMs are on different repositories, and then there's my need for not flooding the storage, though I could set the max concurrent jobs/disks to 1 and that wouldn't be an issue.

Nakivo out of the box runs 6 jobs/disks concurrently. That's set on a per transporter level, so one could set it to 2 or 20, depending on what the underlying hardware can handle.

We just deployed a Datto based backup solution from veeam, and it seems to meet any standard we've thrown at it. Offsite backups, and the like. Just curious if anyone else has seen/used it as well.

You mixed datto with veeam? Isn't the point of datto to get the shadowsnap software or stroagecraft?

Never heard of someone writing veeam backups to a datto box and shipping that offsite. Probably cause I use veeam in a larger datacenter envrionment where we replicate with veeam to a second DC in addition to the backup data.

Interesting idea though

Thuleman said:

The equivalent of the Veeam Proxy is the Nakivo Transporter. You would deploy a transporter per remote site. This allows you to use the network acceleration (WAN acceleration), which reduces the data volume sent over the link at the cost of increased CPU load on the transporters. Network acceleration was a core feature of Nakivo at release whereas Veeam only added it in version 7, more than a year after Nakivo offered it in the same product space.

Click to expand...

So this appeared to be complete BS. Looks like Nakivo is purposely misleading its users into believing they provide WAN acceleration, when in reality they have nothing even remotely close. What they do provide falls into the definition of "WAN optimizations", something Veeam has provided since day 1.

I've done extensive testing of both Veeam and Nakivo on the same workload with WAN acceleration enabled in both (although in case of Nakivo this term is should really be quoted), and I've observed 10-20 times greater bandwidth usage with Nakivo vs. Veeam. And because my upload is just 5 Mbps, Nakivo jobs were taking respectively 10-20 times longer!!!

I have wasted so much time on these test and am really irritated by Nakivo's false advertizement. Considering that WAN acceleration is industry standard team that has very specific definition, so they have been knowingly misleading their prospects

anvigos said:

I have wasted so much time on these test and am really irritated by Nakivo's false advertizement. Considering that WAN acceleration is industry standard team that has very specific definition, so they have been knowingly misleading their prospects

Click to expand...

Thanks for signing up on [H] just to make this post.

I am not convinced that your quoted definition of WAN acceleration:

A WAN accelerator is an appliance that optimizes bandwidth to improve the end user's experience on a wide area network (WAN).

Click to expand...

is applicable in the context of common backup solutions for virtual environments.

In either case, Nakivo states the following about their product:

Network Acceleration

WAN and LAN links are often slow or have limited bandwidth, driving the need to optimize network utilization with technology that can reduce network traffic. With NAKIVO Backup & Replication, network acceleration is achieved with enhanced compression and traffic reduction techniques which enable 2X faster backup and replication, as well as recovery of VMs and files from local and offsite backups.

Click to expand...

via the product data sheet at http://www.nakivo.com/Resources/NBR-DS.pdf

Luckily most every backup solution out there provides you with a trial period for you to test it in your own environment. In addition Nakivo provides actual professionals with a free 2-socket NFR license to run in your home lab as you please. See: http://www.nakivo.com/en/free_nfr_license.htm

anvigos said:

I've done extensive testing of both Veeam and Nakivo on the same workload with WAN acceleration enabled in both (although in case of Nakivo this term is should really be quoted), and I've observed 10-20 times greater bandwidth usage with Nakivo vs. Veeam.

Click to expand...

I am well familiar with the concept of exaggeration for dramatic effect as I often use this technique myself. However, it only works well when the exaggeration is actually so outlandish that it really drives the dramatic effect home.

Technology is what it is and backup solutions have become a commodity where both features and performance are converging between all the different solutions and the true differentiators becomes cost and quality of support.

Claiming that the efficiency of one product is more than an order of magnitude worse than that of another product simply cannot be taken seriously. When making stuff up you need to keep your claims to more believable numbers while still effectively dissing the product.

0V3RC10CK3D said:

I cant want for a hyper-visor based synchronous backup system that works like Zerto without needing snapshots. Surprised it hasn't been done yet.

Click to expand...

We are OT, but to clarify, Zerto does not use snapshots and is indeed HV based.

Thuleman said:

I am not convinced that your quoted definition of WAN acceleration

Click to expand...

My bad, it's in that link I have provided, and here it goes (and Nakivo support confirmed me they currently don't do this):

Basically, an accelerator works by caching duplicate files or parts of files so they can be referenced instead of having to be sent across the WAN again.

Click to expand...

Thuleman said:

I am well familiar with the concept of exaggeration for dramatic effect as I often use this technique myself. However, it only works well when the exaggeration is actually so outlandish that it really drives the dramatic effect home.

Technology is what it is and backup solutions have become a commodity where both features and performance are converging between all the different solutions and the true differentiators becomes cost and quality of support.

Claiming that the efficiency of one product is more than an order of magnitude worse than that of another product simply cannot be taken seriously. When making stuff up you need to keep your claims to more believable numbers while still effectively dissing the product.

Click to expand...

That is pretty arrogant reply do you have any facts?

Because I do, and I am actually not exaggerating at all. Veeam definitely does in their marketing, they claim "up to 50x faster". I could never get anywhere close to this. But my 10-20x numbers are actual, real numbers from my own testing on a part of my production environment. I know its hard to believe, I too could not believe and had to test recovery often

I suggest you simply try the same test with Veeam trial? I am testing daily backups, and they are able to do at least 8-10x data reduction with a single server on incremental runs with WAN acceleration. But it jumps to almost 20x when you add a few dozens of servers to the job, for obvious reasons (more similar data between servers which does not have to be transferred).

Note: I am NOT talking about initial full backups here. With that, I am getting absolutely crazy ridiculous data reduction numbers there, because Veeam "warms" cache from target side backup repository, so there is almost no data that needs to be transferred over, as most of it is in target side cache already. I am talking about incremental runs, which are all about unique data (the hardest part).

Thuleman said:

Claiming that the efficiency of one product is more than an order of magnitude worse than that of another product simply cannot be taken seriously.

Click to expand...

Seriously? Do you not believe that a car is 10x faster than a bicycle? But there is your order of magnitude difference!

Car is 10x faster because it has an engine, and bicycle does not. Veeam is 10x faster because it has WAN acceleration, and Nakivo does not. This was the whole point of my post anyway...

I wouldn't be surprised if the results are because of different types of backups. Veeam has multiple options for type of backups (inc, reverse inc, synthetic full), versus nakivo is just synthetic full. That means the backup size is going to be larger (and hence the wan time longer), vs an incremental from veeam. I noticed after using veeam to test for several months, then switching to nakivo for cost, the nakivo backups are always larger and typically longer.

anvigos said:

That is pretty arrogant reply do you have any facts?

Because I do, and I am actually not exaggerating at all.

Click to expand...

If that's truly the case, and you did put in all these hours to figure it out, then here is what I would do if I were you; I'd write it all up in a clear and concise fashion, including all the facts, the setup of the environment, all pertinent details, perhaps add some screenshots as appropriate, post it to your blog, then come here and link to it. If you don't have a blog then you could make a new thread about it here. That way readers have something to go on other than a 1st-day forum member showing up saying that a product sucks and is 10x worse than another.

As dave99 pointed out, it would also be important to compare both products using synthetic full in both cases. A discussion whether synthetic full (or forever incremental, however you want to call it) is a good choice given other methods certainly has merit but is a different matter altogether.

It's important to point out that the "WAN acceleration" that is new in Veeam 7 only operates on backup copy jobs.

I can confirm I am using synthetic full with Veeam, in fact this looks to be the default setting, since I did not touch it in my testing. I will try to put something together soon.

Note, I did not say the product sucks and is 10x worse. I did say that Nakivo performs 10x worse in my testing, but that's only because I am comparing apples to oranges, really! According to my findings, Nakivo simply does not do WAN acceleration, while Veeam does. Not my fault in comparing apples to oranges though, just like you I assumed they do provide WAN acceleration based on all their marketing.

In my first post, I've quoted you using "Network acceleration" and "WAN acceleration" terms interchangeably, they should not be. This is the point I was trying to make, sorry if it came across like comparing the two product directly.

I have certainly used the terms network acceleration and WAN acceleration interchangeably, and wrongfully so.

Now the only mystery that needs to be solved is why, in your specific case, it appears that the Veeam synthetic full (which is a feature only introduced in Version 7, long after Nakivo had it, but that's just as a side-note) is 10-20x faster than Nakivo's synthetic full backup since Veeam's WAN acceleration doesn't apply to backup jobs.

No matter which product is used, the synthetic full principle remains the same, one full backup, incremental backups, and then the creation of a synthetic full backup on the repository side. If the performance of one product is 10-20x slower than that of another then it's unlikely to be a technology problem since the process inside the software is functionally identical.

Hi everyone, I work for Veeam R&D and been doing technical product management for Veeam Backup & Replication pretty much since the beginning, for over 6 years now. I thought I should register here to address some incorrect statements about our product, as well as to answer any further questions.

Thuleman said:

Veeam synthetic full (which is a feature only introduced in Version 7, long after Nakivo had it, but that's just as a side-note)

Click to expand...

This is not true. Veeam had synthetic full since v1 (released over 6 years ago), and in fact, synthetic forever-incremental backup was the only available backup mode for a very long time. Specifically until our v4, where we have introduced optional periodic full backups based on requests from some customers who wanted this due to their policies, or just piece of mind (some people just don't trust super long forever incremental chain).

Thuleman said:

With Veeam deduplication only works per backup job. So if you want really high deduplication levels then you have to put all of your VMs into the same backup job. This is, of course, less than optimal and no one in their right mind actually does that.

Click to expand...

I am not sure why you think this way. There is absolutely nothing non-optimal about this. In fact, based on our support statistics, most Veeam customers with less than 50 VMs go with the single job (and you noted you only have 18 VMs). I hope you agree that tens of thousands of our users cannot all be not in the right mind especially since many of them have been doing this for years now, and it worked well for them.

As far as WAN Optimization vs. WAN Acceleration, we at Veeam actually went through all these steps a while ago, adding first the former, and than the latter, so I can clarify the difference first hand.

WAN optimization is really the core stuff for supporting high-latency WAN links, which in my experience must include at least the following top 3 technologies:
1. Network traffic compression (just because it is so easy to implement, and no reason not to)
2. Multi-threading (helps to saturate high-latency links and some "interesting" network equipment)
3. Optimize communication between product components to be less chatty, and exchange data in larger blocks (TCP/IP does not "like" chatty workload with lost of small packets exchanged), or just switching to UDP. We tried both.
Now, on top of that, Veeam has a few more advanced know-hows that we introduced based on unexpected real-world issues and behaviors, but they are too technical, and I don't necessarily want to tip any competition here anyway.

WAN acceleration is the whole next stage, and it's all about data reduction, and making sure all unique data is sent over WAN only once and only once. The definition provided earlier in this thread captures the idea pretty well - it is all about determining the repeated data, and caching it. Now obviously there is a lot of secret sauce in how you do this optimally (over a year in research alone in our case), but end users don't care. What matters for them is dramatic bandwidth consumption reduction, which in turn increases performance copying data over WAN links accordingly.

Let me give you a simplified example. Imagine you have 50 Windows 2012 VMs, and it is Patch Tuesday. Say, they got 100MB worth of patches installed, but really those are all the same files. Now, solutions without WAN acceleration will transfer 50x100=5000MB of data over WAN during the incremental run the following night, when Veeam will transfer only actual 100MB (50x less). Meaning that if your WAN speed is the bottleneck, it will take Veeam up to 50x less time to process the corresponding incremental run.

Hope this makes sense! Let me know if you have any questions about Veeam solution.

Thanks for joining the discussion Gostev!

Gostev said:

I am not sure why you think this way. There is absolutely nothing non-optimal about this. In fact, based on our support statistics, most Veeam customers with less than 50 VMs go with the single job (and you noted you only have 18 VMs). I hope you agree that tens of thousands of our users cannot all be not in the right mind especially since many of them have been doing this for years now, and it worked well for them.

Click to expand...

Just to clarify, I had 18 VMs in Nakivo at the time, overall I have a few more, but sub 100 in either case.

However, that tens of thousands of Veeam users run all their VMs in the same backup job does indeed make me think that they are not in their right mind. To me this just means that they either don't care to optimize their backup strategy and/or choose to not follow best practices.

One very glaring example of why different backup jobs are absolutely necessary are various retention requirements. The most obvious use case for that is that financial data (in the US) has to be (in most cases) retained for 7 years. Clearly that data has to be on a different retention schedule than other data. So it makes exactly zero sense to lump all VMs into the same backup job if you are subject to the retention requirement, unless the argument is that the different retention requirements are fulfilled by means other than Veeam which increases the complexity of the backup solution. There are plenty of other use cases can be found for different retention requirements.

Nakivo's deduplication across the entire repository regardless of how many jobs are involved is the superior technology if the goal is to conserve backup storage space. The more VMs are involved the higher the disk space savings when deduplicating across the entire repository.

Then there's the per-core pricing difference which especially stings when it comes to multi-tenancy (or self-service recovery as Veeam calls it). Users have to decide for themselves whether Veeam's 2k/socket really provides 1.4k more value than Nakivo's $600/socket for the respective highest functionality versions, especially when considering that Nakivo's pricing is flexible whereas my own experience with Veeam's pricing has been a very rigid VMware-esque "take it or leave it" when I attempted to upgrade to Veeam Enterprise Plus. I understand that startups are more willing to be flexible while established vendors believe that they can afford the "my way or the highway" attitude (till they can't anymore).

It's IMHO a common misconception that the pricing differences would only apply to new customers. Let's consider an existing Veeam Standard customer who will be asked to pay an additional ~$1,200 per socket to upgrade to Veeam Enterprise Plus. That same customer can just pay Nakivo ~$599/socket outright to obtain the multi-tenancy (for example).

I also appreciate that Nakivo doesn't nickle and dime customers who want to backup to Amazon. Backing up to Amazon is a standard feature of Nakivo that's included in all editions at no extra charge. I really have misgivings about Veeam asking me to pay up for functionality that should be standard in any backup product in 2014.

I am sorry I got the synthetic backup wrong. I know that I meant to have a valid comparison about backup modes in there somewhere but wrote up the wrong detail.

@Gostev thanks for weighing in. One thing I like about Veeam is that their staff members are cool. Don't know too many other software company VPs posting on the forums

@Thuleman seems like you are referring to full product prices, for your business size it makes more sense to go with essentials package which gives special pricing for small environments, this is what we went ahead with http://www.veeam.com/smb-vmware-hyper-v-essentials.html

I don't think it is remotely fair to compare Veeam Enterprise Plus to Nakivo when comparing pricing, because in terms of functionality, even Veeam Standard beats Nakivo big times (think Instant VM Recovery alone, or Microsoft application items recovery). And Enterprise and Enterprise Plus add so much more functionality that Nakivo does not have, it is simply insane to compare. That said, I appreciate you may not need this functionality - but then again, why do you refer to Enterprise Plus in your comparison then

In any case, I always tend to look at TCO instead of upfront pricing, and Nakivo would additionally cost me 6 digit purchase of 3rd party WAN accelerators (or huge bump of what I pay for my WAN link instead), plus a few more solutions on top to do application item recoveries for my users (been looking at Kroll OnTrack to use in conjuction with Nakivo). Finally, DR testing would be too costly and time consuming without SureBackup. I guess these were top 3 considerations for me to go ahead with Veeam.

anvigos said:

@Thuleman seems like you are referring to full product prices, for your business size it makes more sense to go with essentials package which gives special pricing for small environments, this is what we went ahead with http://www.veeam.com/smb-vmware-hyper-v-essentials.html

Click to expand...

Generally speaking it is best to let the people who run the environment decide what their functional requirements are. Which is precisely why I wrote that "users have decide for themselves" which product to use. To you WAN Acceleration is important because you seem to copy backup jobs over WAN. To me that feature is irrelevant, but I do need self-service recovery so that admins who maintain their own VMs can recover those themselves. Global deduplication across the entire repository is also important to me because I do run different backup jobs for valid business process reasons.

Just because an environment is small in VM count doesn't mean that it can't, or shouldn't, have functional requirements which can only be satisfied by the highest priced editions.

anvigos said:

I don't think it is remotely fair to compare Veeam Enterprise Plus to Nakivo when comparing pricing, because in terms of functionality, even Veeam Standard beats Nakivo big times (think Instant VM Recovery alone, or Microsoft application items recovery). And Enterprise and Enterprise Plus add so much more functionality that Nakivo does not have, it is simply insane to compare. That said, I appreciate you may not need this functionality - but then again, why do you refer to Enterprise Plus in your comparison then

Click to expand...

FYI, Nakivo does Microsoft application item recovery for Exchange which was introduced in version 4 as well as the truncation of Exchange logs. In our environment we don't run Exchange or Sharepoint, so that functionality is not needed.

To me the comparison of Veeam Enterprise Plus to Nakivo Enterprise makes perfect sense because only Veeam Enterprise Plus has the feature I need. It doesn't matter to me if Veeam Enterprise Plus has features I don't need.

Ideally vendors would let customers order software a la cart, but then they would lose out on too much revenue generated by customers who buy the next higher license level just for that one feature they need.

As so often in virtualization the answer to which backup software to use is; it depends! To me Nakivo makes more sense to satisfy the requirements. As far as TCO goes, additonal factors to consider are that Nakivo's global deduplication across a repository will lower storage costs by hundreds/thousands of dollars and that you don't need to buy a Windows license to run it.

My intent in making this thread was to explain the reasoning why *I* switched to Nakivo in case someone else is in a similar situation and may find this info useful. It's certainly not meant to convince everyone to buy or switch to Nakivo. People need to use what makes the most sense to them in their environment.

Thuleman said:

Just because an environment is small in VM count doesn't mean that it can't, or shouldn't, have functional requirements which can only be satisfied by the highest priced editions.

To me the comparison of Veeam Enterprise Plus to Nakivo Enterprise makes perfect sense because only Veeam Enterprise Plus has the feature I need.

Click to expand...

Hi, Thuleman. I just wanted to clarify this obvious confusion about our Veeam Essentials offering. Veeam Essentials suite provides exactly the same functionality as full Veeam Backup & Replication product, and is available in the same licensing editions: Standard, Enterprise and Enterprise Plus. So, you are really not losing any functionality going with Veeam Essentials, comparing to buying the same edition of Veeam Backup & Replication at full price.

Moreover, you actually gain much more.Veeam Essentials is a suite that consists of both Veeam B&R and Veeam ONE product. The latter provides advanced monitoring, reporting and capacity planning for your backup and virtual infrastructure, and is incredibly useful product by itself. But you essentially get it "for free" as a part of this suite.

To sum up, Veeam Essentials Enterprise Plus contains exactly the same Veeam Backup & Replication Enterprise Plus product in terms of functionality, will all features of the corresponding edition still present... it is just attractively priced specifically for small businesses, because we understand that most of those companies cannot afford the full product price (just as you have explained above).

Here is more information on Veeam Essentials, should you ever consider Veeam again
http://www.veeam.com/smb-vmware-hyper-v-essentials.html

Thank you!

Thuleman said:

FYI, Nakivo does Microsoft application item recovery for Exchange which was introduced in version 4 as well as the truncation of Exchange logs.

Click to expand...

No, not really - because it does not support Exchange 2013 which we are using in the second half of 2014!

And since you bring this up... I was largely unimpressed with the way they approached implementation of this particular feature. I did some digging in the install directory during my eval, and it became apparent that they just took an open source project for Exchange recovery, simply adding their UI on top of that (very limited functionality comparing to Veeam). I then went to the project site, and it looks to be abandoned for over a year now... which answers why there is no Exchange 2013 support in Nakivo

But the bigger issue is that I just don't trust vendors who glues their solution together from random open source pieces, instead of building it in-house. Simply because they can never support you with complex issues, or add new functionality and platform support in the timely manner (being fully dependent on real work force behind the code). I've been burnt by such vendors more than once now.

Normally this approach means that their R&D team is simply too small to build the solution themselves. You get what you pay for...

While I can't speak to the Exchange functionality since I don't use it I did find the following amusing:

anvigos said:

But the bigger issue is that I just don't trust vendors who glues their solution together from random open source pieces, instead of building it in-house.

Click to expand...

You may want to look up how many of the VMware features and products were "glued together".

Are you saying that most of the vSphere code was taken from open source projects? Honestly I don't believe this is the case. VMware did acquire many solutions, but those were brought over along with the teams who built them from scratch, so I have no concerns in VMware's ability to support me.

I was searching about Nakivo on these forums and came across this thread. After reading through these forums, I am seriously suspecting Veeam has asked their employees to conceal their identity and participate like other normal customers. For example, Gostev the VP of Veeam has a profile in facbook and his profile ID is anvigos - Check that out here - https://www.facebook.com/anvigos

He is also giving a 5 star rating to Veeam in facebook - which is OK but still a shady practice.

What's funny is he is appreciating himself in these forums for weighing in.

This is manipulation of the masses with lot of positive comments and a shady practice. Most of the other IDs are also has similar Veeam employees. While they do have a solid product I thought these practices was not necessary.

0V3RC10CK3D said:

I cant want for a hyper-visor based synchronous backup system that works like Zerto without needing snapshots. Surprised it hasn't been done yet.

Click to expand...

I have Veeam and Zerto, but I am not a big fan of Zerto. I used to not like snapshots because of performance issues, but a lot of that was due to contention and they were VM level snapshots. Storage snapshots are awesome. Since we were NetApp, I was excited to see Veeam 8 and start taking advantage of storage snapshots which really helped with performance. Now using different storage, the snapshots are beyond fast and a great way to protect VMs in additional to backups.

VSS is snapshots and important for transaction-consistent backups like Exchange and SQL.

I like the idea of Zerto since it is storage agnostic, but that is about it.

I would be curious to check out the dedupe for Nakivo. Right now I have a couple different setups. One backup repository is going to ZFS with lz4 compression. Only getting 1.01x compression. The other is Windows Server 2012 R2 with dedupe enabled (I believe this is not recommended, but I haven't had any issues) and I am getting 21% dedupe.

Kaps - I have been using nakivo for about 6 months. started with version 4 and now on 5.7.1. No complaints. It does its job nightly like clockwork. only issues arise is when repo gets low on space. I have used it to replicate across datacenters and it does use compression and its pretty good one. As far as dedup I'm using 2 transporters with local backup repos. I just add vmdks to them and extend them. Here is a screen shot of one of them that has about 15 vms being backed up.
with normal compression and dedup i'm getting 94% on this one


here is a more recent one with 4 vms being backed up. with this one i'm getting 54% and it increases as I add more vms to be backed up


As far as negative - only one that i have is the lack of support on weekends. I had few issues arise and had to improvise over the weekend but ticket was resolved on monday.

They do provide improvements constantly. I'm waiting for ability to move vms between repos and also some sort of automation for replicated vms which is not there yet.

Alex

Hi Kaps,
the deduplication rate is closed related to VM data, we are using nakivo to protect over 250 VMs in multi tenant environment and using about 10 repository.
The Space savings rate is always over 85% combining fast compression and deduplication and keeping 30 recovery points for VM
All our environment works using only linux platform for Nakivo transporter
We actively collaborate with Nakivo support and development teams fixing and enhancing their product with a really good feedback

New version 6 will finally provide backup copy, first test on alpha version are fine

Marco

Damn I like nakivo and all (and was the first paying customer), but I hate to see new accounts come in and give a marketing speech as it comes across really spammy.

That said -in case anyone sees the above post and thinks it's just spamware, it's a solid product, good value, although not as full featured as veeam (it's come a long way since initial release in feature count though), but not nearly as expensive either.

kspooner13 said:

We just deployed a Datto based backup solution from veeam, and it seems to meet any standard we've thrown at it. Offsite backups, and the like. Just curious if anyone else has seen/used it as well.

Click to expand...

We used Datto at my last job. Worked well for most things but file based restores were limited when I used them. At that time we couldn't just do a restore and have all the file paths restored like you would with something like Backup Exec. You would mount the backup image and copy and paste the files. Is that still the case or did they fix that?