Bacula-users

Re: [Bacula-users] [Bacula-devel] Minor SD Feature Request

2008-05-10 13:23:27
Subject: Re: [Bacula-users] [Bacula-devel] Minor SD Feature Request
From: Blake Dunlap <blake AT ISDN DOT NET>
To: 'Kern Sibbald' <kern AT sibbald DOT com>, "bacula-devel AT lists.sourceforge DOT net" <bacula-devel AT lists.sourceforge DOT net>
Date: Sat, 10 May 2008 12:22:47 -0500
> Hello Blake,
>
> One part of Bacula that I would like to improve just a bit (not too much
> coding for the moment) for the next release is the information returned
> for
> Autochangers.  Currently, it seems to me that the sysadmin has very little
> information about the actual state of the autochanger via the console
> interface.  Although your suggestion seems to be a bit more than simple
> reporting of the status, I am interested in it.  The problem is that I
> don't
> understand what you are asking for well enough to possibly implement
> something.
>
> Could you be much more explicit with what you want, perhaps giving an
> explicit
> example of what happens now and what you would like to see happen.  Don't
> forget that at the current time, Bacula has no concept of changing the
> slot -- for example, when a Volume is loaded by Bacula from Slot 2 into
> the
> drive, it *must* be returned to the same Slot.  Changing this behavior is
> a
> project that would require significant design and thought and is probably
> not
> something we would want to implement in the near future.
>
> On the other hand, I think there is a lot of need and possibility for
> making
> Bacula much smarter at automatically recognizing that a Volume is in a
> different Slot from what is written in the database.  Currently such
> volumes
> are marked in error (if I remember right), but we could consider simply
> correcting the info in the database.
>
> Best regards,
>
> Kern

It is the last paragraph that I am mostly looking at dealing with. Let me give 
our situation in depth and I think that will explain what I am looking for.

We have a 2 drive auto-changer and run 4 pools of backups (Incremental, 
OnSiteFull, OffsiteFull, and OnsiteMonthly). We run two sets of backups for 
clients, an offsite backup that runs every Friday night (due to the lack of 
copy pools etc), and the OnSite backups which occur every night incremental, 
except Saturday night which is a full (the pool is overridden to Monthly the 
first sat of a month). Anyway we rotate the Offsite tapes every Tuesday, and 
supposedly there is an update slots run with all drives released at the 
conclusion of the procedure which should update the database as to the current 
state of the auto-changer.

Now that the back story is established, what has been extremely frustrating is 
that a decent percentage of the time, something occurs which places the tapes 
out of sync, and come Saturday night (the first night a drive would have to 
swap) the auto-changer fails to load a new tape it is looking for in the 
OnsiteFull pool, due to the tape that was in the drive failing to unload due to 
a slot full condition. Bacula now requests user intervention loading the tape, 
and the drive is marked unloaded (because the error didn't occur during an 
unload event, but a load event, which makes it a pain to determine what tape is 
actually loaded in the drive currently). To fix this, one must run an update 
slots, then look back in the logs to figure out what tape failed to unload, 
then "load" that tape into the drive, and Bacula will then realize the drive is 
usable again, and then proceed as normal. Of course due to the times we run 
backups, this has to occur in the middle of the night, or pot
 entially the next day which impacts backups, and the general network.

I believe this is an error condition that could reasonably be dealt with 
programmatically instead of requiring user intervention (An automatic slot 
refresh before unloading tapes / loading tapes (with an assumed lifetime 
validity of say 10 minutes to reduce occurrences) would be one solution).

Let me know if I need to add anything further, as I tried to be as detailed as 
possible in this response, as compared to the quick summary of the actual 
feature request. From a user prospective, I do agree that auto-changer support 
feels more tacked on than anything (for example, the requiring to specify a 
drive instead of an auto-changer when doing an update slots command) and would 
love to see improvements in that regard.

-Blake

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users