Committed Space estimations are too high when User or Application Backups are being submitted to Advanced Disk Disk Pools
Problem
When jobs are started the ' committed_space' counter is updated based on the estimated size of the data being backed up. Backups submitted manually or scheduled which have Full or Incremental schedules can be estimated based on the size of previous backups run of the same type and policy for the client. The estimate is a fixed percentage (120%) and used to adjust the 'committed_space' for the disk receiving the backup image.
If a previous backup is not present, or the job is a User or Application Backup, then a prior image size cannot be used to reliably determine an estimate. In those instances, an estimiate must still be made and the default calculation is (100 - High Water Mark)% of the disk.
As a result, jobs may remain in a queued state or use an unexpected storage unit.
Error Message
The job details and/or logs (rem and dps) may show the current configuration and commit calculations that prevent a job from using the expected storage unit. In this case the high water mark is 85% resulting in an estimate of 19 TB for this job and other jobs already have estimates that result in a committed space total that exceeds the available space on the volume.
[select_from_stu_list] ATTEMPTING TO ALLOCATE FROM STORAGE UNIT - stu_t: name = my-ost, ...
[validate_stu] list_mode = CONSIDER_DRIVE_MEDIA_AVAILABILITY
[kbytes_to_commit] kbytes_needed = 0, user_job_kbytes_estimate = 0
[kbytes_to_commit] remainder = 15% , calculated kbytes_to_commit = 20868141542
[check_disk_space] disk pool/volume does not have sufficient best-fit space, name = my-lsu, avail_space = 142240799784960, committed_space = 170441765601280, kbytes_needed = 20868141542
V-143-1546 [validate_stu] Disk volume is Full or down @aaaan
Cause
Note that If the high water mark is 90%, 10 concurrent User/Application jobs will commit the entire volume - even if otherwise empty - and additional jobs will not be able to use the volume.
The nbdevquery command can be used to review the total and committed space. In this case, the committed space is 0 so either all backups have completed or those in progress have exceeded their estimate.
$ /usr/openv/netbackup/bin/admincmd/nbdevquery -listdv -D -stype AdvancedDisk -dp < diskpool_name>
name : </MOUNT-POINT>
id : </MOUNT-POINT>
diskpool : <DISKPOOL_NAME::STORAGE_SERVER::AdvancedDisk>
disk_media_id : <DISK_ID_for_example_@aaaab>
total_capacity : 2147483648
total_phys_capacity : 2147483648
free_space : 2126877696
free_phys_space : 20605952
potential_free_space: 0
committed_space : 0
precommitted_space : 0
nbu_state : 2
sts_state : 0
flags : 0x6
num_read_mounts : 0
max_read_mounts : 0
num_write_mounts : 1
max_write_mounts : 2147483647
system_tag : <Unknown>
Solution
/usr/openv/netbackup/bin/admincmd/nbemmcmd -changesetting -USER_JOB_KBYTES_ESTIMATE < kbytes> -machinename < masterservername>
Alternate options:
Increase the High Water Mark (HWM) to 100%. This prevents the Committed Space from being allocated
or
Configure EMM to prevent job throttling. The committed space is still calculated, however the number of jobs that can run simultaneously is not restricted.
/usr/openv/netbackup/bin/admincmd/nbemmcmd -changesetting -DISABLE_DISK_STU_JOB_THROTTLING 1 -machinename < master_server>
For further information on Advanced Disk options and configurations, refer to the Related Article linked below.