Onbar/TSM imported restore - log protection ?

IDS v10.0.fc8 Aix 5.3 TSM 5.2.1 We are doing, if I understand the terminology correctly, an imported restore, of our production machine to another machine. The purpose of which is to validate our backups and sometimes to extract databases. We’ve done this with ONTAPE for many years but are now moving to using ONBAR with TSM. It appears that we need to create a node on the target server that has the same name as the source server in the DSM.SYS file. And that works. However, it also appears that we are putting the TSM backup data from the source instance at risk by potentially performing a log backup or dbspace backup from the target server that would be recorded as coming from the source server, since the node/instance names are now the same. In other words, a logical log backup from the target would overlay the backup file of a logical log from the source instance thereby destroying any PIT recovery option. We have considered insuring that only a bogus alarm program exists on the target server so no real LL backups would occur and writing a “wrapper” for the ONBAR command to not allow any backup operations, only restores. But the problem with these solutions is what if these are undone somehow and we unknowingly corrupt our production backups files only to find out in a crisis we are unrecoverable. So, what are we missing or doing wrong? Thanks Rogers

How much visibility do you have to your TSM environment? Meaning, can you see the exact image name it wants to back up when it is doing an onbar log backup? I ask because I have recently had similar struggles and concerns with DB2 and Netbackup (Informix and Netbackup works like a charm!). Because of my Netbackup settings/policies/clients, I actually don't have to worry about the target server on a DB restore issuing a log backup that could overwrite the source system log backup (hope that made sense). This is because the client and policy settings in Netbackup distinguish between the databases/database instances. So on my target server, the log backup after restore attempts to use some of the source settings but this confuses the DB2/Netbackup relationship and eventually the DB2 log backup fails (and my restore completes successfully).... and i am able to get back to business ... that being the business of setting the target server Netbackup/DB2 relationship to the proper settings for the target. I hope that made some sense :) Hopefully you have detail visibility to your TSM environment and can see those types of details. Norma Jean

Something akin to wearing sunglasses on a foggy moonless night. I can see in the IXBAR.{servernum} file the unique object ID created for the file, but it appears in our testing that if the IXBAR file is not current during a restore the process can still determine the log files belonging to that instance. I believe it is doing that by combining node/servernum/log#. That belief along with a recovery failure we had in testing lead us to the conclusion we could be creating problems by allowing the imported restore instance to backup objects.

i think you should be copying your source ixbar to your restore target, but it depends on the type of restore you are doing.. and that's another topic. can you ping your TSM admin to get some detailed help? I don't know TSM, but i know enough about netbackup and i can see my netbackup setup... for example, there is a client (i.e. system where DB is attempting to issue backup), a policy, a schedule, an owner, a group.... and of course the "filelist" or image being backed up. an example of my backup image is: /DB2/PRD/LOGFILE/node0000/db2prd/C0000000_S0047889.LOG where PRD= the DB issuing the log backup and db2prd is the DB2 instance owner. when i was doing this with informix, i didn't have such a long name (i was working with raw devices (not sure if that played in)) the log backup images would simply be the Informix log number, i.e. in the above example it would have been 47889. HOWEVER, the netbackup policy, client, schedule, etc. helped netbackup understand the difference between DB X's log backups and DB Y's log backups so there was no overwriting. I don't know TSM, but i think if you have a TSM admin... it would give you comfort to work with him/her and see what they are seeing during the DB log backup process and during the restore process. when you do your restore, do you have to change some TSM configuration files on your target server and/or target $INFORMIXDIR and/or user home dir? this could be evidence that you are changing settings enough so TSM will clearly distinguish between source-DB logs and target-DB logs.

You should be able to rename the DBSERVERNAME Name and or SERVERNUM to something else during the import restore. To do this you need to copy the source ixbar to the target host and change the sourceDBServerName ( column 1 in ixbar file ), also rename the ixbar file to ixbar.SERVERNUM and copy the source oncfg_SourceServerName.SourceServernum to target $INFORMIXDIR/etc/ oncfg_TargetServerName.TargetServernum. Your chunk paths will need to match those of the source unless you create a chunk remap file and use onbar -r -rename -f rempaFile. Stuart McCann Integrated Spatial Services Unit Information Communication & Technology Department of Lands, Bathurst Phone: (02) 63328285 stuart.mccann@lands.nsw.gov.au -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of ROGERS PATTERSON Sent: Friday, 21 March 2008 5:52 AM To: ids@iiug.org Subject: Onbar/TSM imported restore - log protection ? [11684] IDS v10.0.fc8 Aix 5.3 TSM 5.2.1 We are doing, if I understand the terminology correctly, an imported restore, of our production machine to another machine. The purpose of which is to validate our backups and sometimes to extract databases. We've done this with ONTAPE for many years but are now moving to using ONBAR with TSM. It appears that we need to create a node on the target server that has the same name as the source server in the DSM.SYS file. And that works. However, it also appears that we are putting the TSM backup data from the source instance at risk by potentially performing a log backup or dbspace backup from the target server that would be recorded as coming from the source server, since the node/instance names are now the same. In other words, a logical log backup from the target would overlay the backup file of a logical log from the source instance thereby destroying any PIT recovery option. We have considered insuring that only a bogus alarm program exists on the target server so no real LL backups would occur and writing a "wrapper" for the ONBAR command to not allow any backup operations, only restores. But the problem with these solutions is what if these are undone somehow and we unknowingly corrupt our production backups files only to find out in a crisis we are unrecoverable. So, what are we missing or doing wrong? Thanks Rogers ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum. *************************************************************** This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Department of Lands. This email message has been swept by MIMEsweeper for the presence of computer viruses. ***************************************************************