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:[EMAIL PROTECTED] Sent: 09 September 2004 14:01 To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] JG Computing 4455 Province Line Road (609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
