NetBackup FETB Licensing: Why Capacity Looks Too High

A NetBackup FETB overage should be reconciled before you redesign backup policies. Changing a file server from an agent policy to VM level protection does not automatically lower licensing usage, because current FETB Plus terms classify qualifying virtual workloads at a 1.5 to 1 entitlement regardless of the policy type applied.

That distinction was the core of a recent administrator problem. The environment was over its licensed limit, and the proposed fix was to move file servers from weekly full plus daily differential agent backups to VM backups with accelerator and block level incrementals.

What does NetBackup FETB actually measure?

FETB stands for Front End Terabyte and is a capacity licensing measure based on the amount of protected front-end data. It is not the size of the deduplicated backup repository and it is not simply the number of bytes written during every backup job.

NetBackup documentation describes one FETB as 1 TB of protected data. Usage reporting looks at the protected estate and policy or workload information to determine the licensing total.

This is why backup frequency can be misleading in licensing conversations. A weekly full backup and several differentials move more data through the infrastructure than one snapshot, but the licensing meter is designed around the protected front end rather than treating every written copy as a new full quantity.

Before changing schedules, identify which clients and workloads are producing the licensing total.

Does a virtual file server get the 1.5 to 1 FETB Plus ratio?

Under Cohesity's April 2026 NetBackup Product Specific Terms, FETB Plus lists physical workloads at 1 FETB Plus to 1 FETB of protected data and virtual workloads at 1 FETB Plus to 1.5 FETB of protected data. The workload definition includes virtual machines on platforms such as VMware, Hyper-V, Nutanix AHV, Red Hat Virtualization, Azure Stack, and OpenStack.

The important wording is that the virtual classification applies regardless of the policy type used to protect the workload. That supports the point made in the Reddit discussion: if the file server is already a qualifying virtual workload and the organization owns the relevant flexible licensing edition, switching from an agent policy to a VM policy may not create the licensing reduction expected.

Do not apply that ratio from memory to every contract. Product terms change, editions differ, and older entitlements can use different rules. Match the report period to the Product Specific Terms and purchase documents that govern your environment.

Do accelerator and block level incrementals reduce FETB?

They can reduce backup traffic and storage work, but they should not be treated as a licensing trick. Accelerator and block level incremental methods are operational optimizations. They can reduce the amount of data moved during subsequent backups because NetBackup avoids resending unchanged data in the same way as a traditional full read.

FETB capacity licensing is a different measurement. If the protected front-end workload is still 20 TB, making the backup path more efficient does not necessarily turn it into a 10 TB licensed workload.

This is a useful architecture distinction. Backup optimization affects network, media server load, window length, and repository consumption. Licensing rules determine how the protected workload is counted.

If you are also comparing backup architectures in other virtualization stacks, the Proxmox backup comparison is useful for separating backup method from the size of the underlying protected workload. The most efficient data path is not automatically the smallest licensing meter.

Can nbdeployutil double count the same server?

It can produce results that need reconciliation when the same asset is protected through different policy paths or when usage classification does not line up cleanly. The Reddit discussion specifically suggested checking whether VMware and Windows NT or Standard policy protection for the same file servers was being counted more than once during a migration between methods.

NetBackup documentation says usage reporting considers protected data and that multiple copies of the same backup are not simply counted as separate protected front-end capacity. But policy combinations, accurate licensing support, client identity, and transition states can still make the report look surprising.

That is why nbdeployutil should be treated as a report to reconcile, not a number to accept without inspection. Open the detailed client and policy output. Match hostnames to real assets. Look for duplicate identities, old policies that still run, and workloads protected both at VM and guest level.

If two policies are intentionally protecting different datasets on the same server, the data may not be duplicate from a licensing perspective. If they are protecting the same filesystem during a migration, document that overlap and reconcile it according to the applicable licensing process.

What should you check before changing protection policies?

Start with the contract and the current Product Specific Terms. Confirm whether the environment is licensed under NetBackup Platform Base Complete Edition with Flexible Licensing or another model, and confirm whether FETB Plus applies.

Then run a fresh usage report and group results by workload. For each high consumer, record the physical or virtual classification, policy types, protected size, duplicate protection paths, and whether the asset is still active.

Pay special attention to migrations. It is common to leave an old agent policy enabled while a new VM policy is being tested. That overlap is sensible for recovery safety, but it can complicate licensing reports if both paths remain active for weeks.

I would also flag assets that have been decommissioned but remain in policy definitions. The broader backup hygiene lesson from Proxmox Backup Server applies here too: inventory has to match reality, because stale protection objects create operational noise even when the storage technology is different.

Should you switch to VM level backup anyway?

Switch if it improves recovery, operations, or infrastructure efficiency, not because you assume it will solve FETB. VM level backup can simplify machine recovery and reduce guest agent management for some workloads. Guest or application level protection can still be necessary for granular file or database recovery.

For file servers, compare restore requirements first. Do you need entire VM recovery, individual files, long retention, application-consistent snapshots, or recovery to alternate infrastructure? Then choose the NetBackup method that meets those requirements.

If the licensing report is wrong, fix the report and classification. If the licensing entitlement is genuinely too small for the protected estate, the choices are to reduce protected scope, change retention or workload design where that affects entitlement, move some workloads to another platform or product, or purchase enough capacity.

The worst option is to weaken recovery just to make a confusing report smaller. Reconcile first. Redesign second.