In the message dated: Wed, 13 Sep 2006 12:33:59 +0200,
The pithy ruminations from Kern Sibbald on
<Re: [Bacula-users] fatal error--Bacula wants tape to be in the "other" drive i
n autochanger> were:
=> On Wednesday 13 September 2006 11:30, Alan Brown wrote:
=> > On Tue, 12 Sep 2006, Kern Sibbald wrote:
=> >
=> > > On Tuesday 12 September 2006 18:21, [EMAIL PROTECTED] wrote:
=> > >> I'm running into a frequent situation where Bacula wants a given volume
=> to
=> > > be
=> > >> in one drive of our autochanger, and it doesn't seem to find the volume
=> when
=> > >> it's already in the other drive.
=> > >>
=> > >> This is with Bacula 1.38.9, under Linux (FC1), with a 23-slot, 2 drive
=> > >> autochanger and mysql5.
=> > >>
=> > >> Most backups work fine, but this is a persistent problem.
=> > >
=> > > Two drive autochangers did not work correctly until Bacula version
=> 1.38.11,
=> > > and there have been no such problems posted against 1.38.11.
=> >
=> >
=> > Kern: This is exactly the problem I posted last week and I am running
=> 1.38.11
=>
=> I don't think it is the same problem, but that is not important. What is
=> important is he is not using 1.38.11, and there are known problems with the
What's important to you--as the developer--may not be as important to me, as an
end-user (who's willing to help improve Bacula as much as possible). From my
perspective, I'm much less concerned about whether there are different issues in
1.38.9 and 1.38.11 than I am about whether the symptom (ie., backups failing) is
still present. It sounds like various users are reporting that the same
symptoms appear in 1.38.11 and 1.39.20, even if you see that they have
different causes.
=> management of Volume names on prior versions, so the problem is no longer
=> relevant to me -- I cannot support old versions other than the most recent
=> one.
I think I understand that...and I wasn't actually asking for "support" on an
older version. In fact, if upgrading to 1.38.11 actually fixes the problem,
than that's a terrific solution.
However, our one Bacula installation is also our production backup
system--which is
probably the case for many people. I'm quite reluctant to upgrade to another
version if it doesn't actually solve the problem...and there seems to be a bit
of dispute about whether 1.38.11 really does solve the problem...
So, getting back to my original question:
Is there a definitive solution (and "upgrade to version X.Y.Z" is a
fine answer)
to the problem where backups fail because Bacula wants to use a volume
in on tape drive when the volume is already loaded in another drive?
I'm happy to supply other information (debugging output, config files, etc.) as
needed.
=>
=> >
=> > I know why it's occuring - people are running update slots against a
=> > particular tape drive instead of the autochanger
=> >
=> > And I know why they do that - running update slots against the changer
=> > only ever unloads drive 0, no matter which drive is actually specified.
Right. There's no way (that I've found, with 1.38.9) to run "update slots"
without it explicitely referencing tape drive 0.
=> >
=> >
=> > I know you don't regard it as a bug that when run this way, all the tapes
=> > in the changer end up associated with an individual drive, but I do.
=>
=> I'm not planning to change the current behavior, but I can make sure that
the
=> document is explicit enough on this point.
=>
I'm a bit confused here... If volumes become associated with a particular drive
as the result of running "update slots", then it sounds like there's no way
around the fundamental problem, regardless of whether I upgrade to 1.38.11.
=> >
=> > Additionally it's definitely a bug that update slots ignores any drive
=> > specfication.
=> >
=> > IE:
=> >
=> > *update slots
[SNIP!]
=> > 3307 Issuing autochanger "unload slot 47, drive 0" command.
=> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^This is not drive 1
=>
=> I wasn't aware of this problem with the drive number, and I don't remember
=> anyone mentioning it before. Thanks for pointing it out. The big question
is
I'll take a closer look at the output from "update slots" in whatever version
I'm running, and report the results.
=> whether or not this problem exists in 1.39.22 or not, because it is unlikely
=> that I will be making any further patches for 1.38.11.
=>
For my clarification...do you consider the 1.39.x series to be production
quality?
Kern --
I do want to restate that I do appreciate the quality, features, and depth of
Bacula, and I'm particularly grateful for your timely responses. Perhaps it's
the fact that the package is so important, or that it's so close to
"commercial
quality" (whatever that is!) that causes people to have such high
expectations.
Thanks,
Mark
----
Mark Bergman [EMAIL PROTECTED]
System Administrator
Section of Biomedical Image Analysis 215-662-7310
Department of Radiology, University of Pennsylvania
http://pgpkeys.pca.dfn.de:11371/pks/lookup?search=mark.bergman%40.uphs.upenn.edu
The information contained in this e-mail message is intended only for the
personal and confidential use of the recipient(s) named above. If the reader of
this message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that you have
received this document in error and that any review, dissemination,
distribution, or copying of this message is strictly prohibited. If you have
received this communication in error, please notify us immediately by e-mail,
and delete the original message.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
