Understanding what controls the overall capacity of the appliance


Understanding what controls the overall capacity of the appliance, as shown in the capacity report.


The overall capacity of physical appliances is a hard coded value given to each appliance type.  For UEB virtual appliances, capacity is calculated based on the size of the backup storage allocated to the UEB.  There are 3 factors that govern these "capacity" decisions.  

  • Physical storage:  This is the theoretical maximum amount of space after partitioning available for ALL operations.  Physical storage may contain backup, logs, database records temporary processing space, WinIR reserve, and more.  This is not a measure of how much a unit can hold in terms of data because 10% or more of this total space is reserved for other processing outside of raw data storage.  Many restore operations cannot be performed without a minimum of space as well, so some space is outright prevented from being used.  
  • D2D Device Size:  The Disk to Disk device is a logical cap applied to backup storage on a volume.  This is the maximum sum total of all backups stored on a system, including the Single Instance Store for deduplicated blocks and all backups for all clients, plus some temporary files created during backups for some operations.  
  • Capacity:  Capacity is the realistic amount of total source backup data that the D2D could typically accommodate accounting for basic operational use.  It is generally assumed customers will have at least 2 master backups of all clients some points in time, so the "capacity" number will have to be lower than the D2D size value to accommodate multiple copies, SIS storage, and other overhead. On older appliances before we implemented Advanced Adaptive Deduplication (AAD), capacity was a hard-set limit above which the system would disable some functions. It was a worst-case peak assuming that if you got there you would have no retention and only basic operational space to keep a single copy of a backup for each system.  On more modern appliances using AAD, this is more of a guiding rule and exceeding capacity "may" be possible for some customers with high compression or deduplication rates.  The more of the max recommended capacity is used on a unit, the lower retention will be.  It is typical to have significant spare capacity at initial time of deployment to account for data set growth over many years.  If Too much capacity is used, it may not be possible to land a new master backup completely in order to delete an older one.  We cannot delete an older backup until a new backup is successfully completed.    

How capacity is measured:

This is simple.  "Capacity" is counted as being the current raw (uncompressed) size of data protected for each client as measured by the size of their current master backup.  If you backed up 300GB of data from a client, we will record that client's capacity as 300GB.  Behind the scenes this may be compacted to a much smaller value.  If you have 5 master backups on disk for this client, we'll still just count the 300GB one time.  

For VMWare and Xen VMs note that the provisioned disk size may be counted instead of the VMDK size in some cases (where NFS datastores are used specifically, but in some cases CBT issues in vmware may misreport zero-length block data causing their API to provide unallocated blocks as well as allocated blocks).  For Hyper-V VMs the VHD or VHDX size is counted.  

For more information, please see the Capacity Report section of the Legacy Unitrends Admin Guide or the Capacity Report section of the New 9.0 Unitrends Administrators Guide.


In the legacy UI, select Reports > Capacity Report to view the report.
In the Satori UI, to view the report, select an Appliance from the list and click Generate Report.  When finished, click < Report Categories in the upper-left of the report to return to the Appliance category of the Available Reports page.

Have more questions?

Contact us

Was this article helpful?
0 out of 0 found this helpful

Provide feedback for the Documentation team!

Browse this section