Arno Lehmann schrieb: > > 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... I just can't figure out what config option would cause a volume to be recycled and set to used at the same minute if the volduration time is set to 4 days (but this wouldn't be the first case of PEBKAC...).
> ... (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. I'm a bit afraid of the amount of debug data that bacula will produce until this problem occurs next time. > 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. No concurrent jobs, no differend drives. Just 2 jobs that have the same start time, but different priorities. Anyway, thanks for your suggestions fo far! 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
