Bacula-users

Re: [Bacula-users] Serializing catalog backup

2011-01-10 16:51:54
Subject: Re: [Bacula-users] Serializing catalog backup
From: Mike Ruskai <thannyd AT earthlink DOT net>
To: bacula-users AT lists.sourceforge DOT net
Date: Mon, 10 Jan 2011 16:49:17 -0500
On 1/10/2011 4:20 PM, Phil Stracchino wrote:
> On 01/10/11 15:48, Mike Ruskai wrote:
>    
>> I know how to backup the database.  That's not my question.  My question
>> is how to create a schedule, in an environment with multiple concurrent
>> jobs, that guarantees that the catalog backup runs after all other
>> scheduled jobs, and by itself.
>>
>> So if I have three machines currently running a backup job
>> simultaneously, the catalog backup has to wait until they finish, even
>> if the maximum number of concurrent jobs is four.  Once they do finish,
>> and the catalog backup starts, no other jobs can start until the catalog
>> backup is complete.
>>
>> Can this be done in Bacula, or do I need to do custom synchronization in
>> run-before scripts?
>>      
> If you set the Catalog job to a lesser priority (say, 15, where the
> highest priority is 1, and most normal jobs are priority 10), you
> guarantee that the Catalog job will not be started while any
> higher-priority job is running.
>
> Guaranteeing that no higher-priority job can start while the Catalog job
> is running is a more difficult problem, but one that usually isn't an
> issue unless you typically have jobs running around the clock and being
> started at varying intervals.  However, since the DB dump or snapshot
> that typically starts most DB backup schemes should be an atomic
> operation that occurs with the tables locked, if another job starts
> while your catalog job is running it really shouldn't matter.  It's not
> going to be able to modify the catalog while the catalog is being dumped.
>
>    
I should have read more carefully about concurrent jobs.  It seems that 
enabling it basically kills your ability to prioritize jobs, since only 
jobs of the same priority run at the same time (and the mixed priority 
option only minimally changes that).  So if there are X concurrent jobs, 
and X currently running jobs, it's not possible to queue up another ten 
jobs and have them consume the available backup slots in a specific 
order based on priority.  They will presumably run in the order they are 
started, which means the scheduler has to take over as the priority manager.

So simply having the catalog backup be a different priority ensures that 
no other job can run at the same time, provided mixed priorities are 
disallowed (that would allow the higher-priority backup jobs to start 
while the catalog backup is under way).  Which is just as well, since I 
don't like the idea of relying on database or table locks.



------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users