On Wednesday, September 22, 2010 09:13:37 pm Christ Schlacta did opine: > Why keep a backup server up 24/7 when it only works durring bakup hours? Because its also my main play box.
> Why not append the entire catalog to each tape? Or at least the > entire catalog to date? This is what my wrapper does, the entire catalog, including the cstalog/indices from the amdump just completed. > Sent from my iPhone > > On Sep 22, 2010, at 17:53, Gene Heskett <[email protected]> wrote: > > On Wednesday, September 22, 2010 08:48:40 pm Dustin J. Mitchell did > > > > opine: > >> On Wed, Sep 22, 2010 at 10:07 AM, Jon LaBadie <[email protected]> wrote: > >>> Any thoughts on how desireable you feel be a separate > >>> copy of amanda data would be and other approaches? > >> > >> This comes up often, and I've never found a solution I'm happy enough > >> with to make the "official" solution. > >> > >> Gene's approach is the obvious one, but has a few limitations: > >> > >> - What do you do if you run out of space on that tape? Start a new > >> tape? How do you reflect the use of that new tape in the catalog? > >> > >> - How does recovery from that metadata backup work? There's a > >> chicken-and-egg problem here, too - you'll need an Amanda config to > >> run any Amanda tools other than amrestore. > >> > >> Let's break down "metadata" into its component parts, too: > >> 1. configuration > >> 2. catalog (logdir, tapelist) > >> 3. indexes > >> 4. performance data (curinfo) > >> 5. debug logs > >> > >> Configuration (1) can be backed up like a normal DLE. The catalog > >> (2) > >> should technically be recoverable from a scan of the tapes > >> themselves, > >> although the tool to do this is still awaiting a happy hacker to > >> bring > >> it to life. Indexes (3) are only required for amrecover, and if your > >> Amanda server is down, you likely want whole DLEs restored, so you > >> only need amfetchdump. Performance data (4) will automatically > >> regenerate itself over subsequent runs, so there's no need to back it > >> up. Similarly, debug logs (5) can get quite large, and generally > >> need > >> not be backed up. > >> > >> So, to my mind, the only component that needs special handling is the > >> catalog, and we have a menu of ways to handle that: > >> > >> - append a copy of the entire catalog to the last tape in each run > >> (hey, what is the "last tape" now that we have multiple simultaneous > >> tapers?) > >> > >> - append a copy of only the catalog for that run to the last tape in > >> each run > >> > >> - finally get around to writing 'amrecatalog' > >> > >> - rsync the entire catalog to another machine nightly > >> > >> I just stuck that last one in because it was my technique back when I > >> managed a fleet of Amanda servers. Each would simply rsync its > >> config > >> and catalog to the other servers. Since they were all backing up to > >> shared storage (a SAN), I could do a restore / amfetchdump / recovery > >> of any dump on any server without trouble. It's a very > >> non-Amanda-centric solution, but it's *very* effective. > >> > >> Dustin > > > > And TBT, Dustin, if that other server is known to also be a 24/7 > > machine, > > that sounds like a jolly good idea. My milling machines drive, a > > 60Gb, > > would have more than enough space to do that, also including an > > image of > > /home/amanda. But its uptime is possibly not on a par with this box > > when > > the weather & power supplies might take it down. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Kliban's First Law of Dining: Never eat anything bigger than your head.
