And yes… the first babys-steps are taken. A release of the beta gave me more insights and I’m quite pleased with the work done by the teams.
My attention was mostly attracted by the V-One integration in VBR (yesyes… exceptionally nice dashboard and metrics) that will give insights…

So yes… in this tiny setup there is clearly still some work to do :-)… but I was also triggered by the “how would I get my score better” – question. And actually I was surprised by all the possible actions that were simply listed in the best-practice-analyser(that also suddenly changed icon).

Next to the dash and the advice, some time ago a colleague asked me a question about the percentages as bottleneck (all good for another blogpost pretty soon). So I dared to ask that to our new AI-robot…

Which actually gave me a pretty good answer. And this gives me hope, a lot of hope… currently I still need to answer quite a lot questions from clients that bumped into a small issue, could find where to tweak something or just had a generic question. I’m convinced that by promoting this chat I’ll be having less work :-). So my goal for 2024 is hereby defined. Train you to ask the right question, because the answer will be given and extremely likely very correct.

Now if you think it is really all about monitoring and intelligence, then you’re all wrong. There is a lot, a lot more, but a lot more is going to be announced and get visual in the coming months. Stay tuned and discover about inline detection, scanning an publishing and so on!

Another blogpost started with “how hard can it be”… well… I could be starting exactly the same for this post…
And yes, indeed, as a system engineer you’re not supposed to be talking about licenses, it is for the sales… But the question drops frequently in my inbox, so it might be worth to clarify a few things. First on a higher level. If you are looking how and where to find those licenses when a product was bought, click the link as I made a clickable demo already.

Let’s take a closer look at the above picture. Because before calculating how many licenses you actually need, we need to understand the definition of a “workload” for Veeam.
First the easiest ones: VM. One single virtual machine that is going to be backed up shall be understood as a workload. Secondly we can make the same assumption on physical workloads where we need a Veeam agent. So whenever an agent is deployed this is also considered as a workload. To get more insights in your workloads there is a report in V-One that can be consulted.

Now some people might wonder, what if… I deploy an agent on a virtual machine (and yes, that is possible and in some clustered environments even a good choice). It remains one workload… as simple as it can be… we don’t do any ++++ calculation at Veeam. It “just” remains 1 workload. The same rule is applied if you want to deploy a Veeam-plugin (like Oracle RMAN plugin) on a virtual/physical machine that is already been backed up (while excluding application integration and the data). This still is “just one” workload, and thus just one license. Only difference is that the vm-integration or agent will take care of the OS and the files, the application plugin will take care of the data that is being kept in that application and will treat it accordingly(archivelogs, transactionlog, truncates,…).
Now it is all about common sense… a workload in the cloud is also just one workload.
The only main exception on VBR is the NAS/share backup. Backing up a filer will be charged per slot of 500GB of frontend data.
Just keep in mind, if your xxl-fileserver that is provisioning shares is a physical/virtual machine, it can also be backed this way and will be considered as 1 workload. The approach of backup and versioning is completely different, so depending on the business-requirements the choice is to the admin how to implement the corresponding backup-strategy.

summary: 1 workload = 1 VUL (Veeam Universal License)

And now comes the most recurring question… how much licenses does it cost to copy to another datacenter… or make a replica… or…
euhm….. same rule… we don’t do +++ . So either you do just one single backup it is 1 VUL. If you plan to implement the 3-2-1(-1-0) rule and thus copy it over to another datacenter, it is still 1 VUL.
If you plan to use replica-jobs or CDP as replication-mechanism on top of that backup, it just remains that single VUL. Even better, you want to integrate with the storage snapshots, setup datalabs, want a full instant recovery plan and aim for automatic offloading to a cloud (or bring back backups from a cloud)… we don’t care… it is only the source data that is being licensed, all the other functionalities come with that license.

Second most asked licensing question is: my fileserver is 20TB how many licenses do I need for Veeam… 1… it is “just” one single machine.

So is Veeam expensive… well, if you limit yourself by taking a single backup of a single machine and drop it on very expensive storage, than it can be considered as expensive. However, if you plan to implement multiple copies, a replication-mechanism, tape-out, offload to cloud and keep in mind the license is transportable. Then it is for sure a (mega-)cheap product.

And that brings us to our last (already mentioned) very strong point in licensing, it is transportable. So the license that is for instance now assigned to a physical machine could be moved after that machine is migrated to a virtual machine… the license is then liberated as the source is not existing anymore. When the machine is being backed up, it can be offloaded to object storage in the cloud and then even as a DR or migration-path be started up in the cloud. If the vm is not onprem anymore the machine can now be backed up with the corresponding cloud product (Veeam backup for Azure/AWS/Google), and the license is now being consumed over there… even a failback is possible, by migrating the last data back to onprem. Also the license moves along when the machine is now being backed up onprem.
No additional costs or conversions are required… it is still the same workload.

As last… a free give-away… did you know we actually grant you 10% overconsumption? WHY? Because we know an environment is never stable forever. From time to time there is just general growth and it will allow the buffer for you to get licenses aligned again… OR… when you have migration-projects that push you as an admin temporarily in an exceeding-situation.

So… how hard can it be… not very hard… define the workload, make a list of workloads and then sum up how much licenses you’ll be consuming.

In case you need some help, don’t forget to reach out to your sales person.

Footer:
Our old license type is based on sockets or instances for physical machines. VUL (instance-based) cannot be combined with socket-licenses, unless socket-licenses are being used for hypervisor and VUL/instances ONLY for physicals,plugins and or NAS-licenses. It is NOT possible to combine VUL and sockets for the hypervisor of multiple datacenters!