Re: backup takes too long

Neil Truby wrote: > > Tim Schaefer wrote: > > > Hmmm, so it's ok for doing the backup, but the restore is questionable. > > This would be the major point of the backup, to restore as needed, > > obviously. > > > > I didn't make my point clearly enough: I've not had any problems with > doing restores per se, but doing a restore results in the onarchive > catalog, which is just a table or group of tables I guess, in a state > prior to its knowing about the archive from which you've just restored. > This results in an inconsistency message, requiring a proceed/cancel > reply next time you launch an archive, which is easy enough to bypass > interactively, but fatal if your archives are scripted. > Hmmm, I'll keep that in mind. Having learned the "easy" part of OnArchive the restore simply scares me. I get the feeling it'll make a bigger mess of things than simply reloading data. In a real restore I would want as much control of things as possible. I don't get that feeling from onarchive or onbar. I've also seen frequently where a restore of just one table is desired. > > I noticed the OnArchive program handles archiving to disk, which is something I > > recommended, and then the O/S would pick up the archive on it's regular UNIX backup. > > Exactly what I do. And always have done with tbtape/ontape. > Cool. I'll head this way... :-) > As to an alternative to onarchive; my site is quite new to Informix, and > before I arrived was being administered by Informix consultants. They > had installed the onarchive procedures because we had a requirement to > back up to disk (the archive is immediately ftp'd to a remote site for > contingency), and ontape to disk isn't supported. But if I'd been there > from the start, I'd have used ontape anyway, and would commend it as a > solution. IMHO it's perfectly OK provided you know what you're doing and > you take due care. > > Neil Truby > Chase Manhattan Bank > Bournemouth,UK Looks like an interim solution also could be to use onpload ( The high-performance loader ) to unload each table via unload scripts, piped into gzip and the table.gz files get picked up by the UNIX backup. My instinct is to try to go for a parallel restore with onpload, which would be faster than ontape, but maybe for simple, small data bases this would not be necessary, and just use ontape. The onpload scheme could also allow sending the .gz files to different tape units, etc.. The only disadvantage to onploading the tables ( during a restore ) in parallel would be if rowids were used. (?) But it would also eliminate even knowing onbar and just stay with the standard UNIX back-up, making things even easier to maintain. But I could be wrong. :-) Thanks for the insight... Tim -- Tim Schaefer \\\\|// tschaefe@mindspring.com (6 6) ------------------------oOOo---( )---o00o--------- http://www.inxutil.com MAKE TIDAL WAVES DIVE IN THE OCEAN IS BIG