On Tue, 27 May 2008, Tore Anderson wrote:

> [1] It actually says that it's waiting for jobs with _higher_ priority
> to finish, which is incorrect;  the jobs running all have a _lower_
> priority than the job waiting first in line.

Yes, I've commented on this in the past.

> I thought the priority would only control how a job would sort in the
> queue while waiting for a storage definition or tape drive to become
> available, but I guess I was mistaken.

I thougth the same thing originally.

>  If I start a restore job I want it to be processed ASAP (ie. only wait
> until the first running job has finished, not all of them), to be the
> first one to grab the tape drive if several jobs are waiting for it, and
> also to not impact the overall backup performance more than necessary
> (let the other nine jobs keep running and allow new jobs to start).  Is
> this possible?

The only way I've found for restores is to make sure they're the same
priority as the rest of the jobs.

On a practical note - Job priorities are _very_ useful for ensuring that a
particular job is the only one running when it runs - eg during catalog
backups.

We make our users jump through hoops for restores - mainly because we
don't want them to become dependent on the things. Grabbing a file off
backup tape should be last resort. As part of this hoop jumping we enforce
a minimum waiting period for restore requests (a few hours) which is
usually long enough to allow for full execution queues or higher priority
jobs.

AB


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users