Chris, * Chris Hoogendyk <[EMAIL PROTECTED]> [20070926 17:20]: > > > Jean-Francois Malouin wrote: > >* Ian Turner <[EMAIL PROTECTED]> [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 > > <[EMAIL PROTECTED]> > > --------------- > > Erdös 4 > -- <° ><
