Re: Odd error from amcheck

Jon LaBadie <[email protected]> Wed, 17 Apr 2019 18:40:21 -0400
Newsgroups gmane.comp.archivers.amanda.devel
Message-ID <[email protected]>
On Wed, Apr 17, 2019 at 06:24:42PM +0000, Debra S Baddorf wrote:
> 
> 
> > On Apr 17, 2019, at 12:15 PM, Jason L Tibbitts III <[email protected]> wrote:
> > 
> > I had a bit of downtime with my backup server (not related to Amanda)
> > and after getting things running again I've seen a couple of odd
> > problems related to labels.
> > 
> > Today I got the following from amcheck:
> > 
> > NOTE: Holding disk '/local/amanda/work': 7461020 MB disk space available, using 7460920 MB
> > slot 19:amcheck-device: TypeError in method 'storage_getconf', argument 1 of type 'storage_t *' at /usr/lib64/amanda/amcheck-device line 165.
> > 
> > That corresponds to this block of code:
> > 
> >                } elsif ($dev->status & $DEVICE_STATUS_VOLUME_UNLABELED and
> >                         $dev->volume_header and
> >                         $dev->volume_header->{'type'} == $Amanda::Header::F_WEIRD) {
> >                    my $autolabel = storage_getconf($storage, $STORAGE_AUTOLABEL);
> >                    if ($autolabel->{'non_amanda'}) {
> >                        print STDERR " contains a non-Amanda volume\n";
> >                    } else {
> >                        print STDERR " contains a non-Amanda volume; check and relabel it with 'amlabel -f'\n";
> >                    }
> > 
> > which would seem to suggest that it's finding the tape to be unlabeled.
> > And last night in order to get things to run, I had to relabel a tape.
> > But these tapes have all been previously labeled, and in fact I've been
> > using them for a while.  I have no idea what could cause them to become
> > unlabeled, besides the obvious cause of something writing to them.  But
> > the tape in slot 19 was just loaded and hasn't been in the drive in some
> > time.
> > 
> > If I run amtape inventory, it tells me
> > 
> > [...]
> > slot 18: label C00018 barcode C00018L6 [retention-tapes]
> > slot 19: blank barcode C00019L6
> > slot 20: label C00020 barcode C00020L6 [retention-tapes]
> > [...]
> > 
> > but... it was fine and had a label last night.  And I have a feeling
> > that tape C00020 will end up being unlabeled tomorrow.
> > 
> > Has anyone seen anything like this?  What's the magic incarnation to
> > read the amanda label from a tape without running amanda tools?  (I know
> > dd should do it but I can't seem to find the right combination of
> > options.)
> > 
> > - J<
> 
> 
> mt -f /dev/nst0   rewind
> dd if=/dev/nst0   of=MyFile   bs=512k   
> mt -f /dev/nst0   rewind     !! so ready for amanda to use it
> 
> for   /dev/nst0   substitute the location of your drive   (grep amanda.conf  to find it)
> 
> for bs=512k   you may have to guess higher or lower (if an older, smaller tape).
> This is usually the hardest part to guess at.
> 
> 
> Then do     more MyFile
> read the first block   and ^Q   out of the rest.   
> 
> Mine shows    
> AMANDA: TAPESTART DATE 20190204200001 TAPE ad5-daily-123
> ^L
> 

Isn't the amanda tape header data still 32KB?  I thought you
could skip syncronizing dd block size and actual tape bs.

For example:

  # dd if=/dev/???? of=MyFile bs=32k count=1

Skip the "of=MyFile" to write to stdout/screen.

I think you would have to synchronize the bs of dd and the
tape if you wanted to read file data from the tape.  But
not the 1st 32KB.

Jon
-- 
Jon H. LaBadie                 [email protected]
 11226 South Shore Rd.          (703) 787-0688 (H)
 Reston, VA  20190              (703) 935-6720 (C)