Re: [Bacula-users] Running Jobs simultaneously on two streamers of same type - Sorry to come back up ;-) with this again

2006-03-30 Thread Christoff Buch

Hello,

meanwhile I really tried to get it on
my own, but looking at page 135 of Bacula Manual Version 1.38.5 just knocks
me out.

On line one and two it says:
.. all queued jobs of priority
1 will run before queued jobs of priority 2 and so on, regardless of the
original scheduling order.

While in the last paragraph it says:
If you have several jobs of different
priority, it may not best to start
them at exactly the same time, because
Bacula must examine them
one at a time. If by Bacula starts a
lower priority job first, then it will
run before your high priority jobs.
If you experience this problem, you
may avoid it by starting any higher
priority jobs a few seconds before
lower priority ones. This insures that
Bacula will examine the jobs in
the correct order, and that your priority
scheme will be respected.

I assume the last paragraph applies
regardless of jobs running concurrent or not. Is that right?

If yes:
For me, it sounds like the whole concept
of priorities is obsolete and job order has to be managed all by schedules.
Right?
I mean if priorities are only respected
correctly as long as jobs are started (by schedules) in the according order
(because bacula needs to examine them in just this order to be able to
respect those priorities correctly) - what do I need priorities for
It all depends on the schedules then.
Or did I miss it completely?

Coming back to my original concern:
As a pro user I have, as mentioned before,
backup-servers each controlling several streamers of the same type.
The amount of data per day is relatively
high.
So I want to be finished with backups
in the morning to service my users with restores if need be.
In other words I want the respective
jobs go parallel on the streamers, not sequentially.

I think I understand why concurrent
jobs are not recommended if going on only one streamer.
But this should be not a problem with
two or more jobs each going on an extra streamer. Right?
Basically, can bacula manage that at
all?
If yes, how should I enable it?
Has this, in my case, to do with Maximum
Concurrent Jobs at all?
Can I leave Maximum Concurrent
Jobs = 1 in the Storage Resource of the director's conf? (see my
configuration in original mail, please)
Take out priorities completely?
Give each job an own schedule and giving
them intervals of, say, a minute?


Kind Regards,

i. A. Christoff Buch

=
[EMAIL PROTECTED]
OneVision Software AG
Dr.-Leo-Ritter-Str. 9
93049 Regensburg

Re: [Bacula-users] Running Jobs simultaneously on two streamers of same type - Sorry to come back up ;-) with this again

2006-03-30 Thread John Kodis
On Thu, Mar 30, 2006 at 04:21:59PM +0200, Christoff Buch wrote:

 For me, it sounds like the whole concept of priorities is obsolete and job 
 order has to be managed all by schedules.
 Right?
 I mean if priorities are only respected correctly as long as jobs are 
 started (by schedules) in the according order (because bacula needs to 
 examine them in just this order to be able to respect those priorities 
 correctly) - what do I need priorities for

The one thing that I use schedules for is taken directly from the
example configuration: running a catalog backup immediately after all
the client backups have completed.  While jobs at the same priority
seem to normally run in the order in which they get queued up, there's
no guarantee of this.  There is such a guarantee with priorities.

-- John Kodis.


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] Running Jobs simultaneously on two streamers of same type - Sorry to come back up ;-) with this again

2006-03-30 Thread Arno Lehmann

Hello,

On 3/30/2006 4:21 PM, Christoff Buch wrote:


Hello,

meanwhile I really tried to get it on my own, but looking at page 135 of 
Bacula Manual Version 1.38.5 just knocks me out.


On line one and two it says:
.. all queued jobs of priority 1 will run before queued jobs of 
priority 2 and so on, regardless of the original scheduling order.


While in the last paragraph it says:
If you have several jobs of different priority, it may not best to start
them at exactly the same time, because Bacula must examine them
one at a time. If by Bacula starts a lower priority job first, then it will
run before your high priority jobs. If you experience this problem, you
may avoid it by starting any higher priority jobs a few seconds before
lower priority ones. This insures that Bacula will examine the jobs in
the correct order, and that your priority scheme will be respected.

I assume the last paragraph applies regardless of jobs running 
concurrent or not. Is that right?


If yes:
For me, it sounds like the whole concept of priorities is obsolete and 
job order has to be managed all by schedules.

