2008-10-22
How Amanda knows what restore program to use
Here's an error message we got from Amanda during a recent restore attempt:
warning: restore program for /slocal/amanda/bin/ufsdump not available.
amrecover couldn't exec: No such file or directory
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;
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 toufsrestore
) 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.