Informix server migration

[Alan Riggs]

I have a need to migrate an Informix database from a partner's datacenter to our datacenter. Among the complexities of this project is the issue of media backup/restore. The client is using Omniback 2.55 and Informix onbar. My own experience is primarily with Oracle, and I have never worked with Informix using omniback. We use omniback 3.5. My questions:

Is it possible to restore an Informix backup made under omniback 2.55 in an omniback 3.5 environment?
If so, will it be necessary to import the partner's 2.55 database or can I simply import the tape to our database?
WHat type of configurations/customization might need to be done to the Informix onbar agent in order to match what the partner's site is doing?

[Rich Wright]

It should be possible to restore the 2.55 backup under 3.5.
But, the safest thing to do would be to rename /opt/omni, /var/opt/omni, and /etc/opt/omni. Then install OB2.55 and restore the OB data base followed by the Informix restore.
You need some Informix control files for the restore to work.
These should be backed up as a post-exec after every Informix backup. Here is our list...
(for each Informix DB instance)
/informix/etc/ixbar.
/informix/etc/oncfg_.1
/informix/etc/onconfig.
(and ...)
/informix/etc/sqlhosts

I would think that "import tape" would take much too long.

[Byron Myers]

Another option to consider is using OBII to backup the raw LV's used by INFORMIX, then create the evquivalent LV's on the target system and restore - this bypasses onbar altogether. I have tried this with success. The backup and restore of the INFORMIX file systems is straight forward with OBII, tar, fbackup, ftp, etc.. If you use onbar, don't forget to synchronize the sqlhosts.soc file with the target's name resolution - as sqlhosts.soc ties hostname with the INFORMIX instance.

[Alan Riggs]

Rich,
I'm not sure whether importing the tape or transfering the partner's OB 2.55 database will actually be faster.

Byron,
I like your idea. When backing up/restoring the rlv's are there any special precautions which you have had to take? Obviously, I would need to match the exact LV configuration (with symbolic links, in this case, since I will not be replicating their storage solutin), but is there anything else I should watch out for in creating the backup/restore specification?

[Nick Wickens]

Hi

We do lots of recoveries of informix instances between boxes and it did take a while for us to find the best method but we have now got it down to a fine art - here are a couple of pointers.

One thing to be aware of is that unless the versions of Informix on both sites are at exactly the same release level you may have problems. (ie if you decide to use a later Informix release for your datacenter build).

The problem we found was that Informix made subtle changes to the format of the ixbar file that you need for the recovery to work.

Basically an Informix restore will require the following between the two machines -

(1) You will need a copy of the ixbar file from the original at the exact point of backup completion. If you can remove any log entries from this file ( identified by "L") it does make whole instance recoveries easier but make sure you want to recover the system back to the point that the onbar backup was started - ie no system activity after the start.

(2) You will also require the oncfg file from the system at the same point as the ixbar file. Again removing log entries does make the recovery easier. Both the ixbar and the oncfg files will have a number in the file name which should correspond to the SERVERNUM parameter in the ONCONFIG file. Both these files should exist in $INFORMIXDIR/etc

(3) You will also need to make sure that you have exported the OB2APPNAME and OB2BARLIST environment variables before starting the restore.

(4) Any raw volumes and link files need to be in place prior to the restore.

(5) Do the restore with the "onbar -r -w" command at the command line (logged on as Informix) rather than letting Omniback do it. If the configuration is setup correctly the instruction back to Omniback should be automatic.

Check the omniback integrations manual for details on Informix - its not too bad as manuals go.

[Alan Riggs]

Nick, that's a helpful procedure for restoration, but it appears to rely upon all servers in question being configured in the omniback database. In this case, the server to which we will be restoring will not exist in the OB II database we bring down from the remote site, OR we will be importing the tape into our local OB database and teh remote server/Informix config will not exist.

Given your experience, can you give me some ideas how I might plan for such a situation?

[Nick Wickens]

Hi Alan

The Informix engines etc must all be in place on your local system before you can attempt any recovery. That is you will need to have recovered and reconfigured everything in the /opt/informix (ie the $INFORMIXDIR) first before the restore will run. Therefore you will need to import and recover a backup of the /opt/informix filesystem to your local machine first. This is because Informix just uses Omniback purely as a storage manager and the recovery must be done using the informix onbar utility (Omniback will call that routine). If you have the informix installation disks you could install informix first and then amend the $INFORMIXDIR/etc/onconfig and sqlhost files to match the remote system. You would need to run the informix/omniback integration script as detailed in the Omniback integration manuals.

There are alternatives to using Omniback though - You could just tar or fbackup the /opt/informix directory and recover it locally first. Then you could use the informix ontape backup facility for the database recovery (ontape -s I think is the command for the backup and I think its something like ontape -r to recover) This method may greatly simplfy things for you if you are not too familiar with informix. However you will still need to have built your local volume groups and logical volumes and put in place the appropriate link files to the volumes first. It is very important when using onbar or ontape that the link files match the directory and filenames of the remote system & point to raw logical volumes of exactly the same size as the original otherwise the restore will fail.

When i get back in the office I will try and remember to post up our documentation for informix recoveries plus some scripts I created to build a second script for recovery to an other system this should give you a list of everything you need.

If I forget remind me via email to nick.wickens@twefs.co.uk

[Alan Riggs]

Thanks. We will be installing the software fresh and then replicating configuration files for the specific database(s). When we ran a test of the process in May, we used the ontape utility to generate and restore the backup. We had some issues with this, primarily speed and robustness: a media error on tape 4 required restarting teh process from tape 1--ouch. So, I was hoping that omniback could provide a more reliable media manager.

We don't have any problems with replicating the exact structure of logical volumes, though the VG configuration is different which means any solution requiring backup of the raw volumes directly will have to include repointing the restores.

On a side note: Does anybody have experience running Informix 9.20c1 under 11i? The Informix DBA from our partneer is now saying that Informix does not certify that version for use under 11i.

[Nick Wickens]

Hi again

I don't think you will see much difference with the recovery speed using Omniback/onbar against ontape - We found the recovery times to be roughly the same although with an autoloader, omniback will mount the tapes for you.

I would quite happily have stuck with ontape for our backup & recoveries but was forced down the onbar route by a manager who wanted to consolidate all system backups into one application - omniback. Omniback/onbar backups are far more complex and you are bound to have more issues (and hair loss) than with ontape.