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
Bacula-users@lists.sourceforge.net 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
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
