Hello, śr., 12 lut 2020 o 00:10 David Brodbeck <brodb...@math.ucsb.edu> 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 <will...@perasotech.com> >> 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
