== How Amanda knows what restore program to use

Here's an error message we got from [[Amanda http://www.amanda.org/]]
during a recent restore attempt:

> _warning: restore program for /slocal/amanda/bin/ufsdump not available._ \\
> _amrecover couldn't exec: No such file or directory_ \\
> _{{C:nbsp}}{{C:nbsp}}problem executing restore_ \\
> _amrecover: amrecover: pipe data reader has quit: Broken pipe_

First the background: the filesystem that we were attempting to restore
a file from had recently been migrated from our old fileservers to one
one of our [[new Solaris fileservers ../solaris/ZFSFileserverSetup]];
the backup we were restoring from had been made on an old Solaris
fileserver, and was being restored on the new fileserver. (Our old
fileservers use a cover script for Solaris _ufsdump_ for local reasons.)

What Amanda is complaining about here is that it doesn't know what
program to run to actually restore files from the backup. In fact
it wound up taking a guess, but the guess didn't work.

(Amanda doesn't have its own format for backups; instead it relies on
things like GNU tar and _ufsdump_, and just ships around and manages
their output. This means it needs to run an outside program, the
'restore program', in order to actually retrieve things.)

When it makes a backup, Amanda also records the 'type' of the backup and
the program that was used to generate it. Unfortunately, Amanda only has
three types: Samba backups, tar backups, and a general type for 'dumps',
of which there are at least four sub-varieties.  Amanda guesses which
sub-variety of dumps it is dealing with (and thus what program it should
use to restore them) by looking at the program that made the backup.  If
it doesn't know the program at all, Amanda falls back to the hard coded
default name '_restore_'.

(You can see what any particular copy of Amanda thinks these programs
are by examining the debug logfiles for _amandad_; they're part of the
configuration parameters that get reported on startup.)

In our case, Amanda on the new fileservers was never configured to use
our old fileserver cover script as the '(plain) dump' program, and so it
didn't know that it should use _ufsrestore_ (its 'plain dump' restore
program) to restore it. There's two options for a solution:

* reconfigure Amanda on the new fileservers to use the same nominal
  _ufsdump_ cover script. This is undesirable for various reasons,
  but is temptingly easy (and we don't need to do UFS dumps on the
  new fileservers).
* put a '_restore_' program (either a cover script or just a symlink
  to _ufsrestore_) somewhere in our _$PATH_ when we do Amanda restores.

I suspect that we'll wind up adopting the first solution.

~~Update~~: I was wrong about the second option; you have to do it
somewhat differently to make things work. See AmandaRestoreProgramsII.