Re: Back-ups to Disk?
Posted in 1993
John Powell (johnpo@vcd.hp.com) wrote: : This post is related to an earlier one about logical logs and named pipes. : I realize that Informix only supports archives and logical logs going to : tape (via tbtape on Rel. 5) at this time. However, I would like the archive : and logical logs to go to disk from which they can be backed up to tape via : the daily UNIX file system backups. I imagine that if one were to dedicate : enough disk space for this purpose, write the appropriate shell scripts, and : arrange for this area of disk to be put to tape daily, then one would have : a fairly reliable backup strategy in place. Has anyone tried this yet? : Has anyone successfully restored (rolled forward) Informix from files on : disk? Please reply with any information you have on this subject. : Some background on this post: Our computer operations group is moving : towards an 'operatorless environment'. There will be no computer operators : around at night or on weekends to put tapes into DAT drives so that tbtape : can send archives and logical logs to those tapes. We have recently : purchased a system called Alexandria (no plug intended) which will completely : handle the UNIX back ups - scheduling, library functions to track what is : on each tape, control over a 'jukebox' of tape devices so that tapes can : be switched in and out automatically as needed, etc. Hence the desire to : find some way to perform the Informix reliability backups to disk or (better : yet!) to pipe their output into Alexandria. Has anyone out there used : Alexandria yet? : : _____________________________________________________________________________ : John Powell : HP Corvallis, IJBU CIM Dept. : Telnet 750-8389 : Phone (503) 750-8389 : e-mail: jpowell@cv.hp.com (Internet) : ____________________________________________________________________________ In theory what you want to do will work, at least for the logging, but you run across potential problems with the archive/restore. First off, using any DAT tape is not the panacea that it seems, as Informix uses the Unix write() call to write to tape. This call is subject to your Unix maximum file size limit. This is usually 2 gig and can often be upped to 4 gig and no more. It's limited by the size of a long int. No matter what you do, your tape size set in tbmonitor needs to be less than your Unix file size limit. We have 15 gig DAT drives, but we can only put 4 gig on each one in an Informix archive. You're also limited in the types of device you can use. On restore of a multi-volume archive, tbtape looks for a physical rewind and a new beginning of tape marker. We tried putting multiple 4 gig "pseudo-volumes" on one tape. Tbtape saved it off fine, but refused to restore after the first archive. If you go above two volumes on a restore from a hard disk, you'll probably run into the same problem. As long as you can get your entire archive or set of log tapes onto one physical device in Unix, you scheme will probably work. In the "Managing Large Databases" course at 93 Informix World, the instructor suggested using a link such as "/dev/archtape" as the log device. When each disk was filled in a multiple-disk backup, the message would come up on the screen calling for swapping tapes. The operator (or theoretically a program which watches for the output could do this) would then relink another physical disk to /dev/archtape. However, I think you're going to find that Informix's tbtape is not very amenable to trying to customize it for an operator-less environment. We've really wanted to do this, but haven't yet found a way that is reliable enough to bet our business on. Whatever you do, before committing to it, do several levels of archives with several logs, and then try to recover from it. In our abortive attempt to put multiple archives on one no-rewind log tape, all looked fine until we tried to recover, at which time the machine barfed. We hassled Informix incessantly about it, and they eventually said "f*ck you, we won't do anything custom for you". Maybe **sigh** version 6.0 will be better. -- =========================================================================== jlumbley@netcom.com (Joe Lumbley) "If you believe that my statements Database Administrator represent my company, please send The Tigon Corporation money and I'll send you stock" Dallas, Texas ===========================================================================