1| Page

Information on resource allocation within NetBackup.

Scope: This document will outline how resources are allocated within NetBackup and configuration options that are available to change the behavior of the NetBackup Resource Broker (nbrb). In-depth behavior of nbrb will be outlined, as it is the primary process responsible for resource allocation. Other processes will be covered only as they affect resource allocation. This document will not cover troubleshooting techniques. That will be covered in a different document. The areas of the application that will be covered as follows: For the purpose of this document, resource allocation will be defined as the point in time a job appears queued in the activity monitor, until the point that a job has started writing. The behavior outlined will apply to NetBackup versions 6.5.2 and later releases. The focus will be on a scheduled backup job. The differences between bptm parent and child will not be covered. The portion of the functional overview covered, is as follows:

2| Page

Definitions: bpcd: The NetBackup client daemon. This listens for connections on all NetBackup servers and clients. In 6.x, the default behavior is that connections from the master/media server(s) are made through vnetd. The vnetd daemon then makes a connection to bpcd to initiate whatever action needs to be completed. bpcompatd: NetBackup compatibility daemon. Used by nbjm to initiate calls to media servers. bpbrm: NetBackup backup and restore manager. This runs on media servers when backups or restores are running. The nbjm process will connect with bpbrm, via bpcompatd to vnetd to bpcd, to spawn the bptm process during backup and restores. The bpbrm process will send job manger (bpjobd) updates via nbjm. For mpx backups, bpbrm is started in MPX mode. A backup is then added to this mpx group by sending the START BACKUP message to bpbrm. bptm: NetBackup tape manager. This runs on media servers and is typically initiated by bpbrm. Some of the many things this process is responsible for are: writing data to disk or tape, initiating tape actions such as load/unload, reporting drive states to

3| Page nbrb and establishing a pipe with the client bpbkar process in order to pass data to the media. nbemm: NetBackup Enterprise Media Manager. Originator ID (OID) 111 This process will run on the entity that is known as the emm server, typically this is the master server. This process has several subcomponents, such as mds (media and device selection component, OID 143) and da (the device allocator for shared drives, OID 144). nbrb: NetBackup Resource Broker. Originator ID (OID) 118. This process is responsible for allocating disk and tape resources to jobs requiring them. It interacts with the nbemm components such as mds (the media selection component of emm), da (device allocator) ,fsm (Fiber Transport service manager) and dsm (disk service manager) frequently to query and update allocation status within the database. nbjm: NetBackup Job Manager. Originator ID (OID) 117. This process is responsible for passing job updates to the jobs database (bpjobd) and passing resource requests to nbrb and resource updates to bptm. vnetd: This daemon listens for connections on all NetBackup servers and clients. PBX: Private Branch Exchange. Originator ID (OID 103), product ID 50936. PBX listens on port 1556. It is responsible for establishing connections on the master and media servers for certain functions. Specific examples of when each of the above processes/daemons are utilized will be outlined later in this document. Neither the examples above, nor the ones outlined later on in this document are a full list of scenarios, but will cover many of the steps and actions required to allow resource allocation to occur.

4| Page

