On Monday 12 March 2007 04:05, Troy Daniels wrote: > Greetings Listers, > > Last week I upgraded my Bacula install to 2.0.2 without any issues during > the upgrade process. > > All seemed to be working well until Friday, but that was only because I > hadn't discovered this issue yet. > > I run several jobs each night, with Full backups on Friday night and > incrementals every other night. Once the backups are completed I have > bacula setup to verify a few of these tape jobs against the catalog with > Volume to Catalog jobs. > > These verify jobs have a higher priority, so they shouldn't start until > after the backup jobs are complete. I also schedule them to start 10 > minutes after the backups at 23:15. (All backups are scheduled to start at > 23:05) > > This behaviour seems to have changed in Bacula 2.0.2 however. They seem to > launch immediately and select which tape they'll use for the verify. > > Here's a log excerpt from a job running under 1.38.5 (My old version) > > > 02-Mar 01:09 backup1-dir: Verifying against JobId=6017 > > Job=fs1.2007-03-01_23.00.00 02-Mar 01:09 backup1-dir: Bootstrap records > > written to > > /export/bacula/var/backup1-dir.restore.Verify-fs1.2007-03-01_23.15.00.bsr > > 02-Mar 01:09 backup1-dir: > > 02-Mar 01:09 backup1-dir: The job will require the following Volumes: > > 02-Mar 01:09 backup1-dir: > > 02-Mar 01:09 backup1-dir: 000009 > > 02-Mar 01:09 backup1-dir: > > Even tho it was scheduled to run at 23:15, it didn't start until 1:09 the > next morning. This is the expected behaviour. > > Here's a log excerpt from Friday night under 2.0.2: > > 09-Mar 23:15 backup1-dir: Verifying against JobId=6101 > > Job=fs1.2007-03-08_23.00.00 09-Mar 23:15 backup1-dir: Bootstrap records > > written to /export/bacula/var/backup1-dir.restore.11.bsr 09-Mar 23:15 > > backup1-dir: > > 09-Mar 23:15 backup1-dir: The job will require the following > > Volume(s) Storage(s) SD Device(s) > > ========================================================================= > >== 09-Mar 23:15 backup1-dir: > > 09-Mar 23:15 backup1-dir: 000010 Tape > > OfficeAutochanger 09-Mar 23:15 backup1-dir: > > 10-Mar 20:57 backup1-dir: Start Verify JobId=6125 Level=VolumeToCatalog > > Job=Verify-fs1.2007-03-09_23.15.00 > > As can be seen, the job started at 23:15, selected tape '000010' and then > waited until the next night to run (Full backups take most of a day :) ) > Meanwhile, the full backup ran, writing to 2 other tapes. > > The problem encountered by bacula is that tape 000010 had been removed from > the Autochanger on Friday morning and replaced with this weeks incremental > tape. So Bacula blocked, waiting for a tape, until I discovered and > cancelled this job this morning. Not ideal, but it did bring this issue to > light. > > What I'd like to know is if this was a deliberately designed feature, or if > it classifies as a bug? If it's deliberate, is there anyway to control when > it performs it's tape selection, or even which job it verify? I've scanned > the Jobs section of the latest manual but didn't see anything obvious. > > For now I can either work around it(With a Run script running the verify > job), or even work with it (I've wanted to run the Full Backup job verifies > on Sunday for a while anyways.) >
To the best of my knowledge there is no deliberate change in the way Verify jobs are run. You haven't supplied sufficient information, so I am not able to understand the problem. Regards, 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
