Recovery of destroyed TSM server to another TSM server

[SRysh]

Need some help thinking thru a recovery scenario.



I have 2 TSM servers, ServerA and ServerB, and am using virtual volumes to store the copy pool from ServerA on ServerB and the DB backup of ServerA on ServerB and visa versa.



If ServerA is destroyed, and I am not able to get replacement hardware immediately, can I start a second instance of TSM server on ServerB, and restore ServerA's database to it, then restore client data using ServerA's copy storage pool (which is stored as a virtual volume on ServerB).

 

[chad_small]

Yes you can. The only thing you'll need to do is update the server definition on SERVERB to point to the new IP address SERVERA now has. Really should be easy. Are they sharing the same library? If so why do server-to-server virtual volumes?

 

[sgabriel62]

Srysh

Here is my confusion and my recommendation to your thought pattern.

To cross-platform your pools and DB - in a way makes sense - but will become a storage and recovery nightmare if you are not careful.

I can see virtual volumes for the TSM DB portion of your thought pattern but not for the copy pools - unless you have a dedicated SAN array that has the space available to receive copy pool data.

If the latter is true - then I would recommend a STBY TSM server - this could be your second TSM instance or a separate server. Your naming convention of your copy pool virtual volume should be simplistic rather than default - this means manual intervention.

Your STBY TSM server needs to have the 5 vitals upto date 100% of the time. Then and only then are you ready.

Good luck - sounds like you're attempting a true virtual environment - completely doable.

Keep us upto date on your progress for our other interested readers.



Steven

 

[SRysh]

Thanks for the input, here's some more info.



The copy pools will be on tape, not disk, (so no need for SAN array) and the servers are at 2 different locations (across a WAN).



What is an STBY TSM server and the 5 vitals?



I thought more about the recovery situation. In a disaster, if I recovered ServerA's database to a second instance of TSM on ServerB, shouldn't the restored ServerA's database know about its copy pool which exists as a virtual volume on ServerB, and thus when I issue a restore from a client of ServerA, TSM should look to the copy pool for restores? So I really shouldn't need to restore ServerA's primary pool if all I want to do is recover client data.

 

[SRysh]

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>Yes you can. The only thing you'll need to do is update the server definition on SERVERB to point to the new IP address SERVERA now has. Really should be easy. Are they sharing the same library? If so why do server-to-server virtual volumes? </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>



Chad, when you say update the server definition on ServerB to point to the new IP address on ServerA do you mean with the DEFINE SERVER command? Since ServerA's IP address is now the same as ServerB, will this cause a problem, or do I need to have multiple nics?



The reason for server-to-server is because the servers are across a WAN, so they are not sharing the same library.



Thanks again for the input

 

[sgabriel62]

dsmserv.dsk

dsmserv.opt

devconfg

volhist

Recovery plan



A TSM STBY server is a server in "Hot Mode" where the TSM Databases are synchronized between servers.



You should be OK as long as the DR plan has all the necessities.

Syncronization cross the WAN is dependent on your bandwidth.



Here's are some thoughts

- Synchronize your TSM DB between servers. If you are going virtual over the WAN - synchronization is better.

-Simulataneously write to two copy pools. Where one is going to your offsite location.

Again dependent on bandwith and library drives and available media.



As long as your DR plan has your recovery steps in sequence - you should be fine.

Keep in mind - the TSM receiver - needs to have the space available to receive these virtual volumes. If you have a tape library at the other end waiting - consider migrating from the virtual volume to the tape library on the active server in one sequence of events.

Obviously you will have to test every one of our theories and choose which one you feel more comfortable with.



good luck





-Simultaneous writes between copy pools - where

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>Thanks for the input, here's some more info.



The copy pools will be on tape, not disk, (so no need for SAN array) and the servers are at 2 different locations (across a WAN).



What is an STBY TSM server and the 5 vitals?



I thought more about the recovery situation. In a disaster, if I recovered ServerA's database to a second instance of TSM on ServerB, shouldn't the restored ServerA's database know about its copy pool which exists as a virtual volume on ServerB, and thus when I issue a restore from a client of ServerA, TSM should look to the copy pool for restores? So I really shouldn't need to restore ServerA's primary pool if all I want to do is recover client data.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>

 

[SRysh]

Server B is going to be an active TSM server for the clients on its LAN. ServerA is an active TSM server for the clients on its LAN. When you say to set up a TSM STBY (standby?) server can this be a second intance of the TSM server running on the same box? Can you point me to some documentation on TSM STBY server and syncronization the databases?