Process flow explained: When a job is scheduled by the NetBackup Policy Execution Manager, Originator ID (OID) 116, and it appears in the activity monitor, the job has reached a state where it has been passed to nbjm. The nbjm process will then add the request to the nbrb inbound queue, for resource allocation fulfillment. The job may appear in the activity monitor before or after the request is sent to nbrb, depending on timing of the receipt of the job. Job attribute updates are sent to bpjobd from nbjm every 10 seconds. The job will remain in the inbound queue until nbrb breaks from the current allocation cycle. Breaks in the evaluation cycle can occur for several reasons: The nbrb process has reviewed all allocations that are waiting. The nbrb.conf file parameter SECONDS_FOR_EVAL_LOOP_RELEASE time has been met (the default is 180 seconds at 6.5.4 and later versions). If a high priority request [span request, subsequent requests of a dup job, and requests with a pending condition] is received and the nbrb.conf parameter BREAK_EVAL_ON_DEMAND is set to 1 (enabled.) If nbrb is not currently in the middle of an evaluation cycle, an evaluation cycle will start as soon as nbjm places the job in the inbound queue. Once nbrb reads the request from the inbound queue, it is placed on the nbrb queue of requests that it is currently reviewing. The process will review specific resource requirements for the job. Resource allocations will be reviewed and an allocation assigned for each of the following: A client allocation, after reviewing the maximum number of jobs allowed per client. A policy allocation, after reviewing the maximum of jobs allowed per policy. One or more storage unit allocations (which include media and drive information) based on the request type. o First checks if it can join an existing MPX group. If it can, the request is satisfied internally without going to MDS. Other checks may be made to MDS at this time outside of the allocation. o If the request cannot join an existing MPX group, nbrb checks its cache to see if it is worth sending the request to MDS. If nbrb's cache indicates that all the drives in the storage unit are in use, MDS is also going to return 'retry later'. Why to send it to MDS then? o If, as per nbrb cache, it is okay to send the request to MDS, nbrb will send the request to nbrb. Each of the above are separate allocations and if a limit is exceeded or otherwise not available (such as if all the drives are busy or down), the resource allocation will not succeed and will be retried at a later time. Once nbrb has successfully allocated resources for a backup job, the resource allocations are passed to nbjm via the nbrb outbound queue.

5| Page The nbjm process reads the information from the nbrb outbound queue the job will appear as active in the activity monitor within a short period of time. The nbjm process will initiate a connection to the bpbrm process on the media server, typically via vnetd to bpcd communication, and bpbrm in turn will initiate the bptm process. When bptm is started, it initiates a connection to the nbjm process on the master server in order to get the media and drive information for the backup job. This communication is initiated through PBX, and an ORB connection will be established between the bptm and nbjm processes. At the time that nbjm receives the request from bptm, it will add the media/drive information to the outbound Callback queue. *** Note: There is only one nbjm Callback queue used for this purpose, all resources requests are passed to the media server bptm processes in a first-in-first-out order. The activity monitor will now show the drive as mounting, positioning and eventually writing. If the backup encounters an end of media (EOM) during the course of writing the backup, bptm will notify nbjm via PBX, and will wait for additional resource and drive information to be allocated. The current drive resource will not be released completely until a new drive/media is allocated. This ensures that the if no other drives are available, the current backup job should be able to use the same drive. At the end of a backup job, bptm will send an update to nbjm via PBX, that it is finished writing. The media server bpbrm process will send a job end message to nbjm. The nbjm process will send an update to nbrb to free the resources and unload the drive The unloading of drives will always take place at the end of an evaluation cycle. The release of resources will take place at the beginning of each cycle. The nbrb process will update nbemm as drives become available, are unloaded, etc.

An in-depth look at the nbrb process

The nbrb, or NetBackup Resource Broker, is the daemon/service responsible for handling resource requests for NetBackup. The nbrb process runs through an evaluation cycle periodically to review requests, unload media, release resources, etc. When the allocation cycle starts, nbrb sorts the list of jobs waiting for allocations, and looks at each item in the list sequentially. It either: Allocates the resources and crosses it off the list Or marks it for later evaluation. The resource broker (nbrb) maintains a set of queues for the requests and allocations: A queue for requests it receives, referred to as the inbound queue. A queue for requests it is currently evaluating. A queue for requests processed that need to be transferred to the media server, referred to as the outbound queue.

6| Page

