On Friday 30 August 2002 11:28, Quinn, Richard C. - Collinsville IT wrote:
First, I had to pick this message out of the trash because the return address is forged. >Hi, > >We are running informix 7.3 with Amanda 2.4 on Solaris 2.6. > >We have a dilemma with regard to backing up our Informix Dbase. > >We have a 120 Gig dbase we normally backup via the Informix > ''ontape'' utility. > >Doing this gives us the 'roll forward' capability. So that in the > event of a crash. >We can recover the database pretty much up to the minute of the > last transaction. > >So now we have Amanda up and running and we wish to be able to > back up our Database. > >From what I am told, Amanda won't back up a single image(which, I > guess, means a file) on more than one tape. >And, from what I understand, the informix dbase is backed up as a > single image. > >This single image is far more than can be stored on one of our DLT > 7K tapes(70 gig compressed). > >So the alternative would be to export the database to a filesystem > and then back THAT up onto Amanda. >Well, from what I am told, if we do that, we'll lose the ''roll >forward'' capability. >That would not be acceptable to our users. > >That and doing it this way(the export method) would require > another 130 gig of unused disk space so as to >have a place to put the exported Dbase. > >We tried using a combo of ''onbar'' and using a FIFO, but that > didn't seem to resolve our Dilemma. > >I think the Key issue is the word ''image'' and the fact that one > cannot be written over more than one tape. > >Is there anyone who is familiar with this problem? > > >Rich Unforch, this answer is gonna be offtopic, sorry. Yes, and its an insurmountable problem for amanda unless you can break the database into smaller, will fit on a tape, pieces. Amanda has never been able to span a single filesystem across more than one tape and I don't believe doing that is even in the designs outline for reasons of dependability. So I use tar, and split my disklist entries for /usr into subdirs that will fit. But since most database's are basicly a "one door" model, I've no idea how to go about doing the subdir equivalent to a huge database. One possible, non-amanda solution might be to setup a raid array of 4 160 gig drives, giving you 320 gigs of recoverable storage and use rsync to do a nightly image. This is good for a 1 drive failure and we've confirmed that it works by doing a shut down and exchanging one of the drives with a fresh one. On startup of the md system in the reboot, the rebuilding begins, and can even be interrupted by yet another reboot without effecting the recovery, it just starts back up again at the point where it was interrupted. We did this disk swap test half a dozen times without any problems before it was placed into service at the tv station where its now been doing its nightly thing to much of the system for over 6 months with no hiccups, including the recovery of several crashed windows boxes from it during this time. The elderly WD drives in them have about all self destructed by now though. We are well aware that a 2 drive failure means everything is gone. OTOH, this is much faster even over the network because rsync only moves that which has changed since the last such operation, making it effectively at least 10x faster than a tape drive since the raid has an hdparm -tT speed in the 50+ meg/second thruput. So the 100baseT is the bottleneck, not the tape drive. We used promise 4 port cards, (20269's IIRC) 2 of them so each drive was the primary on its cable, in a software raid using mdtools on linux. ISTR we did that for less, far less, than the 4 digit quote we got from Knox for Arkeia. Having played with the single drive arkeia freebie, lemme tell you that amanda is one heck of a lot friendlier. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.13% setiathome rank, not too shabby for a WV hillbilly
