Hi, We have seen the same behaviour as described below. When a Verify job is scheduled to run before the last Backup job is finished, it will not verify the backup that was running but the previous job that already was finished at schedule time. So you have to make sure that a backup job is finished before you can start a verify job of that backup Job in the new version (2.0.x). The difference with 1.38.x is that with that version the verify job picked the Backup job when it was starting the verify Job, and with the 2.0.x version it is picking the Backup job at Schedule time. You can verify this behaviour when you start a backup and verify job (with different priority) at the same time. The verify job will not verify the backup job that was started at the same time, but the one that finished before the verify started. At the moment we don't schedule a verify job but we schedule an Admin Job with a Runafter shellscript that will start the verify job, so that the verify job will absolutely sure start after the backup job is finished. We are running version 2.0.2 at the moment, so maybe the behaviour is changed in the 2.0.3 version, I didn't check, but as mentioned above we found a way to do a verify of the correct backup tape.
K.Regards, Michel van Schaik Kern Sibbald wrote: > 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 > ------------------------------------------------------------------------- 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
