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
