Here's the mt status after a run that used 2 tapes: SCSI 2 tape drive: File number=3, block number=0, partition=0. Tape block size 0 bytes. Density code 0x80 (DLT 15GB uncompressed). Soft error count since last status=0 General status bits on (81010000): EOF ONLINE IM_REP_EN
On this run, the first tape does not appear to contain the *reported* backup images. So in effect, none of my backups took place while amanda says otherwise. Sure, I can give 2.4.4b1 a try. I've tried every other release. :) Before I noticed the tapes acting funny. I know that that last dumper line in amreport did occur and was never a problem. robin On Wed, 19 Feb 2003, Joshua Baker-LePain wrote: > On Wed, 19 Feb 2003 at 2:17pm, [EMAIL PROTECTED] wrote > > > I've attached a run using the unix tools. There were messages in the log > > which I've also attached. > > > > Another symptom I've noticed is that when amanda uses multiple tapes. The > > first tape will not be accessible by the amanda tools but mt/dd can read > > the fileheaders and read the backups. But the tapes following the first > > are never readable by amanda nor mt/dd. > > This is from the amreport email you sent: > > taper: tape tape-08 kb 31302464 fm 63 writing file: No space left on device > taper: retrying host1:/disk1/bs/.donnotrm01.0 on new tape: [writing file: No > space left on device] > driver: dumper0 pid 10771 is messed up, ignoring it. > > That last line is, I believe, a bug that remained through 2.4.3 final. It > *could* lead to the second tape not being readable, but I'm not so sure > about that. > > Can you try 2.4.4b1? If it makes you feel better, I'm using it in > production on my larger config (1.5TB worth of (used) RAID space backed up > to a Overland AIT3 changer) with good results (including working > amrecover). > > Also, can you try writing multiple tarfiles to a tape, ejecting the tape, > then reading back some of them? The errors in the system logs are > indicating some sort of issue with reading. > >
