This is kinda long winded folks, don't say I didn't warn you.

I believe I have solved the "asking for a volume that's NOT in the changer 
even when a  volume that ought to be usable is in the changer" problem.

I believe this addresses the issue many people have where they want to 
restrict bacula to using a tape that's in the changer in preference to other 
tapes which are not, even if bacula's recycling algorithm seems to prefer 
an "offline" volume.

It's a BASH script that has been written for my environment, but should be 
adaptable to any bacula implementation.  I'm using mysql, and running on 
Bacula v 2.0.3.  If you're using sqlite or postgresql, you'll have to change 
the "mysql" part of the script and may have to adapt the queries.  

I've set up the script to run as an admin job before any real backup jobs run 
each day.  

Here's the script:

#!/bin/bash
/usr/local/bin/bconsole <<EOF
unmount storage=MyAutochanger
update slots storage=MyAutochanger
mount storage=MyAutochanger
status dir
EOF

## Enable any UseVolumesInChanger volumes that are InChanger
for volname in `mysql bacula<<EOF
SELECT VolumeName AS ""
FROM Media,Pool
WHERE Inchanger=1
AND Media.PoolId=Pool.PoolID
AND Pool.Name='UseVolumesInChanger' ;
EOF
`; do bconsole <<EOF
update volume=$volname enabled=1
EOF
done

## Disable any UseVolumesInChanger volumes that are !InChanger
for volname in `mysql bacula<<EOF
        SELECT VolumeName AS ""
        FROM Media,Pool
        WHERE Inchanger=0
                and Media.PoolId=Pool.PoolID
                and Pool.Name='UseVolumesInChanger' ;
        EOF
`; do bconsole <<EOF
update volume=$volname enabled=0
EOF
done
### End of the script.

First I 'unmount' the autochanger, update the slots and remount the 
autochanger.  I do this because if I 'update slots' with a tape in the drive 
bacula "forgets" that the tape is in the drive and errors can result when it 
comes time for a job to run.[1] 'update slots' is so that if non-operators 
have changed tapes that bacula will know what's actually in the tape drive.  
The 'mount' command is used so bacula will be able to use the autochanger 
when jobs run.  Finally for this section, a 'status dir' is used to nudge 
bacula into pruning appropriate volumes.

The next section runs a mysql query to figure out which volumes meet the 
following criteria:

1.  They are in the correct pool:  "UseVolumesInChanger" in this example.
2.  They are in a changer.  NOTE:  This script doesn't care WHICH changer.  I 
know such a concern will certainly matter for certain implementations.  It 
doesn't for mine, as I only have one pool that needs this script and that 
pool only ever uses one autochanger.

Then I use the output from that query to update the "Enabled" flag to "1" 
(yes) for each volume with bconsole.

The final step, commented with"Disable any...", does sort of the opposite.  It 
queries the mysql database for any volumes in the UseVolumesInChanger that 
are NOT in the changer then uses bconsole to set the "Enabled" flag to "0" 
(no).

To test this, I have done the following:

1. Manually switch tapes in the autochanger.
2. Using bconsole, run the admin job which runs the script.
3. Using bconsole, 'status dir' to see if the scheduled job that uses the 
UseVolumesInChanger pool is asking for a tape that's in the changer or not.
4. Using bconsole, 'list volumes pool=UseVolumesInChanger' and check output to 
verify that any tapes not in the changer are "Enabled" = 0.
5.  Repeat steps 1-4 using different tapes to verify proper function.

Note that relatively short volume retention periods must be set or bacula 
won't be able to recycle tapes that are in the changer and your 'status dir' 
commands might get an "*unknown*" result for the volume requested for a 
scheduled job.  For my purposes, I've set volume retention for the 
UseVolumesInChanger pool to 12 hours, as the job runs every 24 hours and it's 
more important that a new backup is made every night than it is that last 
night's backup stays on the tape.

With this script managing the disabling of volumes to bacula, whatever tapes 
are in the changer for this backup job/pool will be preferred over other 
tapes, and I can still use the other slots in the autochanger for volumes 
from other pools and other jobs.

If anyone sees any problems with this setup, or perhaps ways it could be 
improved, I'd like to hear of them.  I hope to have the time this afternoon 
to write this up on the bacula WIKI.  I'm new to mysql, so if there's a more 
elegant way to do the query, I'm all ears, erm... eyes.  I think there may be 
some "smarter" way to get the right pool without the dual "WHERE 
Media.PoolId=Pool.PoolID and Pool.Name='UseVolumesInChanger'" bits.

Maybe I ought to get into python so I can write this script for bacula's 
internal python capabilities.

--Tim G.

[1] I think that when bacula has "forgotten" about such a tape, that 
the "mount" command would make bacula "remember" the tape that was in the 
drive.  I might test that someday, but I didn't want to when I thought of it 
as I wrote this message.  If it does, then the unmount command becomes 
superfluous and I can get away with just doing an update slots followed by 
mounting the device again.  *shrug*

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to