"David Jurke" <[EMAIL PROTECTED]> 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users