Hey Jacob,
It sounds like you are trying to do a redirected restore.
I'll try and address some of your questions, but once you get a working restore, it will make a little more sense.
- Make sure your storage manager must support imported restores.
Well, obviously it does, because the DBA I replaced did imported restores. But lacking that vital information, just how in blazes would I determine what features my storage manager supports and which it does not? Or is this only in the ixbar and oncfg.<servername>.<servernum>? If the latter, anyone point me to documentation as to the meaning of all those columns?
As you say, it does support redirected restores because it's been done before, and veritas does allow redirected restores. In terms of features, that's a question for your veritas folks. You often have to treat it as a bit of a black box unless you have access to the veritas API.
- Make sure all the files/raw devices exist for the chunks.
Again, obviously they do here. But that begs the question: In an ontape recovery, it spits out a list of the chunks it will restore, like the chunks portion on "onstat -d" taken from the backup media. Is there any way to get onbar to produce such a useful list? This would be VERY helpful if the original server got destroyed.
The dbspaces that are needed will be those listed in the ixbar file. Also the $INFORMIXDIR/etc/oncfg_<INFORMIXSERVER>.<SERVERNUM> file may be useful. But you should be taking a list of the dbspaces and chunks from the prod server and storing them somewhere safe, just like you should be with other critical files, like onconfig, sqlhosts, LV information, etc...and ixbar of course. This is a recommended practice for any system as part of DR.
- Both the source and target computers must be on the same LAN or WAN..
This important question is more for the network experts: How do I determine this?
But also, WHY? I think I should be able to carry the backup media on a big drive in my pocket and walk it to the target server, LAN/WAN be D****d.
I don't know about this - you should be able to restore to any compatible server as long as netbackup is available.
- Identical hardware (binary compatible should be enough), identical OS release (familiar territory here).
- The same configuration and ROOTPATH information, although the server names and numbers can differ.
This is funny: Folks here are telling me I should recover the target server with same server name as the source, though I think that sow confusion in the sqlhosts file. It would seem easier to just leave the same server name and leave sqlhosts alone. Also, only the root device and logical log count really need to be identical. NETTYPE? LRU params? Do those really need to be the same? I doubt it.
Some things need to match, some things don't. For example, I seem to remember LOGSIZE must match.
- Identical storage-manager versions.
I suppose they are the same on both servers but how do I determine the version of storage manager (remember, Veritas in my case) on either host? And of the source were destroyed, how would I obtain the version that had been on that host?
Probably a question for the veritas admins. I bet that there's a handy command to run to display this. There is a file $INFORMIXDIR/etc/sm_versions that stores the version of the storage manager, but this is something that should already be set up. Still, make sure that it has the same value on the source and target systems.
- Compatible XBSA libraries
GAAAAAK!! How do I find that out? I'll be satisfied for the moment of just locating these libraries! I'll hazard guess that the library is the shared-object file specified by BAR_BSALIB_PATH. But how would I determine the release version of the library and if it is compatible? Again, how would I determine this from the backup media if the original server has gone POOF?
Yes, this would be the file referenced by BAR_BSALIB_PATH. The file that this points to should match on the source and target servers. If not then, who is to say whether they are compatible or not - apart from a veritas admin.
Now, for your redirected restore, there are a few things to do. It sounds like you are already connecting to some veritas server, or you wouldn't get the message about the rootdbs object not being backed up. It may not be the right one though - hard to say at this point.
You have already copied over the ixbar file. If you just want to restore the latest backup rather than an older generation, I normally delete everything above the last level 0 backup of the rootdbs. It makes it faster to process when the restore runs. Column #6 in the ixbar file shows a 0 for the Level 0. Rename this file to have the target SERVERNUM, e.g. ixbar.<SERVERNUM on target>
Copy over the $INFORMIXDIR/etc/oncfg_<INFORMIXSERVER>.<SERVERNUM> file to the target. Rename for the target INFORMIXSERVER and SERVERNUM
Look on the SOURCE system and check the environment for anything that says INFXBSA, e.g. env | grep INFXBSA. This could be a big clue if these environment variables are set. If not set in the environment, it's possible that they are set in any script that performs a backup. You may have something called INFXBSA_POLICY. This is a veritas thing. When doing a restore, you need to make sure that you are specifying the correct policy, or it won't be able to find the object. So, if you can find this on the source server, make sure you set it the same on the target, e.g. export INFXBSA_POLICY=XXX. There may be another policy for logical logs too, e.g. INFXBSA_LOGICAL_POLICY. If not set in the environment on the source server, then take a look at the script referenced by ALARMPROGRAM in the onconfig to see if there are any INFXBSA env variables set there.
While you may have limited visibility into veritas, there should be a file on the server called bp.conf. For one of our customers, it is in /usr/openv/netbackup/bp.conf. This has some information in it, including the name of the backup server. When you perform the redirected restore, you want to be able to access that same server, but also the server name is important as it will be used as an identifier when Informix requests the object from Veritas. So, if you can find that bp.conf file on the source system, you can run: grep "^CLIENT_NAME" bp.conf Hopefully you can get this info. Then, on the target system, run: export INFXBSA_CLIENT=<the client_name from bp.conf>
If the SERVERNUM of the source and target systems is different, then on the target, run: export IFX_SERVERNUM=<servernum of source system>
The onconfig file on the target system needs to have the ROOTPATH set to the same as the ROOTPATH value on the source system.
Once you have made these changes, then try a physical restore (onbar -r -p) and hope for the best.
Good luck!
Mike
------------------------------
Mike Walker
xDB Systems, Inc
www.xdbsystems.com------------------------------