On Mon, 21 Dec 2009, Kern Sibbald wrote: > I am not convinced that any small tweak such as you are suggesting will > resolve your problems, which is why we implemented a new set of directives.
I know the reasoning behind the new set of directives and we're using them, however the tweak will go a long way towards resolving issues. > If these are not adequate, I would like to know why. I'm a big fan of dealing with all possible failure modes (belt & braces approaches). The reality is that when job concurrency is set to 1 (the default), having a Job only check for escalation as it actually starts up will avoid issues such as I have described. Part of the philosophy here includes running an incremental backup immediately before commencing full or differentials, so that in the event of failure I'm still able to restore to "today's version" of the backup rather than yesterday's. Because of that I don't like to use the duplicate job weeder - in the event that the incremental's start is delayed beyond the nominal start time of the Diff or Full backup, the incremental gets cancelled. For sites with small (or small numbers of) backups the philosophy may be different, but I've had situations where a paniced user has come to me needing a file restored while a full backup is running and which would have been missed had the incremental not been run. I hope that makes some sense. Alan ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
