RE: Where is my amgetidx?

Thanks Jon!

Solved that PDQ.  As you said, by running amadmin I could get what it had
parsed my configuration file as.  

It turns out that having "index yes" in my global dumptype is not enough -
this gets ignored.  Moving the index yes into each of the types individually
works fine.  Now feeling slightly sheepish on not having tried this first.
[In my defense the box has a SCSI issue that causes it to crash so I've been
trying to fix that instead...]

I've been subscribed to this list for a while and I'm always impressed at
the helpfulness :-)

Is this a possible bug then, since the comment for global dumptype uses
"index yes" as an example?

Thanks again,

Simon

-----Original Message-----
From: Jon LaBadie [mailto:jon AT jgcomp DOT com] 
Sent: 09 September 2004 14:01
To: amanda-users AT amanda DOT org
Subject: Re: Where is my amgetidx?


On Thu, Sep 09, 2004 at 10:43:01AM +0100, Simon Hildrew wrote:
> I have a very similar problem.  I get no index files produced, so I 
> can't use amrecover.  In the FAQ it suggests that I might no have it 
> enabled, but 'index yes' is in my global dumptype.  In my first ever 
> dump, the cdirectory I had specified did not exist, so I have since 
> created it by hand.
> 
> Whilst a backup runs absolutely fine and I can use amrestore to obtain 
> the tar files from the tapes, amdump is still refusing to create indexes.
> 
> What trouble-shooting can anyone suggest to track this down?

First shot, ask amadmin to dump the paramaters of some of your DLE's.

  amadmin <config> disklist <host> <dle-name>

It should output "index YES" among other things.

Then I would check the various "dir" settings in amanda.conf. Make sure they
exist and are readable/writable by the amanda user/group.

> Particularly, I'm not very clear on:
> How exactly the indexing program gets run?
> Where I would expect indexing related errors to appear in logs / if I 
> need to enable any debugging to get more information?
> 

Indexing is done by duplicating the backup data stream (from tar or dump)
and passing the second copy through a recovery program (tar or restore) to
/dev/null but capturing the file list it generates and sending that over a
separate data stream to the tape host (separate network connection).  It is
then compressed on the tape host.  Upshot is you need to look both on the
client logs and the tape host logs for possible problems.

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)