>... Each run, a gzip'd index file is >created. Each run, this file is about 20 bytes long. I doubt gzip is >compressing the information on 20+GB of files into 20 bytes... :-( > >Looking at the sendbackup.*.log files, I can see where the index >program is invoked. I don't see anything to indicate _why_ the index >files are so small.
Could you post one of those files? The symptoms seem to imply indexing
is enabled but the client just never sent anything.
Are your backup images OK? If you pick some client/disk that is having
an index problem, what happens if you try something like this:
mt -f /dev/whatever rewind
amrestore -p /dev/whatever <client> <disk> | gtar tf -
>I'd like to know how to restore index files from tape, if anyone knows
>how to do that...
As Joshua said, the general problem of doing this with Amanda is
difficult since the client and server may be running totally different
OS's and the software to read an image may not be available on the server.
So the data has to be shoved back to the client, indexed there and then
sent back. Not just a thing you're going to do with a couple lines of
shell script coding :-).
However, in the special case of using GNU tar, it's portable so this
is easier. The attached script is **not** well tested, but might get
you going:
* create a work area and cd to it
* rewind the tape (you might want to mount it read-only, just to be
safe)
* run the script with the tape device as the first argument (and
possibly the client and disk)
* the script output will look something like this:
amrestore: 0: skipping start of tape: date 20020406 label JJ1/test-jj
amrestore: 1: restoring
gurgi.jrj.west-lafayette.in.us._work_tmp_GDGraph-1.33.20020406.0
amrestore: 2: reached end of information
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: restoring
gurgi.jrj.west-lafayette.in.us._work_tmp_amanda-win32.20020406.0
amrestore: 1: reached end of information
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: restoring
gurgi.jrj.west-lafayette.in.us._work_tmp_vnc__unixsrc.20020406.0
amrestore: 1: reached end of information
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of tape: date 20020406
You can ignore the "reached end of information" and "not at start
of tape" messages. They are just an artifact of calling amrestore
for one file at a time.
If it works, the script will create a directory structure in your current
working directory that should mimic the real area. Very, very, carefully
look at the files it creates. If you're happy with them, move them over
to your real index directory, making certain to set the ownership and
modes properly.
Actually, if I was doing this, I'd tar up (or rename) the existing index
area into a safe place, then replace the files, then do some amrecover
testing. Only then would I get rid of the originals.
>-Adam
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
amreindex.sh
Description: amreindex.sh
