Mixing Storage Managers with onbar

I was wondering if anyone had experience using onbar to back up a database with different Storage Managers for the same instance on the same day. For example I have a need to do a whole system backup using onbar and Veritas Netbackup. Then later in the day we need to perform a second backup using onbar with Informix Storage manager (ISM). The second backup is needed for DR purposes. The DR site does not have Veritas Netbackup. We would only be doing whole system backups and whole system restores. All restores would be a cold restore. My plan would be something like this: Veritas backup: 1. copy ixbar.veritas to ixbar file 2. backup using veritas 3. backup ixbar file 4. copy ixbar file to ixbar.veritas Later perform the ISM backup 1. copy ixbar.ism to ixbar file 2. backup using ISM 3. backup ixbar file 4. copy ixbar to ixbar.ism Is this feasible at all? Is there impact to sysutils and/or other Informix related objects? As long as we are doing whole system backups/restores is there any impact to logical logging? Would we have to change the onconfig file and therefore require a bounce? I do not want to do this but may have no choice. We are using IDS 7.31 under HP-UX 10.2 Any help/comments would be appreciated.

Hi, I have no experience with a scenario like this. I think it is quite unusual. There are some things that come to my mind: - I think you have to have both SMs listed in the versions file ( $INFORMIXDIR/etc/sm_versions ). Both I think will then be entered into the respective place in sysutils database. After that I think no more action is necessary with regard to this item. - to switch SMs onbar needs to switch the XBSA library. Usually you specify the XBSA lib path with parameter BAR_BSALIB_PATH in the onconfig file. So you have to change that to switch SMs. As this parameter is used only by onbar (and not oninit), a restart of the server is not necessary for this change to be effective for onbar. (However, you may want to avoid updating the onconfig file while the server also is updating it due to some server configuration change - which usually happen during execution of some "onmode" command or "onmonitor".) Alternatively you can specify a symbolic link for BAR_BSALIB_PATH in onconfig, and then change the link to point to the respective target. Both methods would have to be put into rigid procedures as it is easy to forget a step ... especially when doing some onbar backup "on the fly" ... - doing whole system backups only in this scenario is probably a good idea, because otherwise it is easy to get confused with which backup went to what SM. I.e. I would strictly avoid level-1 and level-2 backups as they always build on the last level-0 (or level-1) backup and the server doesn't know about SM switching ... - using ISM for the DR restore means that you will have to do "imported restore", which is a bit compilcated. You may want to test the procedure thoroughly ... Have you thought about alternatives ? I think in your version you could also do external backup (and then external restore) for the DR purposes ? This would avoid all the config issues and imported restore. And it could be faster than whole system backup/restore. Or you could use ontape backup/restore for DR purposes. As you are doing whole system backup/restore only, ontape operations (by default whole system and without parallelism) wouldn't be much slower ... ? Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management forum.subscriber@iiug.org wrote on 07.12.2005 05:43:26: > I was wondering if anyone had experience using onbar > to back up a database with different Storage Managers > for the same instance on the same day. For example > I have a need to do a whole system backup using onbar > and Veritas Netbackup. Then later in the day we need > to perform a second backup using onbar with Informix > Storage manager (ISM). The second backup is needed > for DR purposes. The DR site does not have Veritas > Netbackup. We would only be doing whole system > backups and whole system restores. All restores > would be a cold restore. > > My plan would be something like this: > Veritas backup: > 1. copy ixbar.veritas to ixbar file > 2. backup using veritas > 3. backup ixbar file > 4. copy ixbar file to ixbar.veritas > Later perform the ISM backup > 1. copy ixbar.ism to ixbar file > 2. backup using ISM > 3. backup ixbar file > 4. copy ixbar to ixbar.ism > > Is this feasible at all? Is there impact to sysutils > and/or other Informix related objects? As long as we > are doing whole system backups/restores is there any > impact to logical logging? Would we have to change > the onconfig file and therefore require a bounce? > > I do not want to do this but may have no choice. > We are using IDS 7.31 under HP-UX 10.2 > > Any help/comments would be appreciated.

I used ISM in the past and then switch to Omniback, I remember that I had to disable ISM (renaming all ISM config exe) to avoid conflict between the 2 Storage manager as ISM is based on Legato product. But beside that I do not see why it should not work as you are doing a cold backup. -----Original Message----- From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On Behalf Of DAVID FREE Sent: Tuesday, December 06, 2005 11:43 PM To: ids@iiug.org Subject: Mixing Storage Managers with onbar [6067] I was wondering if anyone had experience using onbar to back up a database with different Storage Managers for the same instance on the same day. For example I have a need to do a whole system backup using onbar and Veritas Netbackup. Then later in the day we need to perform a second backup using onbar with Informix Storage manager (ISM). The second backup is needed for DR purposes. The DR site does not have Veritas Netbackup. We would only be doing whole system backups and whole system restores. All restores would be a cold restore. My plan would be something like this: Veritas backup: 1. copy ixbar.veritas to ixbar file 2. backup using veritas 3. backup ixbar file 4. copy ixbar file to ixbar.veritas Later perform the ISM backup 1. copy ixbar.ism to ixbar file 2. backup using ISM 3. backup ixbar file 4. copy ixbar to ixbar.ism Is this feasible at all? Is there impact to sysutils and/or other Informix related objects? As long as we are doing whole system backups/restores is there any impact to logical logging? Would we have to change the onconfig file and therefore require a bounce? I do not want to do this but may have no choice. We are using IDS 7.31 under HP-UX 10.2 Any help/comments would be appreciated.

Why not just use ontape for DR purposes? Is there a time requirement because the db is too large? Bob Roussey -----Original Message----- From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On Behalf Of DAVID FREE Sent: Tuesday, December 06, 2005 11:43 PM To: ids@iiug.org Subject: Mixing Storage Managers with onbar [6067] I was wondering if anyone had experience using onbar to back up a database with different Storage Managers for the same instance on the same day. For example I have a need to do a whole system backup using onbar and Veritas Netbackup. Then later in the day we need to perform a second backup using onbar with Informix Storage manager (ISM). The second backup is needed for DR purposes. The DR site does not have Veritas Netbackup. We would only be doing whole system backups and whole system restores. All restores would be a cold restore. My plan would be something like this: Veritas backup: 1. copy ixbar.veritas to ixbar file 2. backup using veritas 3. backup ixbar file 4. copy ixbar file to ixbar.veritas Later perform the ISM backup 1. copy ixbar.ism to ixbar file 2. backup using ISM 3. backup ixbar file 4. copy ixbar to ixbar.ism Is this feasible at all? Is there impact to sysutils and/or other Informix related objects? As long as we are doing whole system backups/restores is there any impact to logical logging? Would we have to change the onconfig file and therefore require a bounce? I do not want to do this but may have no choice. We are using IDS 7.31 under HP-UX 10.2 Any help/comments would be appreciated.