Re: [Bacula-users] Question about Bacula tape handling.

[Erik P. O. <er...@ep...>]

On Thu, 2005-10-13 at 11:28 +0200, Erik P. Olsen wrote:
> On Tue, 2005-10-11 at 09:56 +0200, Kern Sibbald wrote:
> > On Tuesday 11 October 2005 09:06, Erik P. Olsen wrote:
> > > How does Bacula handle "foreign" tapes? I am currently using Amanda for
> > > back-up but planning to switch to Bacula and sometimes I erroneously
> > > leave an Amanda labeled tape in the tape drive. I see the error when
> > > Bacula complains about the tape and pull it out, but later when Amanda
> > > recycles the tape it cannot read it and reports i/o error.
> > > dd if=/dev/nst0 cannot read it either and the only way to recover the
> > > tape is to erase it and relabel.
> > >
> > > Shouldn't Bacula leave the tape untouched when it sees that it does not
> > > carry the correct Bacula label?
> > 
> > Unless you have setup for Bacula to automatically label tape (or explicitly do 
> > a label command), Bacula will not write to a non-Bacula tape.
> No, I don't have automatic labeling specified and haven't issued any
> label command.
> > 
> > However, depending on what version of Bacula you are running, it will 
> > automatically modify your tape drive parameters (variable blocksize, ...) to 
> > be compatible with how Bacula uses tapes.  If you subsequently try to use the 
> > drive and the program is expecting a different mode (fixed blocksize, ...) it 
> > will fail.
> 
> This sounds possible, but a closer investigation proves that it cannot
> be the case. I have stopped the bacula tests for a couple of days and
> today a tape showed the same i/o error symptom and only amanda has used
> the tape drive the last three times it was used, so drive settings
> should be OK.
> 
> I get the following using dd on the tape:
> 
> [erik@epo ~]$ dd if=/dev/nst0
> dd: reading `/dev/nst0': Input/output error
> 0+0 records in
> 0+0 records out
> 
> My conclusion is that since I only use bacula and amanda with the tape
> drive then bacula has indeed caused the failure (it can hardly be dd or
> mt). My experience with tapes comes from mainframes and there this type
> of error would occur with a variable blocked tape where the block size
> or record size was wrongly recorded on the tape. Could that be the case
> here?

Replying to myself! I have now seen that this conclusion is wrong. I
haven't been testing Bacula for quite some time and yet the tape error
has again shown its ugly face. Perhaps it's a hardware problem? Anyway,
I apologise for having accused Bacula for this problem and I shan't
bother this mailing list with this tape problem anymore.

-- 
Regards,
Erik P. Olsen