The process exposes a CORBA interface to nbjm and it uses nbemm's exposed CORBA interfaces for the purposes of passing resource requests and updates. It may be helpful to note that nbjm is nbrbs client, and nbrb is emm(mds)s client. It uses a timer to schedule tasks to include the start of an evaluation cycle, real releases, bptm report drives process, etc. The default timers are as follows: Every 300 seconds nbrb will wake up and look for entities that require servicing, such as releases, new requests, etc. We haven't seen a need to change this ever. Every 10 minutes nbrb will initiate a bptm report drives process. o Reports the actual status of the drives. Failure can cause media servers to be marked offline in emm. For each evaluation cycle, nbrb completes the following, in this order: Read in the nbrb.conf file or configuration settings contained in the emm database (depending on version). Add new jobs from the inbound job queue. Release allocations: These are allocations that are already marked to be released for jobs that have completed. Mark released drives as available. Build the drive/stu/stugrp cache (the evaluation loop timer is started here). Evaluate requests in prioritized areas: o span requests and subsequent resource requests for duplication jobs already active and requests that are allocated but have a pending condition associated with them. these are known as high priority requests o Everything else. User type backup jobs will be sorted to the top of the lists after the high priority requests. Look for drives to unload [the drives that are released and are not used for MEDIA_UNLOAD_DELAY seconds], start unloading drives. Common items that impact the evaluation cycle: There are many variables that will impact the time it takes nbrb to allocate resources for a specific job. The most common of those items, along with very basic details about them are listed below: Tuning parameters specific to nbrb. o This will be discussed in detail in the next topic. Tuning parameters specific to emm. o There is only one write DB connection. Tuning parameters implemented in emm.conf will not increase the number of threads allowed to write More read/update threads are not better in many circumstances. High numbers of threads configured in emm.conf will not help performance of allocations and may hinder them as each emm thread may consume 200 to 400 MB of memory each.

7| Page

* For more information on the algorithms available for storage units, , see the NetBackup Administration Guide, for 6.5, volume 1, Chapter 5 Storage units, unit groups, and lifecycle policies.

The storage unit group configuration may slow down the allocation cycle. How much of an impact will depend on the algorithm used and the number of storage units within the group and their availability. In general: o The more storage units in a group the longer the allocation will take. It is not recommended to have more than 5 storage units within a group. o The algorithm selected will also impact the time it takes to allocate resources.

Duplication jobs, such as vault, SLP and disk staging jobs will take longer to allocate due to the requirement of more than one physical resource. Policy configuration variables that impact allocations: o The number of backups allowed per policy and client o The number of copies. o The type of backup o Application backups such as oracle will spawn a dummy allocation prior to starting the backup. o Schedules that have a variety of different mpx and retention level settings. This can cause drives to not be used at full capacity as one off backups consume drive resources. Poor disk i/o. o The nbrb process uses SQL database heavily for storing its state (allocations, drive info, and other stuff). If the disk I/O is slow, the allocation cycle will slow down. If logging levels are set to a high level, and there are many logs being generated, this may slow down the allocation cycle as the processes cache data to be written to the logs. In general the log level should be set to the default level which is 1. If the customer is facing any issue and symptoms show that this is because of RB, the debug log level should be set to 4. In some extreme cases, where we think that the problem could be because of slow SQL operations, the debug level should be set to 5. nbjm updates bpjobd via bpcompatd connection every 10 seconds. The bpjobd process is single threaded; if bpjobd updates are slow, job updates will not get populated to the activity monitor in a timely manner and jobs may appear to be queued, but actually have resources and be active. Hardware issues o Library or drive issues cause problems with allocations. If a robot is down or having sporadic communication issues, mounts/unmounts may take substantially longer or may have to be retried many times before succeeding. If a drive is unavailable, nbrb will need confirmation that the drive has been unloaded prior to allowing it to be reallocated. At times this may take a substantial amount of time.

8| Page

Media servers being marked offline. o Media servers can be marked offline for several reasons: EMM does not get heartbeat from the media server (vmd/ltid). bpstsupdate is spawned every 5 minutes to poll any disk drives. If this fails, disk allocations will not occur until a status is received.
Nbrb polls drives every 10 minutes from the media servers to get current status. If nbrb doesnt receive a response or the report drives fails, the media server will be marked offline.

