->>In response to your message<<-
  --received from Jean-Louis Martineau--
>
> Paul Yeatman wrote:
> >So, as I continue to look at the problem, I haven't seen before
> >that an amflush is require for the directories on holding disk to
> >be included in a recovery yet . . . this kinda of seems to be the
> >case now (that is as much a question as it is a statement).  I see
> >in the amindexd.###.debug log that it is trying to "gzip -dc ... "
> >files in the amanda index directory for the disk being restored
> >yet these files don't exist.  For instance, the log says this is
> >being executed
> >
> >      /bin/gzip -dc '/etc/amanda/cass/index/cass246/_/20070331_6.gz' 
> >      2>/dev/null | sort > '/etc/amanda/cass/index/cass246/_/20070331_6' 
> >yet "/etc/amanda/cass/index/cass246/_/20070331_6.gz" does not exist;
> >It is instead on the holding disk.  Does it not exist because I have
> >never run amflush?  I swear I've performed tens of recoveries that
> >included files on the holding disk that were (obviously) never
> >amflushed.  I'm so confused!
> >  
> 
> amanda will never remove the compressed index files (.gz) while the dump 
> are still on tape or holding disk.
> You said that you removed some dump from holding disk to debug your 
> previous problem, if you ran amdump while dump was missing, amanda has 
> removed the index file.

Ah, I get it!

I have another Amanda server to check with and do indeed see that all
backups on the holding disk have an associated .gz file in the index
directory.  I CLEARLY need to change this yet, until now on this
server, I have been filling a holding disk, leaving those backups
there, and then changing my amanda.conf to point to a new [blank]
holding disk.  I always figured that in the event of a needed restore,
I could change my amanda.conf to point to ALL holding disks.  There was
a reason I was doing this that I won't bore everyone with now.  So now
I see that, when changing to a new (empty) holding disk, all my
previous, compressed, index files where flushed upon the next amdump
run!  Yikes!!!  This is bad!!  The good news is that the data is still
there!!!  But, boy, sure takes away the power of amrecover!  I had no
idea the consequence of this!

> 
> I hope you have a backup of your index files.

I suppose in a way I do but, given the current state of things, it
seems it would be impossible to figure out what needs to be restored to
correctly repopulate my index directory.  I will hope for the time being
that no restores will be needed until I create stable holding disks and
repeat full backups of everything.  In the meantime, should a restore
be necessary, I will resort to an 'amadmin ...  info' of the disk in
conjuction with sequential hand-run amrestore's.

Thanks Jon and Jean-Louis!

Paul

> 
> Jean-Louis
> 

-- 
Paul Yeatman       (858) 534-9896        pyeatman AT ucsd DOT edu
             ==================================
             ==Proudly brought to you by Mutt==
             ==================================