On almost a weekly basis, I get asked to help customers navigate the winding roads of the NetBackup license guide. For many customers these activities also include some looking under the hood of the customer’s NetBackup environment. I’ll be the first to admit that counting up Enterprise Client licenses is not nearly as much fun as mitigating “Exit Status 1” backup jobs (sarcasm intended) but there can be money in those hills and if you happen to find yourself on the wrong side of a capacity license true-up, wouldn’t you want to know that fact sooner than 3 weeks before your renewal is up?
Most NetBackup customers understand that licensing has never been “easy”. Veritas (formerly Symantec) worked hard to address the complexity by creating the capacity license model. Consume all you want at the buffet table of data protection features and be charged based on the amount of Front End TeraBytes (FETB, essentially the largest full backup) of data you’re protecting with the product. Instead of counting up physical NBU clients, ESX servers, NDMP head units, tape drives, database packs, etc… you let the NetBackup catalog tell you (through the use of the “nbdeployutil” command) what your FETB count is. Veritas charges you for the amount of FETB’s you’re consuming, that’s it (on to figuring out how to change those “status 1” backups to “status 0” backups).
This sounds great until you find yourself in your manager’s office scrambling trying to help her find money in the budget to pay for the 7 TB increase you’ve seen in your capacity consumption since last year.
Sound familiar? It is all too common with too many customers and unfortunately this scenario sours folks on this license model (and sometimes the product). Hindsight is always 20/20 but I offer this as tribute… RUN “NBDEPLOYUTIL” ONCE PER QUARTER! Knowledge is power and money. If you run “nbdeployutil” (and reconcile the report) once a quarter, you’ll know well before you need to start writing checks what your utilization and bill will be. It seems so silly and obvious but it sure seems like most of the unplanned FETB’s detected at renewal time could either have been mitigated or planned for.
Second nugget of advice, “TAKE THE TIME TO SPOT CHECK THE OUTPUT AND RECONCILE IF NECESSARY”.
“nbdeployutil” ultimately creates a report spreadsheet. The “summary” tab of the output spreadsheet does a great job of breaking down the FETB number.
When I said that there was “money in those hills”, this is exactly what I was talking about. The real “secret sauce” of the nbdeployutil command is its ability to flag and identify the potential for “double counting” FETB’s. Wait… did I say “double counting”??? Yes I did. A quick review of the “interpreting the Results” tab tells the tale of NetBackup potentially getting “tricked” by a single client being protected by multiple NetBackup policies. You see, nothing prevents an admin from creating two NBU policies that backup the same data. I most commonly see this effect when it comes to database protection. The admin has “standard” NBU policy that he wants to protect the install binaries and the OS with and then has a second NBU policy (most likely a DB/Agent policy) that is intended to protect the live running database on the client. If the admin is not careful to either specify just the OS paths OR create exclude lists that exclude the live database files from the OS policy, the OS policy can be trying to walk across the live/open database files. Not only are you backing up the same data twice, the NBU catalog can’t tell the difference and will report both copies of the data toward your FETB count. BTW, the OS backup that just tried to walk across live/open database files, will most likely not be recoverable.
It can truly “pay off” to dive a little deeper into the “itemization” tab of the report and reconcile what is going on with the “possible overlap” clients (189 FETB’s vs 307!).
On a related capacity/database protection note. How many of you out there are doing what I call “dump and scrape”? The DBA uses native tools to “dump” DB backups to local disk and then the enterprise backup utility comes by later and “sweeps” up the DB dumps and copies them to secondary storage. Here’s the rub, I see customers try to keep at least a couple of days’ worth of “dumps” local or near local to the protected client. What’s the problem with that? Well… let’s say you have a 300 GB SQL database that you keep 3 days of dumps local. By the capacity license model, you should really only have to pay for 300 GB of SQL data but because your “standard” file and folder backup policy swept up 900 GB of file/folder data sitting on the dump area, nbdeployutil detects 900 GB of Standard or MS-Windows-NT data toward your FETB count. While I see some surface benefits of the “dump and sweep” methodology, the hidden FETB costs are certainly a “con” and something to keep your eyes out for when looking at the capacity model (a blog topic for another time).
The truth is, that there is rarely a “one size fits all”. I’ve seen customers that have very large environments (big FETB footprints) but they don’t make full use of the product and take a minimalist strategy with data protection. These folks should probably stick with traditional license model and definitely assess if they can “raise their game” by leveraging the advanced features of NetBackup (which would justify the capacity license model). Veritas and dcVAST are glad to help you assess your usage of NetBackup to help you get the most out of the product and find the license model that best suits your data protection strategy.
