I'm not sure how Max Full Interval solves the problem. I have used it (before we switched to virtual full) but it doesn't really pertain to resource contention. Maybe I didn't explain the problem very well.
At any rate, I understand the fundamental problem here is I'm trying to use software originally written to back up always-online servers to back up workstations. It's a minor issue, so I'm not too concerned about it. On Wed, Sep 25, 2019 at 8:32 AM Kern Sibbald <k...@sibbald.com> wrote: > Hello, > > Bacula was not designed to handle the case you are describing where you > have multiple clients that are offline. This was not really a design > decision, but rather a design limitation because when the code was > implemented there was no restart functionality. > > A possible way to fix the problem would be to use Max Full Interval and > Max Diff Interval ... > > Best regards, > Kern > > On 9/21/19 12:19 AM, David Brodbeck wrote: > > > > On Thu, Sep 19, 2019 at 6:33 AM Kern Sibbald <k...@sibbald.com> wrote: > >> Hello, >> >> I concur with David. When these jobs are scheduled, Bacula will attempt >> to acauire the needed Storage resources. When the resources are busy the >> job waits, and after a certain time, Bacula will inform you that the >> resources are not available. >> >> These messages generally occur when you over commit the SD resources. If >> you are using disk, increasing the maximum simultaneous jobs in the Device >> resource and restarting the SD will generally solve the problem, but you >> might also have to assign more Storage devices depending on what you are >> doing. >> > > I think this is a somewhat unfortunate design decision, to be honest. I > back up a fairly large number of workstations, and on any given night a > certain number of them will be off or otherwise unavailable. I have these > jobs set to reschedule on failure so that they run when the workstation > eventually gets switched on. > > The problem is, with the behavior you mention, I can't accurately control > how many simultaneous *running* jobs are using storage. If I set the max to > the number of jobs that I actually want to be able to use storage > simultaneously, I end up with some jobs that could otherwise run waiting > for resources because those resources are committed to a job that's > retrying a workstation that may or may not appear. If I compensate by > setting the max higher, I risk overcommitting my storage bandwidth on > nights when all the workstations *are* available. > > -- > David Brodbeck > System Administrator, Department of Mathematics > University of California, Santa Barbara > > > -- David Brodbeck System Administrator, Department of Mathematics University of California, Santa Barbara
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users