The gotchas of backup software 'capacity' licensing in virtual environments

Some backup software manufacturers are offering a capacity based licensing model, instead of a agent based model. Depending on your situation, this may be a dramatically easier and cheaper licensing model. Traditionally you had to buy per-server licenses, per-agent licenses, per-library licenses, and maybe other options as well. Backup software licensing could get very complex and very expensive. But it's extremely important to understand how their model works, for both physical and virtual servers or you may be in for sticker shock.

CommVault, Symantec, and others have introduced capacity based models. With this model, you have unlimited number of agents and servers, but the total amount of data you want to be backed up must be licensed. Depending on the vendor, they may have slight variations on this model. Tivoli capacity licensing is nearly as complex as their agent based model.

When can this model be more cost effective? Generally if you have a lot of servers with minimal data on them, this model works well. Per-server and per-application agents can get expensive. If you have a small number of servers with huge data stores, then a per-server/agent method could be more cost effective.

But, you need to be VERY careful and understand how the backup product measures capacity, if you go with that model. In a physical environment, it's generally very simple. If your pizza box server has 4TB of storage but you've only written 500GB of data, 500GB would count towards your capacity license. The remaining 3.5TB is 'free', until you start to physically use it.

In a virtual environment, this can get more complicated, and you could be in for some nasty surprises. Let's say you do a P2V migration of that same pizza box server, but you downsize the virtual disks to just 1.5TB. Now the million dollar question is, how much capacity counts towards your backup license? 500GB or 1.5TB, or something in between?

With CommVault Simpana 9.0, the answer is 'it depends'. CommVault counts the VMware VMDK disk size against your capacity license, regardless of how much physical space the VM is using. If you use VMware thin provisioned VMDKs, then at least 500GB comes out of your capacity license. If you use thick VMDKs and rely on your storage array to do the thin provisioning (which nearly all modern arrays support), the full 1.5TB counts against your license!! This is because Simpana is not intelligent enough to look inside the VM for actual disk usage and just charge you for the allocated amount. It looks at the VMDKs as a big blob, and charges you accordingly.

As a result, licensing for a virtual server can be significantly more expensive per GB than a physical environment, at least with Simpana 9.0. I don't know how NetBackup or other capacity based products count VMDK storage. I'd hope they are more consistent and use the physical server logic. If my VM has a 2TB hardware thin provisioned disk, but I've only written 500GB of data, only 500GB should count.

Using VMware thin provisioned disks doesn't fully solve the problem. Why? Let's say you have 2TB software thin provisioned disk, and the allocated VMDK space is 500GB. If you copy 1TB of data into the VM, then delete it, the VMDK is now 1.5TB but only contains 500GB of data. So you pay 3x the price for the same 500GB of data, unless you somehow shrink the VMDK.

Finally, if you leverage VMware fault tolerance, you simply can't use VMware thin provisioned disks. You must use EZT (eager zeroed thick) disks. So regardless of how much or how little disk space you use, the total VMDK disk size counts against your license.

This can be very confusing. CommVault has a two methods for counting capacity that you need to be aware of. One model for physical servers and another for virtual servers that can catch you off guard depending on how your VMDKs are configured.