Wandering Thoughts: Recent Entries For 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 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.