Thomas

I'm not sure that you can actually do this. While from a high level
logical view, you might think that the steps that you are taking will
work; however, all BMR's that I have performed, especially in the
Windows environment, I would always restore back to a target machine
that has an identical name and I think that any Windows BMR
documentation would always allude to this also.

My guess is that you have a need to give the machine a different name
because you are restoring it on your live network. Obviously in a full
DR test or real DR, the original machine would not be visable and
therefore you can give the target machine for the restore, the actual
name.

For DR tests, I find it useful to have a dedicated DR restore VLAN. You
can then firewall/traffic filter this VLAN from your live prod VLANs.
You only need enable port 1500 outbound from the VLAN (or what ever port
you have configured for TSM data access). This enables you to give the
identical machine names to the servers you are restoring and also
ensures that when the restore is complete, they don't interfere with
your live prod servers.

Failing this, if you have a spare NIC in your TSM server, create a
restore LAN segment from this.


Leigh

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Thomas Denier
Sent: 24 January 2006 21:25
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] System object restore problem

We just went through a disaster recovery test, using the following
process
for each Windows 2000 system involved:

1.Give the replacement system a different computer name than its
production
counterpart.
2.Execute a 'rename node' command against the recreated TSM database to
change the node name matching the production computer name to a node
name
matching the replacement system computer name.
3.Execute 'rename filespace' commands to make the corresponding changes
to
computer names embedded in UNC volume names.
4.Restore the C drive.
5.Restore the system object.
6.Restore the remaining drives.

At step 5 the attempt to restore the system object finished almost
instantly, with no data movement. This was true whether the GUI or the
command line client was used. The 'query systemobject' claimed that
there
were no matching files. I called IBM and was told that a system object
cannot be restored to a system with a different computer name than the
system that backed up the system object. We were using 5.2.6.0 server
code
under mainframe Linux. We were, in most cases, installing 5.3.2.0 client
code on the replacement Windows systems (one Windows administrator tried
the 5.1.5.0 client code and got the same results). Some of the original
production systems had been running 5.3.2.0 client code, and some had
been
using lower client levels.

Several of the Windows administrators confirmed my recollection that the
process described above had been used successfully at our previous
disaster
recovery test 14 months earlier. We are then using 5.2.2.0 server code
and
a variety of 5.1 and 5.2 client code levels.

This raises a number of questions:

1.Why did our test recovery process stop working?
2.Is there any way to get the process to start working again?
3.Nearly every book or article about disaster recovery emphasizes the
  importance of testing. Why did Tivoli introduce a restriction that
  seems to have been designed to make disaster recovery testing
nearly impossible?