>I'd like to recover a file from the backup using amrecover.
>Unfortunately amrecover tells me, that there is no index available for
>the given disk/date/host. BUT: As fas as I can see, there are all index
>files in the index directory /usr/adm/amanda...
OK, let's tackle this problem first.
It would help to see the actual amrecover messages (all of them), as
well as know what version of Amanda you're using.
First, let's make sure the index files are where they should be. Run:
amgetconf <config> indexdir
That points to the top level of the index directory. Within there should
be a directory for each of your clients. The name will be the same as
(or very close to -- '/' and whitespace are converted to '_' and '_'
is converted to '__', but that's rare in a host name) the disklist entry.
Within each client directory will be a directory for each disk. Those
names will be similar (see above) to the disk name, e.g. "/dev/hda5"
would be "_dev_hda5".
Within a disk directory will be the gzip'ed index files. They have
a datestamp and level in the name, and you must have all of them back
through the full dump preceeding the date you're requesting.
Also, if you're using GNU tar, make sure the files are formatted properly.
If you look at the first few lines and they start with a large number, it
means you're using a broken version of GNU tar. You'll need to upgrade
to 1.13.19 (alpha.gnu.org), and those index files are pretty much junk
(unless you want to strip the leading number off of each line).
Make sure all the directories and files are readable by the Amanda user
(the one that runs amindexd from inetd/xinetd).
Next, run "amadmin <config> find <client> <disk>" and make sure it finds
backups from the date you're interested in back through a full dump.
>The backups were flushed to the tape NEURO006 and I would have expected
>that amanda requests tape NEURO007 next, but it tells me that it would
>like a new tape. ...
If Amanda asks for a new tape, it means the number of tapes in your
tapelist file is less than your tapecycle value.
>Am I right that I would have been informed if one tape
>were not enough for amflush?!?
One way or another. If you have a tape changer configured, amflush
would have automatically advanced to another tape (up to runtapes),
just like amdump.
If you don't and amflush ran into end of tape, it would have reported
an error and told you it left some images in the holding disk.
If your holding disk is now empty, then the amflush probably worked.
Exactly what happened should have been documented in the amflush E-mail.
>Something else is strange: after amflush I tried amcheck still having
>tape NEURO006 in the tape drive. And amcheck was happy. It was happy
>with NEURO007 as well.
That seems very wrong.
Are you sure amflush did anything to NEURO006? If you run:
amadmin <config> find <some-client>
(where "some-client" is a client you know was flushed) does it show
that tape? Were any errors reported in the amflush E-mail?
>Could the problems accessing the tape drive during the last days have
>left some corrupt info files?!?
Not likely.
>I would really be glad to get some advice where to look and what to do!
Take a very close look at your tapelist file and at your tapecycle value.
Also, "amadmin <config> tape" is a handy way to see what tape(s) Amanda
expects to use next.
>Christina Rossmanith
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
