Re: [Bacula-users] Copy Job Configuration Question

[Bill Arlofski via Bacula-users]

On 4/6/24 10:53 AM, Chris Wilkinson wrote:

I am attempting to write a copy job to copy uncopied jobs from one SD to another. It seems that the client and fileset directives are required or the syntax check will fail. The documentation (v9) is not explicit on this point.

This is what I have for the copy job:

Job {
   Name = "catalog-copy"
   Description = "copy of catalog"
   Type = "Copy"
   Level = "Full"
   Messages = "Standard"
   Storage = "dns-325-sd" #source storage
   Pool = "catalog"
   NextPool = "catalog-copy"  #destination storage
   Client = "catalog-fd"  #why is this needed, what value?
   Fileset = "Catalog"  #why is this needed, what value?
   Schedule = "sched_none"
   SelectionPattern = "catalog"  #copy only job names matching "catalog"
   SelectionType = "PoolUncopiedJobs"
}

Many Thanks
Chris Wilkinson

Since the client is not involved in a copy job, it seems that these clauses are redundant. If they really are required,  does it matter what value they have,  even a non-existent one?

Hello Chris,

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.

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



Hope this helps!
Bill

--
Bill Arlofski
w...@protonmail.com

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.

signature.asc
Description: OpenPGP digital signature

_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users