Re: HP-UX / Informix backup

Nicholas Penney wrote: > > I do not know informix at all and we have nobody > here at the moment that does, however we currently > run an informix application on an HP Unix server. > > As the informix database is using 'raw' partitions > the HP backup utility 'fbackup' does not back it > up. > > We really need to copy the informix data out to a > filesystem before running the backup. Can anyone > tell me the best way to do this. I have been > pointed to the sbtape utility that comes with > informix, but this only seems to write to a tape > and we do not want to have to use 2 tapes (and > have the operators swapping the tapes as > required). > > Thanks in advance.... > > -- > Nicholas Penney, HP-UX Unix Support sbtape sounds like it belongs to Informix Standard Engine, which I've never used. Later versions of Informix have tbtape and ontape. Many sites, including mine, use these to direct output to disk rather than tape (define the TAPEDEV parameter within Informix appropriately), then use tar/cpio or whatever to move them off to tape. I assume this will be possible with sbtape also. Although I've used this technique satisfactorily at several sites, it isn't supported by Informix. The reason isn't that it doesn't work (it does), but that whenever an archive is run it overwrites the previous one, and this is not (without UNIX manipulation) over-rideable. Thus sites were running into version control problems with archives. A correctly-administered archive script will avoid this. Even if your HP utility could back the raw partitions you shouldn't use it, just as you shouldn't use dd, which could read them. The Informix back-up utility has sophisticated functionality to ensure that the back-up contains logically consistent data. For example, your HP utility would take an old copy of pages on disk which might well have been modified, with the "new" page held in the database server's cache. Or, suppose it takes an hour to back up all the data, you might have two related tables whose copies are an hour apart, rather than the same point in time. In fact, I doubt whether you could restore from such a back-up at all. Neil Truby Chase Manhattan Bank Bournemouth, UK neil.truby@chase.com