Right?


I don't think so.
See below.

I mean if priorities are only respected correctly as long as jobs are 
started (by schedules) in the according order (because bacula needs to 
examine them in just this order to be able to respect those priorities 
correctly) - what do I need priorities for

It all depends on the schedules then.
Or did I miss it completely?


Not completely :-)

I'll give an example I use:
I've got the whole Bacula setup allowing multiple simultaneous jobs; 
distributed over several storage devices, up to 12 jobs can run 
simultaneously.


I schedule all jobs at the same time, to utilize my backup window as 
good as possible.


Still I do have some jobs that must be run after the regular jobs: 
Database and LDAP catalog backups, and finally a job that shuts down the 
backup server.


To ensure proper execution order and to make sure the database backups 
are run after the regular filesystem ones - the database server would be 
seriously overloaded if those things ran simultaneously - I have all the 
regular backups at one priority level, the database backup runs at a 
lower priority, and the shutdown job has an even higher priority value.


Result: I have the jobs that must not run simultaneously running in 
parallel kind of blockwise.



Coming back to my original concern:
As a pro user I have, as mentioned before, backup-servers each 
controlling several streamers of the same type.

The amount of data per day is relatively high.
So I want to be finished with backups in the morning to service my users 
with restores if need be.
In other words I want the respective jobs go parallel on the streamers, 
not sequentially.


I think I understand why concurrent jobs are not recommended if going on 
only one streamer.


Spooling, not priorities would be the option I prefer. If you're short 
on disk space you can also limit the number of jobs running 
simultaneously on one storage device to one.


But this should be not a problem with two or more jobs each going on an 
extra streamer. Right?

Basically, can bacula manage that at all?


I'd say it can, because it does here.


If yes, how should I enable it?
Has this, in my case, to do with Maximum Concurrent Jobs at all?
Can I leave Maximum Concurrent Jobs = 1 in the Storage Resource of the 
director's conf? (see my configuration in original mail, please)


That's what I'd suggest if spooling is not an option for you.


Take out priorities completely?


Use priorities very carefully.
IMO, priorities are most useful as an additional means to ensure a 
defined job sequence, not to limit concurrency.



Give each job an own schedule and giving them intervals of, say, a minute?


Schedule the jobs in blocks, putting the same schedule into all jobs of 
the same priority, and keep some minutes between those blocks.


Arno



Kind Regards,

i. A. Christoff Buch

=
[EMAIL PROTECTED]
OneVision Software AG
Dr.-Leo-Ritter-Str. 9
93049 Regensburg


--
IT-Service Lehmann[EMAIL PROTECTED]
Arno Lehmann  http://www.its-lehmann.de


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] Running Jobs simultaneously on two streamers of same type - Sorry to come back up ;-) with this again

2006-03-30 Thread Christoff Buch





Mit freundlichem Gruß

i. A. Christoff Buch

=
[EMAIL PROTECTED]
OneVision Software AG
Dr.-Leo-Ritter-Str. 9
93049 Regensburg

John Kodis [EMAIL PROTECTED] wrote on 30.03.2006
16:42:43:

 On Thu, Mar 30, 2006 at 04:21:59PM +0200, Christoff Buch wrote:
 
  For me, it sounds like the whole concept of priorities is obsolete
and job 
  order has to be managed all by schedules.
  Right?
  I mean if priorities are only respected correctly as long as
jobs are 
  started (by schedules) in the according order (because bacula
needs to 
  examine them in just this order to be able to respect those priorities

  correctly) - what do I need priorities for
 
 The one thing that I use schedules for is taken directly from the
 example configuration: running a catalog backup immediately after
all
 the client backups have completed. While jobs at the same priority
 seem to normally run in the order in which they get queued up, there's
 no guarantee of this. There is such a guarantee with priorities.
 
 -- John Kodis.
 
Hi John,

Thanks for your reply!
So do you start your client jobs without
any schedules? How?
How can I determine the order jobs get
queued up? Is it the position in the bacula-dir.conf? (I don't wanna believe
I have to go down to this...)
Besides, I'm mainly concerned about
getting simultaneous jobs to run - and concerning this there's a problem
with priorities as you can see in my earlier mails.