Re: backup takes too long - ( repost without netscape wordwrap )

Neil Truby wrote: > > >> I'm periodically hearing about how bad OnArchive is, but nobody has any definite reasons why. > > Because it's crap! :-) > > Specifically, it's rather flaky. I've never had any problems restoring > with it, and do it every day to a contingency environment, but the two > major problems I have are: > > (1) The catalog frequently gets out of step with what's actually on > disk. This happens particularly when you've done a restore - the > archive you've restored from is not registered in the catalog of the > restored database! Ergo, when next you archive, an inconsistency is > reported. > 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. It appears that it would be safer to just backup each table individually,via unloads, do a nightly dbschema, storing the schema and all the data on tape, or other media. The advantage I guess is that the backup can occur as soon as the largest table is unloaded, which wouldn't prevent anyone from using the data base. The recovery would be as good as the latest backup. Is there something I'm missing here? I realize in OLTP systems you might have to re-enter transactions, but here again, the restore would be a simple reload of the data, and then the users re-enter from the point in time of the last backup. And it could be a phased restore, or parallel, with onpload, unless of course you used rowids. > (2) The continuous log back-up option is prone to crash when a logical > log fills during an archive. > > The first problem is specific to disk dumping. I would suggest that this > product has been "designed" for those of us who dump, and have always > dumped, to disk. One of my surprises when joining the Informix > community is the obsession that people seem to have with dumping to > tape. This seems to be an out-of-date concept to me, unless of cousrse > your databases are huge. > Well, more and more we're seeing larger and larger data bases, in the gigabytes of data, rather than just megabytes. So I would suspect disk dumping will either become more of a refined science, or faster tape drives. 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. (HP/UX) For extremely large databases, of course the big problem is in the window of available time to do the backup. Do you create a series of unloads, to ascii, i.e. "onpload ... | gzip > file" ? or OnBar? It certainly gets more complex as the data base grows. > Neil Truby > Chase Manhattan > Bournemouth, UK Thanks for the info, I'll refrain from using OnArchive, but please tell me about something else that is a better way. :-) Tim -- Tim Schaefer \\\\|// tschaefe@mindspring.com (6 6) ------------------------oOOo---( )---o00o--------- http://www.mindspring.com/~tschaefe http://www.inxutil.com MAKE TIDAL WAVES DIVE IN THE OCEAN IS BIG