Communication issues. o Corba transient errors can occur if media and master servers are unable to communicate effectively. This can slow down unloads, updates and a variety of other issues. Home grown scripts that are passing invalid parameters can cause load on the system and emm database. This can cause delays if there are enough emm update or queries being run. Insufficient resources, such as available memory. Unneeded entries in bp.conf that will trigger host name lookups. o CONNECT_OPTIONS These are only for media server related connections. Client systems should not be listed. They should be configured in the Master Server Host properties Client attributes tab and NOT the Master Server Host properties Firewall tab. * o Invalid SERVER or MEDIA server entries. Clients listed in the Master Server Host properties Client attributes tab that are not resolvable.

**For more information on the Client attributes and Firewall tabs in Master Server Host properties, see the NetBackup Administration Guide, for 6.5, volume 1, Chapter 7, Host Properties.

SQL DB, legacy catalogs and logs can get pretty big. It is highly recommended to keep them on separate disk spindles. Often these files are kept on fancy SAN disks enclosures. If that is the case, please make sure they are configured properly. To measure the performance, focus on both read and write to the disks. We have seen at least two cases where these files were on a fancy SAN disk. The read operations were super fast but the writes were very slow. A large emm transaction log (NBDB.log file). Sizes of the NBDB.log will vary based on the number of transactions that occur in the period since the last backup. If the transaction log grows to large (too large is qualified as 1 to 2GB in size), allocations will slow down. If that occurs, one of two things must be done immediately to eliminate the problem. o A) A hot catalog backup which will truncate the transaction log. Unfortunately sometimes the allocations have slowed down so much that the catalog backup cant get resources. Then Item B MUST BE COMPLETED in order alleviate the issue. o B) Use the /usr/openv/db/bin/dbadm (Unix) or Program Files\Veritas\NetBackup\bin\NbDbAdmin.exe (Windows) tool to manually truncate the log.

9| Page Old files in /usr/openv/netbackup/db/media/drives (UNIX) / Program Files\Veritas\NetBackup\db\media\drives (Windows) on the media servers. These files contain information about the current drive status such as drive name, o/s path, pid, etc. If any information in those files matches anything in emm or nbrb the drive will not be allocated again. By default, these files are cleaned up when bptm exits. Files may be left in the directory if a power outage occurs or if administrators kill the bptm processes. O/S or application bugs impacting the systems ability to process i/o functions. Insufficient O/S file descriptors. A minimum of 8000 is required.

Tuning parameters available in nbrb There are many tuning parameters available that impact how the evaluation cycle runs. The full list is not provided in this document, only the nbrb.conf file (versions 6.5.2 through 6.5.6, 7.0 and 7.0.1) and nbrbutil command options (version 7.1 and later) will be addressed as this is the most frequently tuned. The nbrb.conf file was introduced in the NetBackup version 6.5.2 release and is applicable to every release of the software until the 7.1 release when the tuning parameters were moved into the emm database. At version 7.1, the nbrbutil command is used to manipulate the settings. The nbrb.conf file in versions 6.5.2 through 6.5.6, 7.0 and 7.0.1: This file can be added to a master server in the following paths: UNIX: /usr/openv/var/global Windows: <install_path>\Veritas\var\global The file can contain the following variables: **The behavior changes somewhat at different patches and releases. See the examples for additional details for each specific version. SECONDS_FOR_EVAL_LOOP_RELEASE o If this value is set, nbrb will stop every N seconds specified by this conf. RESPECT_REQUEST_PRIORITY o This parameter will control the behavior of how nbrb will break out of a cycle. This is set to 1 (true) or 0 (false) For 1/true, nbrb will consider jobs waiting in the inbound request queue. For 0/false, nbrb will NOT consider jobs waiting in the inbound request queue. o If RESPECT_REQUEST_PRIORITY is set to 1, or true, then nbrb will stop, perform cleanup and restart the evaluation cycle from the top of the list. NOTE that the total time of the evaluation cycle will not include releasing of resources and drives the evaluation cycle. When nbrb breaks out of an evaluation cycle and start from the top of the list, it does two things which may be an advantage: New requests are picked up. High priority jobs (in the normal queue), which are at the top of the queue, gets a higher chance of running. o In patch 6.5.5, we always evaluate high priority queue when we break.

