Re: [Bacula-users] Why would bacula consider duplicate jobs as fatal?
On Mon, Feb 17, 2020 at 5:03 AM Radosław Korzeniewski < rados...@korzeniewski.net> wrote: > Hello, > > śr., 12 lut 2020 o 00:10 David Brodbeck > napisał(a): > >> One example of a situation where this actually makes sense is if your >> full backups take a lot longer than your incrementals. For example, I have >> some workstations where a full takes three days, but an incremental takes >> only a few minutes. I'd rather have the incremental run every day (and >> occasionally get skipped when a full backup is running) than limit myself >> to only one backup every three days. >> > > In my very, very, very humble opinion it does not make sense and you > design you backup policy incorrectly. When your policy is to make backup > every day then you should not allow for full backup to take more time. In > such case I would recommend to implement VirtualFull which will solve all > your issues. > That is what I eventually did, although VirtualFull has its own issues and feels more fragile to me, e.g. if corruption slips into one incremental than it will propagate forward from that point without any fresh full backup to correct it. It's definitely a more efficient use of both storage space and time, though. -- 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
Re: [Bacula-users] Why would bacula consider duplicate jobs as fatal?
Hello, śr., 12 lut 2020 o 00:10 David Brodbeck napisał(a): > > > On Fri, Jan 31, 2020 at 1:54 AM Radosław Korzeniewski < > rados...@korzeniewski.net> wrote: > >> Hello, >> >> śr., 29 sty 2020 o 17:51 William Muriithi >> napisał(a): >> >>> >>> >> How would this make sense considering it was intentionally configured? >> >> >> I think I do miss your point. Why anyone on Earth would like to configure >> a backup job in such a way that the next job will intentionally run when a >> previous job did not complete and intentionally setup cancelation of the >> duplicated job? >> IMVHO if I knew that my backup job is running for i.e. 8H then I'll never >> schedule next backup job on 4H period and setup a cancellation of the >> duplicate job because it will cancel every second job by design. It would >> be insane, right? >> > > One example of a situation where this actually makes sense is if your full > backups take a lot longer than your incrementals. For example, I have some > workstations where a full takes three days, but an incremental takes only a > few minutes. I'd rather have the incremental run every day (and > occasionally get skipped when a full backup is running) than limit myself > to only one backup every three days. > In my very, very, very humble opinion it does not make sense and you design you backup policy incorrectly. When your policy is to make backup every day then you should not allow for full backup to take more time. In such case I would recommend to implement VirtualFull which will solve all your issues. best regards -- Radosław Korzeniewski rados...@korzeniewski.net ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Why would bacula consider duplicate jobs as fatal?
Hello, śr., 12 lut 2020 o 16:23 William Muriithi napisał(a): > > I think I do miss your point. Why anyone on Earth would like to > configure a backup job in such a way that the next job will intentionally > run when a previous job did not complete and intentionally setup > cancelation of the duplicated job? > > IMVHO if I knew that my backup job is running for i.e. 8H then I'll never > schedule next backup job on 4H period and setup a cancellation of the > duplicate job because it will cancel every second job by design. It would > be insane, right? > > That is how I initially set it up. The problem is, sometimes, the tapes > run out on weekend or at night and jobs fall behind. OK, I understand now. It is not an intentional configuration but a rare occurrences. So over time, you end up with 2 or 3 jobs scheduled to backup the same > file. Instead of restarting to cleanup the backlog, I thought rejecting > duplicates was less involving. > > How do you handle these cases without configuring bacula to avoid > duplicates? > I personally always configure Bacula to disable duplicates and to cancel it. But you can do whatever you want. You can just simply allow duplicates and just queue it so it will run as soon as all required resources become available again. Then no failed jobs because some of the jobs delay. best regards -- Radosław Korzeniewski rados...@korzeniewski.net ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Why would bacula consider duplicate jobs as fatal?
Morning Radosław, > I think I do miss your point. Why anyone on Earth would like to configure a > backup job in such a way that the next job will intentionally run when a > previous job did not complete and intentionally setup cancelation of the > duplicated job? > IMVHO if I knew that my backup job is running for i.e. 8H then I'll never > schedule next backup job on 4H period and setup a cancellation of the > duplicate job because it will cancel every second job by design. It would be > insane, right? That is how I initially set it up. The problem is, sometimes, the tapes run out on weekend or at night and jobs fall behind. So over time, you end up with 2 or 3 jobs scheduled to backup the same file. Instead of restarting to cleanup the backlog, I thought rejecting duplicates was less involving. How do you handle these cases without configuring bacula to avoid duplicates? > Well, this is a job message which inform you about the cause of the job > cancelation, as the job termination status is "cancelled" and not "fatal > error". What would you like to change in this message? Agree, cancelled is fine. I find fatal a bit excessive. That name, I would only use for things that require intervention, not something configured to happen intentionally. Its just a view point, and understand how hard to code against all edge cases. Thought the feedback is worth it though. Regards, William ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Why would bacula consider duplicate jobs as fatal?
On Fri, Jan 31, 2020 at 1:54 AM Radosław Korzeniewski < rados...@korzeniewski.net> wrote: > Hello, > > śr., 29 sty 2020 o 17:51 William Muriithi > napisał(a): > >> >> > How would this make sense considering it was intentionally configured? > > > I think I do miss your point. Why anyone on Earth would like to configure > a backup job in such a way that the next job will intentionally run when a > previous job did not complete and intentionally setup cancelation of the > duplicated job? > IMVHO if I knew that my backup job is running for i.e. 8H then I'll never > schedule next backup job on 4H period and setup a cancellation of the > duplicate job because it will cancel every second job by design. It would > be insane, right? > One example of a situation where this actually makes sense is if your full backups take a lot longer than your incrementals. For example, I have some workstations where a full takes three days, but an incremental takes only a few minutes. I'd rather have the incremental run every day (and occasionally get skipped when a full backup is running) than limit myself to only one backup every three days. -- 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
Re: [Bacula-users] Why would bacula consider duplicate jobs as fatal?
Hello, śr., 29 sty 2020 o 17:51 William Muriithi napisał(a): > Hello, > > Was trying to reduce the number of mails coming from Bacula, and was > combing through the logs to see what I can filter out. Currently, almost > all noise comes from bacula attempting to schedule a job and then realizing > the previous isn't yet done. I have configured bacula not to allow > duplicates to avoid jobs piling up in case I miss replacing tapes when all > are full. > > Anyway as I was doing so, I noticed that, sometime, bacula do consider > duplicate fatal? Yes, this is correct. > How would this make sense considering it was intentionally configured? I think I do miss your point. Why anyone on Earth would like to configure a backup job in such a way that the next job will intentionally run when a previous job did not complete and intentionally setup cancelation of the duplicated job? IMVHO if I knew that my backup job is running for i.e. 8H then I'll never schedule next backup job on 4H period and setup a cancellation of the duplicate job because it will cancel every second job by design. It would be insane, right? > Kind of confused by these instances. > > 22-Jan 17:50 bacula-dir JobId 25338: Fatal error: JobId 25266 already > running. Duplicate job not allowed. > > Well, this is a job message which inform you about the cause of the job cancelation, as the job termination status is "cancelled" and not "fatal error". What would you like to change in this message? best regards -- Radosław Korzeniewski rados...@korzeniewski.net ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Why would bacula consider duplicate jobs as fatal?
> On Wed, 29 Jan 2020 16:16:31 +, William Muriithi said: > > Hello, > > Was trying to reduce the number of mails coming from Bacula, and was combing > through the logs to see what I can filter out. Currently, almost all noise > comes from bacula attempting to schedule a job and then realizing the > previous isn't yet done. I have configured bacula not to allow duplicates > to avoid jobs piling up in case I miss replacing tapes when all are full. > > Anyway as I was doing so, I noticed that, sometime, bacula do consider > duplicate fatal? How would this make sense considering it was intentionally > configured? Kind of confused by these instances. > > 22-Jan 17:50 bacula-dir JobId 25338: Fatal error: JobId 25266 already > running. Duplicate job not allowed. It was a fatal in the sense that the job did not run. However, check the "Termination" line of the output -- it should be should be "Backup Canceled" even though it says "Fatal error" in the message. __Martin ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Why would bacula consider duplicate jobs as fatal?
Hello William, On Wed, 29 Jan 2020 at 17:55, William Muriithi wrote: > Hello, > > Was trying to reduce the number of mails coming from Bacula, and was > combing through the logs to see what I can filter out. Currently, almost > all noise comes from bacula attempting to schedule a job and then realizing > the previous isn't yet done. I have configured bacula not to allow > duplicates to avoid jobs piling up in case I miss replacing tapes when all > are full. You can easily change the Message resource to not notify about all events, the documentation does provide good examples for this. > > > Anyway as I was doing so, I noticed that, sometime, bacula do consider > duplicate fatal? How would this make sense considering it was > intentionally configured? Kind of confused by these instances. You need to use the “Allow duplicate job” option in your job(s) configuration. > > > 22-Jan 17:50 bacula-dir JobId 25338: Fatal error: JobId 25266 already > running. Duplicate job not allowed. > > Regards, > William > If you still need help, you can share excerpt of your configuration in this thread so we can see what could be missing. Hope it helps Best, Davide > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
