Chris,
* Chris Hoogendyk <hoogendyk AT bio.umass DOT edu> [20070926 17:20]:
>
>
> 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 do something similar: I have amanda running a ssh agent and when
amdump finishes I rsync over ssh the amanda configs to several remote
hosts. Just to be paranoid, I also cross-backup all the different
configs among themselves over the different servers (3 of them).
regards,
jf
>
> 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
>
--
<° ><
|
