John Drescher schrieb: > > sometimes I just can't follow the decision bacula takes about which volume > > to > > recycle (bacula 2.0.3 - update to 2.2.4 scheduled, debian etch, postgres > > 8.1). > > http://www.bacula.org/rel-manual/Automatic_Volume_Recycling.html#SECTION002530000000000000000 > > > > [...] > > # Try recycling any purged Volumes. > > # Prune volumes applying Volume retention period (Volumes with VolStatus > > Full, > > Used, or Append are pruned). Note, even if all the File and Job records are > > pruned from a Volume, the Volume will not be marked Purged until the Volume > > retention period expires. > > # Search the Pool for a Volume with VolStatus=Purged > > # If a Pool named "Scratch" exists, search for a Volume and if found move > > it to > > the current Pool for the Job and use it. Note, when the Scratch Volume is > > moved > > into the current Pool, the basic Pool defaults are applied as if it is a > > newly > > labeled Volume (equivalent to an update volume from pool command). > > [...] > > > > And this is what happened, btw: not for the first time: > > > > 07-Okt 11:03 VU0EM005-sd: End of medium on Volume "06D131L3" > > Bytes=687,798,171,648 Blocks=10,661,553 at 07-Okt-2007 11:03. > > 07-Okt 11:03 VU0EM005-dir: Pruned 1 Job on Volume "06D132L3" from catalog. > > 07-Okt 11:03 VU0EM005-dir: ua_purge.c:611 All records pruned from Volume > > "06D132L3"; marking it "Purged" > > 07-Okt 11:03 VU0EM005-dir: Recycled volume "06D136L3" > > 07-Okt 11:03 VU0EM005-dir: Using Volume "06D136L3" from 'Scratch' pool. > > > > > > Why did bacula choose the volume from the scratch pool and not volume > > 06D132L3 > > which is in the Full-Pool and just was purged? Why didn't bacula recyle vol > > 06D132L3 right after purging it? > > > Do you have a multi drive changer? Was 06D132L3 a second drive?
No, this is a single drive changer. > Does query "List Volumes Bacula thinks are in changer" show this tape? The state of inchanger for volume 06D132L3 is 0!? It seems that the state changed between 2007-10-03 and 2007-10-04, I dump the 'list volumes' output to a file each day. 03-Okt-2007 20:05:02 llist volumes mediaid: 13 volumename: 06D132L3 [...] inchanger: 1 04-Okt-2007 20:05:02 llist volumes mediaid: 13 volumename: 06D132L3 [...] inchanger: 0 mtx correctly reports that the tape is in slot 13. At the moment I have no idea why the inchanger flag for this volume was set to 0. In the mtx.log I can see that an 'update slots' command was issued. But the output looks ok to me: 20071004-14:50:53 Parms: /dev/NEC-T40A load 13 /dev/ULTRIUM-TD3 0 20071004-14:50:53 Doing mtx -f /dev/NEC-T40A load 13 0 20071004-14:51:34 Parms: /dev/NEC-T40A loaded 13 /dev/ULTRIUM-TD3 0 20071004-14:51:34 Doing mtx -f /dev/NEC-T40A 0 -- to find what is loaded 20071004-14:51:34 Parms: /dev/NEC-T40A unload 13 /dev/ULTRIUM-TD3 0 20071004-14:51:34 Doing mtx -f /dev/NEC-T40A unload 13 0 I've updated the slots again and now the inchanger flag is 1. That was the reason why the volume wasn't used, now I only need to know why the inchanger flag was wrongly set to 0. Ralf ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
