Re: On-Archie or OnBar ??

Tim Schaefer wrote: > > Derek, > > The onarchive program works fine on a variety of platforms > with one exception. Have you ever tried to restore what you've > backed up using onarchive? On some platforms the backup > is great, the restore doesn't work. > > Unless you can restore from your backups, your backups are worthless. > > I tend to think that onbar is equally worthless. I've done a > complete set of tests with it, and find it does not have the > features necessary for real-world recovery. For example, the > infamous point-in-time restore applies to the WHOLE INSTANCE > without the option to restore either a data base , dbspace, > table, dbslice if you use 8.x, or any combination of these. > > Here's a great test for your recovery: A user drops a table. > Recover the table using onbar. Oh, uhm, fortunately for you > the table was in its own dbspace. Right. Well, the logs come > back with the restore and redelete the table for you. Oh, ok > let's restore using point-in-time. Bring the engine down, > remove the links to the raw device, bring the engine up, engine > thinks the dbspace is hosed, marks it offline. Now you can > restore it using point-in-time restore. Uh, well that applies > to the whole instance, sorry. What if you didn't want to > bring the whole damn instance back? The good folks who created > onbar really don't think like the real world. > > You have to really build your system around onbar if you > choose to use it. I can point to site after site who ignored > onbar until after they built a system only to find that because > of onbar the system had to be redesigned around onbar's limited > feature set, or they abandon onbar because of its limitations. > > Unless you can restore from your backups, your backups are worthless. > > The only benefit I see to onbar is that it tells the engine > things are backed up so that new logs can be brought online, > or other situations where onbar is needed to tell the engine > things are ok. But as to a backup strategy, I still tell people > to buy as much disk for table dumps-to-disk as the data base. > > We had onbar working great with ADSM and it will continue to work > great, but what good is it for me to attempt a restore? Only when > I would want to restore the whole damn instance. This is all its > good for. > > Is this crazy? No, there is no table-level restore in onbar. You > get all or nothing. And if the last onbar backup is hosed you are hosed. > You are at the mercy of also needing the logical logs. For shops who > have onbar working with their heavy OLTP, and can honestly say they > can restore, these are shops where they have probably been through a > certain amount of pain getting this to work. > > I still challenge anyone out there to tell me that a table level dump > to disk and UNIX backup is less than onbar. Even on NT using cooked > files and a tape drive, simply restoring the dbspaces with NT backup > is better than relying on the limitations of onbar. > > Onbar should scare the living daylights out of you for restore. Don't pick on OnBar, it has more functionality than the other two archive utilities put together. What you are saying is that you don't like Informix's archive & restore policies. And from past experience I know that you are ALWAYS right Tim, so I won't argue the point. :-) But to clarify the policy, all data in a database instance must be in a consistent state and in the same time zone. Because referential integrity can be maintained at the application level, the database server has no way of knowing which tables would need to be restored together with your lost table in order to maintain integrity. I agree it would be nice for the DBA to be able to override this guarded approach, but currently you can't. I have a number of customers who would like to restore individual tables from archives, but that has nothing to do with OnBar as such. I believe June wrote a utility to restore a single table from an OnTape archive. But I have not heard of such a utility for either OnArchive or OnBar. Cheers, -- Mark. +----------------------------------------------------------+-----------+ |Mark D. Stock - Informix SA http://www.informix.com |//////// /| |mailto:mdstock@informix.com http://www.informix.com/idn |///// / //| |http://www.iiug.org +-----------------------------------+//// / ///| | Tel: +27 11 807 0313 |If it's slow, the users complain. |/// / ////| | Fax: +27 838250 2325 |If it's fast, the users keep quiet.|// / /////| |Cell: +27 83 250 2325 |Therefore, "No news: travels fast"!|/ ////////| +----------------------+-----------------------------------+-----------+