10 | P a g e If RESPECT_REQUEST_PRIORITY is set to 0, or false, nbrb will NOT add more requests to the list during breakout. The purpose of tuning the SECONDS_FOR_EVAL_LOOP_RELEASE and not enabling RESPECT_REQUEST_PRIORITY is to release the resources for the completed jobs, rebuild the cache list of drives available which may allow allocations to be serviced more rapidly. Additional considerations for RESPECT_REQUEST_PRIORITY If set to 1, the time reported in msec should be close to the time specified in the SECONDS_FOR_EVAL_LOOP until revision 6.5.5 with nbrb EEB from ET 1924099 and 6.5.6. This is outlined in more detail later. If set to 0, the evaluation cycle will still be interrupted. But we will continue from where we left off. The msec reported in the log files will be the entire time it takes for nbrb to make it through the list of jobs its currently reviewing. If set to 0, and BREAK_EVAL_ON_DEMAND = 1 is set, the cycle will be interrupted to satisfy the high priority requests for span requests and subsequent images of a duplication job. If set to 1, and and BREAK_EVAL_ON_DEMAND = 1 is set, the cycle will be interrupted to satisfy the high priority requests for span requests and subsequent images of a duplication job, AND THE SECONDS_FOR_EVAL_LOOP timer will be reset without reviewing the jobs waiting in the inbound queue.

DO_INTERMITTENT_UNLOADS o This will impact whether or not nbrb will unload drives after the SECONDS_FOR_EVAL_LOOP_RELEASE timer has been met. This is set to 1 (true) or 0 (false) 1/true, nbrb will initiate drive unloads as needed. 0/false, nbrb will not unload drives. MAX_HIGH_PRIORITY_QUEUE_SIZE (NetBackup versions 6.5.4 with later revisions of ET1747025 and 6.5.5) o Maximum number of HIGH priority request to consider (after this they are treated as regular request). This is represented by an actual number. o As stated previously, nbrb high priority requests are span requests and subsequent images of a duplication jobs. BREAK_EVAL_ON_DEMAND (NetBackup versions 6.5.4 with later revisions of ET1747025 and 6.5.5) o Break the evaluation loop to when a new high priority request comes in or the timer expires. This is set to 1 (true) or 0 (false)

The nbrbutil options at version 7.1 and later. The nbrbutil command can be used to manipulate the configuration settings that are now stored in the emm database. The options that impact these settings are the following:

11 | P a g e -changeSettings <name=value>[,name=value] configuration settings -deleteSetting <setting name> setting -listSettings settings -- Add or change the NBRB -- Delete a NBRB configuration -- List the NBRB configuration

To list the current configuration settings, the following command can be used: nbrbutil listSettings The output will vary depending on the current configuration. If no options have been set, and the default options used, no output will be returned. To add or change a setting, the changeSetting flag will need to be used. The name parameters that replace the nbrb.conf file settings are as follows: nbrbutil changeSetting name nbrb.conf file setting RB_RELEASE_PERIOD SECONDS_FOR_EVAL_LOOP_RELEASE RB_RESPECT_REQUEST_PRIORITY RESPECT_REQUEST_PRIORITY RB_DO_INTERMITTENT_UNLOADS DO_INTERMITTENT_UNLOADS RB_MAX_HIGH_PRIORITY_QUEUE_SIZE MAX_HIGH_PRIORITY_QUEUE_SIZE RB_BREAK_EVAL_ON_DEMAND BREAK_EVAL_ON_DEMAND *** true and false should be used instead of 1 and 0 when running nbrbutil -changeSettings Other tuning options for nbrb. Additional options are available for tuning nbrb. The following items were addressed as bp.conf file parameters in earlier versions of NetBackup and are also available as flags that can be used with nbrbutil changeSettings. These settings will not be covered in-depth in this document as they are not as frequently utilized as the other options. nbrbutil changeSetting name RB_ENABLE_OPTIMIZATION RB_CLEANUP_OBSOLETE_DBINFO RB_MPX_GROUP_UNLOAD_DELAY RB_RETRY_DELAY_AFTER_EMM_ERR RB_REEVAL_PENDING RB_REEVAL_PERIOD bp.conf file setting NBRB_ENABLE_OPTIMIZATION NBRB_CLEANUP_OBSOLETE_DBINFO NBRB_MPX_GROUP_UNLOAD_DELAY NBRB_RETRY_DELAY_AFTER_EMM_ERR NBRB_REEVAL_PENDING NBRB_REEVAL_PERIOD

