Am Dienstag, 6. März 2018 01:23:45 UTC+1 schrieb Stefan Klatt:
> I have a few comments.
> - Do you have really monolithic config files? They are bad to read
> and old school :-).
In reality the config files are split via the @ operator (one file for pools,
one for storage, one for job templates and schedules, and one for each of ca.
100 clients in a subdirectory)... I just reduced it for better readability and
kept only one job for each pool.
> - I didn't know that the construct JobDefs -> JobDefs -> Job
I had no other issues with that, but I'll try to flatten the hierarchy to one
> - For me your configuration is more complex than needed. E.g.
> Storage definitions at Pools, Jobs and JobDefs is too much.
There is no Storage definition in the Jobs. But Indeed I could remove the
Storage= statement from the JobDefs without error (IIRC I got an error message
for that some time and some versions ago).
> Probably this complex configuration is the reason for your
Yes, but I see no way to reduce complexity... Sadly Bareos still thinks in
"Tapes", frankly the limit of one concurrent Job per "Device" is hard to work
around... So I have to split Full, Diff and Incr for different retention
periods, and also split in different Pool sets in an attempt to get at lease
Thanks for your help!
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
For more options, visit https://groups.google.com/d/optout.