On Monday 19 March 2007 04:15, Troy Daniels wrote: > Hi again, > > Just a quick note to say I've reported the bug as requested. > > I haven't forgotten the documentation updates, but am under time constraints > with a couple of other projects at work currently so haven't had time to work > on them yet.
No problem. > > I've also been giving some thought to my planned feature request for the > ability to specify a job to be verified. I probably should point out that when > I said: > > > "Verify last nights/weeks/months/whatever 'BackupCatalog' job" > > I definitely wasn't considering it as the syntax for the feature. It was more > intended to be getting the idea across. OK > > I can think of 2 ways to go with this that might work: > > 1) Implement an option to the 'run' command to specify the verify job by job > id. Using some scripting magic it should be easy enough to grab the specific > job id you want to verify and trigger a job to perform this verification > whenever you want to. I believe that this is already implemented via the run command then using "mod". However, since no one seems to have used setting the JobId, it has been rather neglected. I'd suggest that you try what exists, and if it is broken, the best is probably to submit a bug report. > > 2) Add the ability to specify a job by offset or scheduled start time. ie > Verify the 2nd last BaculaCatalog job or the BaculaCatalog job that was > scheduled to start on Friday. The offset would enable automatic scheduling of > jobs, and could be potentially more useful than the specific date. (which would > still need to be controlled thru scripting) This is an idea that I think given a bit of careful thought and good specification could be very useful. This idea would need to be submitted as a feature request. > > Option 1 is probably the simplest, and hopefully easiest, to implement. > > Thoughts? Suggestions?? > > Cheers, > > > Troy. > > Kern Sibbald wrote: > > Hello, > > > > Thanks for your analysis and discussion of the problem. Please see my > > comments below. > > > > On Wednesday 14 March 2007 03:36, Troy Daniels wrote: > >>>> When a verify job is scheduled under 2.0.2 to perform a Volume to > >>>> Catalog verify it now selects the job to be verified (and the associated > >>>> tape(s)) at the scheduled start time. It then waits until all jobs of > >>>> lower priority finish before performing the actual verify. This results > >>>> in it verifying the previous nights backup instead of the current nights > >>>> one. > >>>> > >>>> Under 1.38.5 the job wouldn't select the job to verify until it actually > >>>> ran (Actual start time instead of scheduled start time). In my case this > >>>> is after the job I actually want to verify has finished running for the > >>>> evening. > >>> OK, thanks. This time, the problem is crystal clear. The above describes > >>> what I need to know/understand. > >>> > >>> I haven't looked at the code, but I suspect that some of the startup code > >>> was moved earlier in the process. In general this was done so that the > >>> catalog entries are more complete if the job is subsequently cancelled > >>> before it is actually started. > >>> > >>> In this case, if this is what happened, I can see that this will create a > >>> problem for you. However, it does seem to make sense that the Verify job > >>> would select the job to be verified when Verify is scheduled rather than > >>> at some later time when additional jobs may have run. > >>> > >>> I'm not sure what the solution is. It seems there are two ways to resolve > >>> it: 1. Start the Verify immediately after the backup (probably with a > >>> RunScript. 2. Put the code back the way it was in 1.38.11 (assuming that > >>> is the problem). > >>> > >>> Do you or anyone else on this list have any comments on the above two > >>> possible solutions? > >> Well I've already updated my config to implement option 1 as a > >> 'workaround', and am happy to trigger my verifies that way. I've scheduled > >> a 'TriggerVerify' admin job that will run after the backup is complete and > >> launch the verify. I used this as I believe using a RunScript within the > >> backup job wouldn't work as the backup job will still be 'running' when the > >> verify job is scheduled, so it'll still automatically select the previous > >> nights job. > > > > You mention below that you are considering looking over the documentation. > > The above, IMO, regardless of how the code evolves, would be a very valuable > > contribution to the documentation, because as you indicate, it gives > > additional flexibility. > > > >> Also, I personally feel the current implementation isn't as intuitive as > >> how it worked in 1.38.11 - however this can probably be dealt with by > >> appropriate documentation within the manual. > > > > Yes, I agree with you about the current implementation not being very > > intuitive. I think the "correct" solution is to put the code back as it was > > in 1.38.11, and document the potential problems with that (not the problems > > with the current "broken" code) as well as document the Admin workaround job. > > > > I also think that for a longer term, "cleaner" solution it might be a good > > idea to add a RunAfterJob, which runs one or more jobs after the current job, > > and by "runs", I mean it starts the job within Bacula, not through a script > > as RunScript does. This, however, needs to be carefully examined -- Eric > > what do you think? > > > >> It comes down to the > >> difference in scheduled time and start time under Bacula. Especially when > >> you throw priorities into the mix. You might schedule a job to start at > >> 23:15, but you can stop it running until after the backup job finishes > >> using priorities. Seems to me that if you've setup your job to me, you are > >> most likely going to want to verify the job that just ran. > >> > >> What I would *really* like to see is the ability to set which job gets > >> verified by jobid - Currently I can say "Verify job 'BackupCatalog' but I > >> cant say "Verify last nights/weeks/months/whatever 'BackupCatalog' job" > > > > As a longer term project, I might consider this, but if you do submit a > > Feature Request, you will need to be *very* explicit about the syntax -- for > > example "verify last nights BackupCatalog job" seems to me rather difficult > > to parse and probably syntactically very precise (a good flow state chart > > would help). There are also problems with what happens if the job runs into > > the morning ... > > > >> This would aid in resource scheduling IMO - in my case my full backups take > >> up most of Saturday, and there is barely enough time to perform the > >> verifies before Saturday nights incremental backups start - it would be > >> nice to be able to schedule the verify jobs for Sunday when the tape drive > >> is otherwise idle. > > > > Again, the problem here is how to simply and precisely specify such actions. > > > >> A nice side effect of the changed behaviour is that I can now achieve this. > >> > >> This probably needs to be a feature request doesn't it - or is there one in > >> already that covers it? > > > > I don't recall any existing feature request in this area -- all the ones I > > have received to data (with the possible exception of the NDMP request) are > > in the current 2.0.3 projects file. > > > >> Just had another thought - is this change limited to VolumeToCatalog > >> verifies, or was it applied across the board to all verify job types? Seems > >> to me, that it would be a lot easier to overlook the fact that your verify > >> job is actually verifying the previous nights backup if tapes aren't > >> involved. > > > > Good question. I'll look at this when I am looking at the problem. > > > >> If I get time today I'll look into the documentation and see if I can come > >> up with a suitable addition explaining this situation. I might even throw > >> in a feature request if one doesn't already exist. > > > > Yes, thanks, as noted above, suggestions for the documentation would be > > welcome. > > > > In order to be sure this bug is properly fixed (one way or another), would you > > please submit a bug report with the first two paragraphs listed above in your > > previous email. > > > > Thanks, > > > > Kern > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