Additional information on nbrbutil and options available with this command are located in the Symantec NetBackup Commands Reference Guide for UNIX, Windows and Linux, Release 7.1

12 | P a g e

Examples of nbrb behavior with common configuration settings, at various versions of NetBackup:
The impact of the above parameters will vary depending upon the patch revision of NetBackup. Major changes to the behavior are outlined below: NetBackup version 6.5.2 (6.5.1 with EEBs): First availability of the nbrb.conf. If the file was not present, nbrb would not break an evaluation cycle. Upon start of the evaluation cycle, nbrb builds the list of jobs that require allocations. Once this list was generated, nbrb would sequentially read through the list of items requiring allocations until each item was reviewed without unloading drives or adding waiting jobs. NetBackup version 6.5.4: Introduced default parameters for nbrb without the presence of nbrb.conf. Those defaults are: SECONDS_FOR_EVAL_LOOP_RELEASE = 180 RESPECT_REQUEST_PRIORITY = 0 DO_INTERMITTENT_UNLOADS = 1

13 | P a g e

NetBackup version 6.5.4 with the latest nbrb cumulative binary from ET 1747025 and 6.5.5: This version introduced the following settings and their defaults: MAX_HIGH_PRIORITY_QUEUE_SIZE = 100 BREAK_EVAL_ON_DEMAND = 1 The above would cause nbrb to break when a high priority request (span request or subsequent image of a duplication job) would be received.

14 | P a g e

15 | P a g e

NetBackup version 6.5.5 with the nbrb binary (EEB3) from ET 1924099, 6.5.6 and all versions of 7.0 and 7.1: Note: The nbrbutil changeSettings flags and nbrb.conf parameters are interchangeable. For this example the nbrb.conf file setting names are used. At this version of NetBackup RESPECT_REQUEST_PRIORITY = 1 would no longer trigger an automatic restart of the evaluation cycle once the SECONDS_FOR_EVAL_LOOP was met or exceeded. At these versions, nbrb is aware of job priority and will only break completely out of the evaluation cycle if the policy priority of jobs waiting in the inbound queue is higher than the policy priority of the job nbrb is currently reviewing. With RESPECT_REQUEST_PRIORITY is set to 1, when the SECONDS_FOR_EVAL_LOOP_RELEASE is met/exceeded: If there is a job with a higher priority job waiting, nbrb will break and restart the evaluation cycle from the beginning to read in the new jobs. If there are no jobs of a higher priority, then nbrb will unload drives, release resources, rebuild the mds cache and then start evaluating the jobs from the point in the list where it left off. With RESPECT_REQUEST_PRIORITY is set to 0, when the SECONDS_FOR_EVAL_LOOP_RELEASE is met/exceeded: Nbrb does not review waiting jobs. It unloades drives (IF DO_INTERMITTENT_UNLOADS = 1). Releases resources. Rebuilds the cache Resumes reviewing jobs where it left off. With BREAK_EVAL_ON_DEMAND = 1 This will trigger interrupts of the evaluation cycle for events. Those events are limited to the arrival of a high priority request (NOT to be confused with a high priority job) such as a span request or a subsequent request of a duplication job. o With RESPECT_REQUEST_PRIORITY = 0, when interrupted, nbrb will evaluate the high priority request(s) and then proceed from where it left off () . o With RESPECT_REQUEST_PRIORITY = 1, when interrupted, nbrb will check if there are any waiting requests with a priority higher than the last evaluated. IF YES, nbrb starts at the beginning after it adds the new jobs. IF NO, then nbrb starts where it left off. It will cause the SECONDS_FOR_EVAL_LOOP timer to be reset.

16 | P a g e

