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

I had no other issues with that, but I'll try to flatten the hierarchy to one 
JobDefs level.

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

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 
partial parallelism.

Thanks for your help!



You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
For more options, visit

Reply via email to