User Initiated Backup Priorities in Netbackup 7.1

[jmanini]

Is there anyway to overide the fact that a user initiated backup goes to the end of the line. No matter how we set prioroty it still gets queued. I understand that the pecking order has these last but was wondering if there way any way to chnage that.

[RonCaplinger]

The priority is pulled from the Master Server's "Default Job Properties", and these only seem to be used for job types (backup, label, duplication, etc.), nothing for user-initiated backups. 

[J_H_Is_gone]

The user backup uses a policy - you can set job priority in the policy.

[jmanini]

If you do a user iniitated backup the prioity level of the policy is ignored every time and the job is put at the end of the line. The priority only seems to work if the policy's schedule kicks it off... In our case User Initiated backups should always take priority but Netbackups model is the opposite it seems and cannot be changed as far as I know...it would be nice to have total control

[Marianne]

If the user initiated job requires a different tape (due to volume pool or retention), priority will be given to queued backups that can use the same tape (same pool, same retention).

See this section in http://www.symantec.com/docs/HOWTO33114

The following scenarios present situations in which a request with a lower priority may receive resources before a request with a higher priority:

• A higher priority job needs to unload the media in a drive because the retention level (or the media pool) of the loaded media is not what the job requires. A lower priority job can use the media that is already loaded in the drive. To maximize drive utilization, the Resource Broker gives the loaded media and drive pair to the job with the lower priority.

• A higher priority job is not eligible to join an existing multiplexing group but a lower priority job is eligible to join the multiplexing group. To continue spinning the drive at the maximum rate, the lower priority job joins the multiplexing group and runs.

• The Resource Broker receives resource requests for jobs and places the requests in a queue before processing them. New resource requests are sorted and evaluated every 5 minutes. Some external events (a new resource request or a resource release, for example) can also trigger an evaluation. If the Resource Broker receives a request of any priority while it processes requests in an evaluation cycle, the request is not evaluated until the next evaluation cycle starts.

[jmanini]

Hi Marianne, we find that in every case where a user initiated job is kicked off even with the same retention as all of the other jobs be written to tape that the user-initiated job's priority is ignored. I understand the retention point which I've explained to the admins complaining. I have set up a policy where the only schedule was user-initial and set the priority to 500 and right to the end to wait in line...Now if it were not user based it goes right to the front. Weird but not the first thing I saw that did not work as designed....Like calendar based scheduling crossing midnight :)

[Andy_Welburn]

for that high priority job (e.g. drives), then it will not "jump the queue" no matter how high a priority you set due to the reasons Marianne has stated.

This has tripped people up on several occasions. The only way, in the instance where resources are unavailable, would be to suspend those lower priority jobs utilising those resources (including any queued jobs that may also require same), starting the higher priority job so that it claims the limiting resource & then resuming the suspended jobs (which will subsequently queue).

Other than that, if your limiting resource is drives you could try & amend your STU's such that you always have a drive available for user directed backups - this could be seen as a bit of a waste though.

I think the only time I've seen a job "jump the queue" was once for a restore - when the currently running backup "paused" to mount a fresh tape, the restore jumped in & the backup queued until it was completed.

***EDIT*** Wrote the above as you were responding to Marianne's post.

What is the limiting factor for the queued user directed backup? i.e. the one quoted by NB in the Activity Monitor/Job Details

[J_H_Is_gone]

Only thing I can think of is create a storage unit of 1 drive and assign it to this policy.

than it would not have to wait for a drive in the currently used storage unit to become avail, AND if there is and un-used tape drive avail - it would be able to mount a tape right away and go to that tape/drive.

[jmanini]

I have an admin doing an oracle backup by taking it offline then he does a user initiated backup directly to tape and then puts the DB back on line. When he does this it always goes to the back of the line no matter what the priority level or retention level is. Even if the retention is the same it will sit until all of the other scheduled backup policies finish. So he complains the the DB stays down the entire time he is waiting. I told him to change the way he using NetBackup and to at least take the DB offline...zip the files somewhere locally real quick, put the DB back online and then do a normal scheduled backup by using one of my presetup policies. Anyway but the way he is doing it.

[Marianne]

I still feel there is SOMETHING different about this schedule that requires a new tape mount or will require this job to run on it's own. Are other schedules (same stu, same pool, same retention) running as multiplexed and this one not (mpx = 1)?

[jmanini]

No the only thing that makes these jobs differenct is that they are user initiated. the renetions are the same...weird but I'm having them change their ways so that this does not happen anymore.