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: > > [EMAIL PROTECTED] ~]$ 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 ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
