ADSM-L

Re: System object restore problem

2006-01-25 11:29:53
Subject: Re: System object restore problem
From: "Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 25 Jan 2006 11:28:38 -0500
Can't you just boot the host in LOCAL mode, and not join the network
while the restore is in progress?
TSM just uses TCP/IP, doesn't care about Microsoft/Windows/Domain
authorization...

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Leigh Reed
Sent: Wednesday, January 25, 2006 4:54 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: System object restore problem


Thomas,

One other thing. You mention that you have actually managed to complete
this method successfully with 5.1.x.x and 5.2.x.x code. Bear in mind
that there were a number of bugs with the early levels of code regarding
the backup of W2K system objects. So while it may have worked for you,
there may have been underlying problems for others, which have
subsequently been solved, but unfortunately have scuppered your internal
DR procedures.

I really think that your only option is to build a dedicated restore LAN
segment and then use the original machine names for the Windows BMRs.


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?

<Prev in Thread] Current Thread [Next in Thread>