OnBar restore problem

I recently backed up an Informix database using OnBar and restored it over another database on a separate machine (changed names appropriately, and all that). Everything seemed to work except one chunk in a single chunk dataspace failed to restore. There were no messages in /tmp/bar_act.log referencing the dataspace, so it appears that OnBar did not even TRY to restore it. The only thing different about that space was that it was used by a database (there are two in the instance, not counting sysmaster & sysutils) that had no tables defined. Has anyone seen similar problem? TIA Doug Agnew DBA Charlotte Pipe & Foundry dagnew@charlottepipe.com (All the usual disclaimers, etc)

Doug, I recently had an experience with an OnBar restore that sounds something like your problem. During a cold restore, OnBar kept trying to restore a dbspace that I had not backed up. Out of frustration, I reinitialized the instance, and when I tried the restore again, I got a message in the bar_act.log that OnBar couldn't figure out what to restore. Turns out there is a file in $INFORMIXDIR/etc called "ixbar.servernum" (servernum is in the onconfig file), which is one of the (or the only) file Informix refers to as an "emergency boot file". Among other things, this file contains information about dbspaces, and OnBar apparently uses this file to determine out what to restore. When I reinitialized, Informix renamed this file (to something like ixbar.servernum.date.time) and created a new, empty ixbar.servernum file. I believe this is why I got the message about OnBar not being able to figure out what to restore. However, when I renamed this file back to ixbar.servernum, and edited it (using vi, it's a text file) to remove the dbspace for which I had no backup, the restore was successful. It appears that each dbspace to be restored must exist in the ixbar.servernum file. Try comparing each of these files for the two instances. If the files are different, and one instance is supposed to be a mirror image of the other, try copying the ixbar.servernum from your source machine to your destination machine. Note that the infrastructure (dbspaces and chunks) of both machines must be the same in order for this technique to work. The usual caveats apply. Make a copy of the existing ixbar.servernum before you overwrite it with another one. Let me know how you make out. HTH, Milton Doug Agnew wrote: > I recently backed up an Informix database using OnBar and restored it over > another database on a separate machine (changed names appropriately, and all > that). Everything seemed to work except one chunk in a single chunk > dataspace failed to restore. There were no messages in /tmp/bar_act.log > referencing the dataspace, so it appears that OnBar did not even TRY to > restore it. The only thing different about that space was that it was used > by a database (there are two in the instance, not counting sysmaster & > sysutils) that had no tables defined. > > Has anyone seen similar problem? > > TIA > > Doug Agnew > DBA > Charlotte Pipe & Foundry > dagnew@charlottepipe.com > > (All the usual disclaimers, etc)

Milton, Thanks for the reply. I was using the ixbar.0 file from my original machine (with the missing dbspace listed). After the first restore failed, I tried again, and it worked. It appears there is another file that is used (oncfg. something or other) that is built when the instance is started. Probably acts like an emergency version of the first two chunks of rootdbs (my guess). Anyway, I couldn't do the cold restore without it, and onbar did not like the file from my source machine. So I simply cp'ed the file from the destination machine's existing instance (which does not have the dbspace). My guess is that the original list of dbspaces comes from there, and then onbar searches ixbar.0 to determine what backup to use. After I had the first restore done and started Informix, the file was re-created with all the dbspaces, so when I tried to restore again, Informix 'knew' to restore the missing dbspace and all was handled ok. Doug Milton J. Vidrine, Jr. wrote in message <36FF8C00.25139812@hal-pc.org>... >Doug, I recently had an experience with an OnBar restore that sounds something >like your problem. > >During a cold restore, OnBar kept trying to restore a dbspace that I had not >backed up. Out of frustration, I reinitialized the instance, and when I tried >the restore again, I got a message in the bar_act.log that OnBar couldn't figure >out what to restore. > >Turns out there is a file in $INFORMIXDIR/etc called "ixbar.servernum" >(servernum is in the onconfig file), which is one of the (or the only) file >Informix refers to as an "emergency boot file". Among other things, this file >contains information about dbspaces, and OnBar apparently uses this file to >determine out what to restore. When I reinitialized, Informix renamed this file >(to something like ixbar.servernum.date.time) and created a new, empty >ixbar.servernum file. I believe this is why I got the message about OnBar not >being able to figure out what to restore. > >However, when I renamed this file back to ixbar.servernum, and edited it (using >vi, it's a text file) to remove the dbspace for which I had no backup, the >restore was successful. It appears that each dbspace to be restored must exist >in the ixbar.servernum file. Try comparing each of these files for the two >instances. If the files are different, and one instance is supposed to be a >mirror image of the other, try copying the ixbar.servernum from your source >machine to your destination machine. Note that the infrastructure (dbspaces and >chunks) of both machines must be the same in order for this technique to work. > >The usual caveats apply. Make a copy of the existing ixbar.servernum before you >overwrite it with another one. Let me know how you make out. > >HTH, >Milton > >Doug Agnew wrote: > >> I recently backed up an Informix database using OnBar and restored it over >> another database on a separate machine (changed names appropriately, and all >> that). Everything seemed to work except one chunk in a single chunk >> dataspace failed to restore. There were no messages in /tmp/bar_act.log >> referencing the dataspace, so it appears that OnBar did not even TRY to >> restore it. The only thing different about that space was that it was used >> by a database (there are two in the instance, not counting sysmaster & >> sysutils) that had no tables defined. >> >> Has anyone seen similar problem? >> >> TIA >> >> Doug Agnew >> DBA >> Charlotte Pipe & Foundry >> dagnew@charlottepipe.com >> >> (All the usual disclaimers, etc) > > >