Re: [Bacula-users] Timing of Run After

[Eric B. <er...@ba...>]

Hello Ross,

On 2/1/25 22:06, Ross Boylan wrote:
> Apparently, ClientRunAfter scripts execute before the parent backup job is
> done.  In particular, the .bsr file for the `Write Bootstrap` directive had
> not been written when the client script ran.  In the documentation I don't
> see anything specific about the sequencing of RunAfter, ClientRunAfter, and
> WriteBootstrap relative to each other or to anything else.  It is
> retrospectively unsurprising that the client being done is not the same as
> the server being done.

That's normal, I believe that I wrote some documentation about the timing
in the manual, but the Job duration is not the same between daemons.

The Job will start on the director first, it can take time to actually
contact the FileDaemon and start the job on it. RunBefore and ClientRunBefore
and not done at the same time. At the end of the Job for the FileDaemon,
it means that we have nothing more to send and the Job is done. However,
the Director and the Storage Daemon might still have a lot to do.
For example, the Storage will despool the data, upload volumes to the cloud
despool attributes, The Director will insert the catalog data, etc..

The FileDaemon will disconnect and release resources as soon as possible.
We don't need to wait for the other tasks to complete.

> The script executing in ClientRunAfter uses the .bsr to figure out which
> volumes to copy to another system, and using the previous version sometimes
> causes it to miss recent volumes, as well as copying the old .bsr file
> itself.  The backup volumes are disk files.
> 
> I don't think I can run the script, which needs to run as root, in a 
> (server) RunAfter script since the server runs as bacula while the fd client
> runs as root.  That was the only reason I didn't just use RunAfter.  The
> client and server are the same machine.

The RunAfter is done on the Director side, which is "bacula" by default.
It sounds just the right thing to do.

You can also email the bootstrap file using the Message resource for example.

> So, two questions:
> 
> First, what can I assume has been completed before Client or server Run
> After scripts execute?  Which of the directives for the job will have been
> acted on?  What is the state of the database and the volumes being
> written?   Is there a risk of a race condition in which writing a volume
> or .bsr to disk is incomplete or updating the database is incomplete?

Using RunAfterJob on the Director side should be OK, it's done just before
the JobEnd event.

> Second, any suggestions about how to get around the sequencing problems I've
> encountered? It may be relevant that the system the script is copying to is
> a Mac. The bacula website says that is supported, but the only binaries I 
> found were ancient.

We have binaries for Mac on the web site, they are not very old but we have
only the FD. You must compile the other daemons and adjust the different
procedures to start them.

Best Regards,
Eric

> Thanks. Ross
> 
> bacula 9.6.7 on Debian GNU/Linux 11.11 (= bullseye = oldstable)
> 
> 
> _______________________________________________ Bacula-users mailing list 
> Bac...@li... https://lists.sourceforge.net/lists/
> listinfo/bacula-users


-- 
Best Regards,
Eric


Eric Bollengier
Director of Engineering

Bacula Systems SA
Av. des Sciences 11
1400 Yverdon-les-Bains
Switzerland