|
Re: amfetchdump inventory mode
2007-09-26 17:19:07
Jean-Francois Malouin wrote:
* Ian Turner <vectro AT vectro DOT org> [20070926 15:37]:
On Wednesday 26 September 2007 14:57:58 Jean-Francois Malouin wrote:
I'm trying to understand how 'amfetchdump -i' works (amanda-2.5.2p1):
At the moment, not all that well. :-( In theory, amfetchdump can be used to
recreate the Amanda logfile used to track which dumps were stored where. So
if your backup server bites the dust (and wasn't itself backed up), you can
use amfetchdump -i to restore the logs. After that, you will be able to use
amfetchdump to operate the changer and restore specific dumps. Note, however,
that amfetchdump -i will not restore the indices, so you'd still be unable to
use amrecover in that case.
I have it on my plate to fix amfetchdump -i, but before I do so, maybe I
should ask for a show of hands: How needed is this feature, anyway?
You mean the "do this to get what's needed for amfetchdump to work"?
In my book it's absolutely essential! I would (I am now!) be very
nervous to rely on a restore utility that would not work when
things get real'bad.
One of the most important feature of amanda was (it still is but read
on) the possibility of doing a bare-metal restore with just a few
utilities. I say was because in my case the ever increasing amount of
data, the size of the DLEs and the number of chunks needed in order to
fit in my tapes (LTO-1 and LTO-3) was getting out of hand --too much
likely to 'forget' some data while including/excluding dirs in a DLE--
so I had to use the tape spanning feature. I get a much better tape
usage but now I can't do bare-metal restores in case something real
bad happens. I understand that I can't have both the cake AND the
cherry but I would be hard pressed to justify using amanda to our
computer people at my site when such an important feature is missing.
But what is exactly needed by amfetchdump?
The amdump and log files in the logdir?
Sorry for the long tirade!
Thanks, jf
Just as a point of reference, I have a daily cron job that follows
amdump. It watches Amanda to see that it has completed. Then it backs up
the entire /usr/local/etc/amanda directory to another drive on the same
system, then tars and gzips it and scp's it to an archive directory on a
different server. So, every time I run amdump, I follow it with a backup
of a backup of the amanda directories and everything they contain --
configs, indexes, etc. If the drive fails, I have it on another drive.
If the system fails, I have it on another system. And those end up on
tape the next day.
I also have on my intended projects for this fall a Solaris-9/Amanda
bootable disaster recovery CD. I have it all sketched out, just the down
and dirty work to do, and then document my implementation notes in
enough detail that others can do it. My intention is to have a reserved
IP for disaster.my.department.edu, so I don't have to mess with any
install miniboot, reboot, configure the interface, etc. It will just
boot and allow me to run amrecover with a connection to the Amanda
server. I probably shouldn't be touting my chickens before my eggs are
hatched. But, that's the plan.
For the server, it gets a little messier. But, I have several alternate
contingency plans, including just a silly old DAT of the Amanda server.
Recover that (so I have the drivers for the AIT5 Tape Library, among
other things), pull the latest amanda directory from the other server
where it was archived after the last successful backup, and I'm back in
business.
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<hoogendyk AT bio.umass DOT edu>
---------------
Erdös 4
|
|
|
