On 9/27/07, Jean-Francois Malouin
<Jean-Francois.Malouin AT bic.mni.mcgill DOT ca> wrote:
> Yes, you're right that it is manually feasable. However conceptually
> simple the task is, I feel that potential mistakes are bound to
> happen, particularly when doing a restore under pressure! Remember,
> you have the mob^H^H^Husers on your back, yelling bad words at you :)
>
> I'll see if I can write a dirty little script that could somehow
> automate the procedure...

Just to be clear, while native-tools restores are important, and not a
feature we're considering dropping, they should be *very* rare.

It's the purpose of the inventory mode, as well as amrestore, to deal
with the situation where a fresh install of Amanda, without much
configuration (just a tapedev), must perform a restore.

To summarize the levels of functionality for restore:
 OS, Amanda, Config, Logs, Indices: use amrecover
 OS, Amanda, Config, Logs: use amfetchdump
 OS, Amanda: use amrestore[1], or use inventory to recover the logs
and then use amfetchdump
 OS: use native tools

Unless you're locked in a bunker without access to Amanda binaries,
installing Amanda on a fresh box should probably be the first step of
your bare-metal restore process.  That said, you can be confident
that, given a swiss army knife, some duct tape, and a basic UNIX
system, you *can* get at your data.

Dustin

P.S. I think it will make more sense to move the inventory mode to
amrestore, making that the generic restore-without-config-or-indices
tool.  It doesn't really fit well with the operation of amfetchdump,
IMHO.  Opinions welcome.

[1] At the moment, amrestore doesn't support splitfile reassembly,
although it's easy enough to do manually with 'cat'.  We'll be adding
that capability to amrestore soon.

-- 
Storage Software Engineer
http://www.zmanda.com