Hello, On 4/11/2007 8:56 AM, Ralf Gross wrote: ... >> The one thing I would do in your situation is - observe things. If this >> repeats, I would try to get catalog data whenever a job starts, perhaps >> even a dump of the Media table or something... just so you have some >> data to look at. After the error has occured, it's likely Bacula >> modified the catalog entries. > > Well, I've a backup of the bacula database from last weeks full backup > (2007-04-01). > > This shows the same value for voluseduration, 345600 (4 days). > > COPY media (mediaid, volumename, slot, poolid, mediatype, mediatypeid, > labeltype, firstwritten, lastwritten, labeldate, voljobs, volfiles, > volblocks, volmounts, volbytes, volparts, volerrors, volwrites, > volcapacitybytes, volstatus, enabled, recycle, volretention, > voluseduration, maxvoljobs, maxvolfiles, maxvolbytes, inchanger, > storageid, deviceid, mediaaddressing, volreadtime, volwritetime, > endfile, endblock, locationid, recyclecount, initialwrite, > scratchpoolid, recyclepoolid, "comment") FROM stdin; > > 5 06D124L3 5 5 LTO3 0 0 > 2007-02-24 23:45:04 2007-02-25 11:04:06 2007-02-24 23:45:04 > 3 16 230427 1 14865371136 0 0 230428 > 0 Recycle 1 1 2678400 345600 0 0 0 > 1 2 0 0 > 0 0 15 2014 0 0 \N 0 0 > \N > > > Because recycling and marking of the volume happend after the job > started (at the same minute 00:10), I've no idea if it would make > sense to dump the db in a run before skript before every backup.
I admit my suggestion is unlikely to reveal anything useful because the most crucial information here are the retention times and voluseduration etc., and these don't change with volume access. But you'll need some hard data... ... (time settings look correct) > At them moment I would consider this as a bug, but I would like to > here Kern's opinion on this before I open a bug report. ... to confirm that assumption and give Kern something to work on. By the way, I forgot to mention something more or less obvious: Run the DIR with debug output enabled at a fairly high level. Perhaps that gives us a clue why the volume is marked used too soon. Finally, I don't recall if you run multple concurrent jobs to differend drives. If that's the case, it might be that the volume in question was marked used because another job accessed it. I understand that there are cases where job timing is critical, and the current reservation scheme isn't waterproof against two jobs accessing a single volume simultaneously. Arno > > Ralf > > ------------------------------------------------------------------------- > 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 -- IT-Service Lehmann [EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de ------------------------------------------------------------------------- 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
