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! Cheers, Martin -- 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 bareos-users+unsubscr...@googlegroups.com. To post to this group, send email to bareos-users@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
