On 10/8/07, Ralf Gross <[EMAIL PROTECTED]> wrote: > 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. > I remember seeing this on the list a few months ago but I am not sure what the outcome was.
John ------------------------------------------------------------------------- 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