Example 6.5.5 with EEB3, 6.5.6, 7.0, 7.0.1, 7.1 with Respect Request priority = 1 Given the following configuration values: SECONDS_FOR_EVAL_LOOP_RELEASE = 180 RESPECT_REQUEST_PRIORITY = 1 DO_INTERMITTENT_UNLOADS = 1 BREAK_EVAL_ON_DEMAND = 1 MAX_HIGH_PRIORITY_QUEUE_SIZE = 100
At this version of NetBackup, when nbrb starts an evaluation cycle the first steps are the same as in previous versions. The behavior is the same UNTIL EITHER a) a high priority request is received or b) the 180 second timer is met/exceeded. When the 180 second timer is met/exceeded, the v nbrb process pauses, checks the inbound queue for jobs with a higher priority than the one it is currently reviewing. If no jobs are present in the queue, nbrb continues where it left off after unloading drives, releasing resources and rebuilding the cache. Prior to the 180 second break, a high priority job is received, nbrb will break out of the current cycle, unload drives, release resources and rebuild the mds cache prior to reviewing the high priority job. THIS RESETS the 180 second timer. Again, prior to the 180 second break, a high priority job is received, nbrb will break out of the current cycle, unload drives, release resources and rebuild the mds cache prior to reviewing the high priority job. THIS RESETS the 180 second timer. 180 second timer met/exceeded, nbrb unloads drives, releases resources, checks the inbound queue for jobs that are a higher priority than the job it last reviewed. IF a higher priority job is waiting, nbrb will read the new jobs in; if not, it resumes evaluating where it left off without reading in the The nbrb process now reaches the end of the list. Finally new jobs waiting in the inbound queue are read into the list of items nbrb is evaluating. End of list. Nbrb restarts the evaluation cycle including reading in waiting jobs.

NOTE: AT THESE VERSIONS nbrbs eval cycle can be interrupted by an event (the event being the arrival of a high priority request [span or subsequent request of a duplication job]).

Cycle is started and runs for 180 seconds, reviewing jobids 1 30.

No jobs of higher priority present, resume evaluation at jobid 31.

High priority job is received (jobid 72). The timer is now reset. Jobid 72 is evaluated, then nbrb will start where it left off prior to being interrupted.

High priority job is received (jobid 85). The timer is again reset. Jobid 85 is evaluated, nbrb again starts where it left off.

180 second timer met/exceeded. There are jobs are waiting in the inbound queue, but they are NOT a higher priority than the current job. NBRB does not read the jobs in.

17 | P a g e

References: TECH52801: Veritas NetBackup 6.5 Administrator's Guide for UNIX and Linux, Volume 1 http://www.symantec.com/docs/TECH52801 TECH52803: Veritas NetBackup 6.5 Administrator's Guide for Windows, Volume 1 http://www.symantec.com/docs/TECH52803 TECH52859: Veritas NetBackup 6.5 Troubleshooting Guide for UNIX, Linux, and Windows http://www.symantec.com/docs/TECH52829 DOC3684: Symantec NetBackup 7.1 Commands Reference Guide http://www.symantec.com/docs/DOC3684 DOC3653: Symantec NetBackup Administrator's Guide for Windows, Volume 1 http://www.symantec.com/docs/DOC3653 DOC4483: Symantec NetBackup 7.0 - 7.1 Backup Planning and Performance Tuning Guide http://www.symantec.com/docs/DOC4483 TECH64845: Storage unit group considerations: http://www.symantec.com/docs/TECH64845 TECH164638: BUG REPORT: The nbrb allocation cycle doesn't break properly when the evaluation loop timer is met, which causes delays in allocating resources. http://www.symantec.com/docs/TECH164638 TECH158713: Netbackup jobs queue even though sufficient resources are available http://www.symantec.com/docs/TECH158713 HOWTO33588: About the Transaction Log Management menu options http://www.symantec.com/docs/HOWTO33588 TECH168846: Insufficient system file descriptors can cause the EMM_DATA.db file to grow very large. http://www.symantec.com/docs/TECH168846