IDS Forum

RE: Onbar/TSM imported restore - log protection ?

Posted By: Stuart McCann
Date: Tuesday, 25 March 2008, at 9:08 p.m.

In Response To: Onbar/TSM imported restore - log protection ? (ROGERS PATTERSON)

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.
***************************************************************

Messages In This Thread

• Onbar/TSM imported restore - log protection ?
  ROGERS PATTERSON -- Thursday, 20 March 2008, at 2:52 p.m.
  • Re: Onbar/TSM imported restore - log protection ?
    NORMA JEAN SEBASTIAN -- Thursday, 20 March 2008, at 5:00 p.m.
    • Re: Onbar/TSM imported restore - log protection ?
      ROGERS PATTERSON -- Thursday, 20 March 2008, at 5:45 p.m.
      • Re: Onbar/TSM imported restore - log protection ?
        NORMA JEAN SEBASTIAN -- Thursday, 20 March 2008, at 6:08 p.m.
  • RE: Onbar/TSM imported restore - log protection ?
    Stuart McCann -- Tuesday, 25 March 2008, at 9:08 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.