Hello,
This is a nice solution to the problem, and something that you might want to
keep indefinitely. However, the "problem" should be fixed in version 2.0.3.
Regards,
Kern
On Friday 16 March 2007 19:45, Darien Hager wrote:
> > On Thursday 01 February 2007 18:02, Jeronimo Zucco wrote:
>
> > Someone pointed out how to modify the code recently on this list
> > (it involves
> > modifying the SD).
> >
> > Another approach would be to run a "dummy" job that does the
> > ClientRunBefore -- it could be a Verify with an empty FileSet. The
> > real job
> > could then be scheduled after the dummy job using priorities or
> > whatever ...
> ============
>
> Executive summary: Just a followup for the lurkers and archive-
> readers... Here's a workaround for this problem based on a dummy-job
> approach.
>
> ============
> I encountered this problem too, when some DB prep scripts took too
> long (~50 min) to run on some clients before the data transferring
> phase, and editing the source seemed a bit of an invitation to
> maintenance and future installation trouble.
>
> My solution (which seems to work) is to have two jobs, a download-db-
> dumps job, and a preparatory job. The prep job is scheduled a little
> earlier and with a higher priority (smaller priority number) than the
> main download job.
>
> The prep job uses an empty fileset and runs the prep script *after*
> the bulk of the job. If you run it before, then when it takes too
> long it will generally result in failed job because the client can't
> connect to the SD (despite having nothing to transfer), so you get
> annoying emails even when everything actually worked fine. Prep Sample:
>
> RunScript {
> Command = "bash -c \"/etc/bacula/dbdiffs.py /var/
> bacula/db_backups/; echo $? > /var/bacula/db_backups/rval.dat\""
> RunsWhen = After
> RunsOnClient = yes # BUG in Bacula 2.01, cannot use
> uppercase Y in Yes for RunsOnClient.
> }
>
> So it runs the script and stores the return value ($?) into a file.
> Then the real backup script checks that file, and if the file does
> not exist or has a nonzero error code, the main backup will fail.
> Main script sample:
>
> RunScript {
> Command = "/etc/bacula/exitval.sh /var/bacula/
> db_backups/rval.dat"
> AbortJobOnError = yes
> RunsWhen = Before
> RunsOnClient = yes # BUG in Bacula 2.01, cannot use
> uppercase Y in Yes for RunsOnClient.
> }
>
> Exitval.sh reads the file and exits with the value contained therein.
> In effect, this allows you to run scripts of >30 mins and still have
> Bacula tell you when they fail. Furthermore, in case they corrupted
> your database dumps at the same time, Bacula won't do the backup.
>
> --
> --Darien A. Hager
> [EMAIL PROTECTED]
> Mobile: (206) 734-5666
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
