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.
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. 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? 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. 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
