Capacity license auditing using nbdeployutil ...possible and potentially significant errors ?

[Jim-90]

Can anybody else confirm this behaviour in Front End license spreadsheet generated by nbdeployutil?

From what I can see capacity license auditing using nbdeployutil can give possible and potentially significant errors if you have been doing some maintenance on  policies.

I run nbdeployutil at the start of every month to track front end license usage.  The report is based on one month's history.  I allow for about 10% accuracy as it seems jump around a bit.  The trend line is the important part.

From what I can see if you:

• move a server to a different policy
• split a large policy into smaller ones
• rename a policy

These have the potential to give you a misleading result because nbdeployutil doesn't have enough smarts to realise that it is actually counting the data a least twice and possibly multiple times.   This probably can be seen in the Itemized tab of the capacity report.

[Marianne · Accepted solution]

nbdeployutil should never be used 'as is'. (See the 'Disclaimer' tab.)
Especially if Oracle and/or other databases are backed up via multiple policies and multiple log backups per day.
Or any situation where a client appears in more than one policy.

I always recommend that Backup Admins use the Itemization column to look for duplicates/overlaps. 
Duplicates can be removed from "Charged Size" column (with a note/reason added in the next column). Doing so will result in more accurate "Charged" size on the Summary tab.

[RiaanBadenhorst]

Yes if you've done some modifications you should exclude those dates with 

--hoursago

It also gets a bit tricky when you've got backups of a client split between policies. If you're not the admin, its really hard to get a accurate figure without indepth knowledge of the site.

[Jim-90]

Thanks.  Removing duplicates was my thinking as well.  Looks like I'll have to script it given the length of the itemized tab/worksheet.

[Genericus]

I have solaris clusters for my oracle databases, so I get the same DB backed up via different servers as the DB moves around, I always have to sort and remove duplicates. 

There is a "feature" where if the VM admins are not tidy, can end up with variances in name between system and system.domain, I have found that if there are mismatches, you can add system to a VM policy, and get both system and system.domain being backed up - again with the duplicates in the report.

I can 10-25% total TB back after clearing duplicates, so it is worth my time to go over the report.