"David Jurke" <David.Jurke AT tnzi DOT com> writes:

> I think it'd need some tweaking to delay putting each tablespace
> into backup mode until Bacula is ready to back it up - one of the
> problems I have is that we can't put all the tablespaces into backup
> mode at the same time because of the volume of logs produced.

the open of the FIFO will not return until Bacula is there wanting to
read the data, so do the locking after the "Dumping $ts" line.

> Perhaps I could run a script before the backups start to query the
> database for a list of tablespaces, and build a set of Bacula job
> configs, one per tablespace, then tell Bacula to reload its config.

you could do that, but I don't think you gain anything.  the code I
included is intended to be a pre-script, where the @tablesspaces
initilisation at the top should be replaced by a database query.

> In fact, Would I need to dump the database to anything? Wouldn't I
> just have a pre-backup job to put the tablespace into backup mode,
> bacula that tablespace's file straight to tape, then a post-backup
> to put the tablespace back to normal?

indeed.  with my script, you don't actually have a post-backup script,
though -- the tablespace twiddling is done in the FIFO handling
process which exits as soon as Bacula is done reading.

-- 
regards,          | Redpill  _
Kjetil T. Homme   | Linpro  (_)


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users