Hi Rob,
Thanks. I had almost arrived at this type of solution, but a little less clean. Le lundi 06 janvier 2025 à 17:07 -0600, Rob Gerber a écrit : > Dummy resources are certainly possible. > > A fileset like you describe could simply lack any file definitions. > It's that simple, I think. Bill A has some dummy definitions he uses, > and I've adopted them. I've pasted a past email from Bill on this > subject below. > > The words below this line were written by Bill A and NOT by me. > > The parser sees that it is parsing a Job resource, and then requires > all the settings for a Job resource, and does not > distinguish a Backup type job from an Admin one, or Copy, or Verify > etc. This had annoyed me also for some time, but I > suspect the developers will never want to spend time on making this > distinction when parsing resources. :) > > What I have been doing in my Bacula environments for many years is I > create some "dummy/fake" resources and use them in > places where the parser requires them but they are clearly not > needed/used. > > The nice (OCD?) thing here is that in my Copy, Migration, Admin, > Restore, etc job logs and summaries, it is clear that no > Fileset, or Client, or Storage, etc was really used. > > The same is true when viewing Job listings in BWeb, Baculaum, Bacula- > Web, Bacularis, or in my > https://github.com/waa/baculabackupreport script. ie: It is > explicitly clear that a Copy/Migration Control job (for example) > in the list contacted no Client. > > In each of my fake resources, I have just the bare minimum required > to satisfy the parser fro that type of resource. I name > them all "None" (there is funny bug in my reporting script story > about this - Python programmers will know straight away :) > and I use them in special jobs as mentioned above. > > > Fake Client for copy jobs, etc: > ----8<---- > Client { > Name = None > Address = localhost > Password = N/A > @/opt/comm-bacula/include/Clients-Defaults # Some required things > for all Clients like FDPort, Catalog are in here > } > ----8<---- > > Fake Fileset for copy jobs, etc: > ----8<---- > Fileset { > Name = None > Include { > Options { > Signature = md5 > } > } > } > ----8<---- > > Fake Storage for admin jobs, etc > ----8<---- > Autochanger { > Name = None > Address = localhost > Enabled = no > Device = N/A > Password = N/A > Media Type = None > } > ----8<---- > > Fake Pool for copy jobs, etc: > ----8<---- > Pool { > Name = None > PoolType = Backup > } > ----8<---- > > Fake Schedule with no run times. This way I can implicitly see what > are my "Manually run" jobs: > ----8<---- > Schedule { > Name = Manual > } > ----8<---- > > Robert Gerber > 402-237-8692 > r...@craeon.net > > On Mon, Jan 6, 2025, 3:37 PM Christophe PEREZ via Bacula-users > <bacula-users@lists.sourceforge.net> wrote: > > Hi, > > > > With Bacula 15.0.2, is it possible in your opinion, to create a > > completely dummy job? > > What FileSet to put to have no backup? > > The goal is to send a command to the Storage daemon (so on a > > client) at > > the end of the backup. > > Thanks in advance! _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
