Disaster Recovery: Rebuilding a TSM server on a different machine/configuration

[MarcBouchard]

Hi everybody,



I'm working on our disaster recovery plan and I'm having a problem with this... Here's the situation.



Building "A" - Production site

---------------------------------

TSM Server on an x345 machine, with 400GB storage pool and a 3583 library.



Building "B" - Recovery site

-------------------------------

TSM Server in vmware , with 20GB storage pool and a single LTO2 drive.



As you can see, very different environments. VMWare is not a problem as I got TSM running A1 inside it. My problem is this.



I rebuilt the TSM server in vmware, configured the single drive and the storage pool/database files etc. Everything works.



Now, let's say building "A" is no longer available and I have to recover data in Building "B". I recovered the database using our last db backup, that worked fine as well. BUT. it reconfigured the system (pools, etc...) exactly like the original location. Nothing works as I dont have enough space for the stg pools, not the same type of library etc...



How do I go about restoring "only" the tape infos so I can do data restores afterwards? I basically need to import the tape contents only, not the entire config.



Thanks a lot for your help!



Marc

 

[n9kws]

Because it does not work that way......



A DB restore is everything, execpt the info in the devconfig.dsm, dsmsrv.dsm, dsmserv.opt, and volhist.dsm. All of which are read only at start up time. You cannot selectively restore the volume information from the DB.



However, there is a solution to your problems and it has to do with cross-server communication. By having your copypools on the remote server, you can recover easier. In this config, you have the copypools for A on TSM server B, and vice-versa. In a DR situation, you still have to recover the failed server and restablih communicaiton with the remote, but that should be easy enoungh for an experienced admin.



Be aware that the server which hosts the copypools of the remote server cannot touch the data of the remote server, becasue it appears to the hosting server as a image backup. Only the server that put the data on the remote server knows how to get the files out of the volumes.



Be aware that this configuration requres a sizeable data connection between the TSM servers, as the volume of data crossing the wire could be massive (YMMV). But TSM is designed to do stuff like this.



Repost if you have more questions,

Andy.

 

[MarcBouchard]

Thanks for the quick response...



but that's no good for me... What I basically need to know is how to restore from bare metal on a machine that has a different configuration... Are you telling me this is impossible? I understand the method I am using is great for recovering on the same machine if it ever crashed badly enough to not restart. But if this hardware is no longer available, how do I recover elsewhere?



We can't afford to buy another library to have it sit there in case something happens



As for the replication/remote pools method, that's not something I can consider, because of storage and bandwidth issues.



Thanks,



Marc

 

[blagrange]

You can always just reconfigue the layout. If the tape pool is the same media etc. Just destroy the disk pool and revover from your copy pool.



Not sure if this is what you are asking?

 

[heada]

After you restore the database, you mark all the primary pools (and volumes within those pools) as destroyed. You then reconfigure the tape systems (drive, library, etc) and restore from the copypools.



For on-going life in the DR setting (going to running from there for a period of time) you'll need to recreate some primary pools (disk, tape, etc) so that you can backup the clients and TSM DB and move back to your new home (rebuild old server or build a new server) Basically, do the same procedure again (restore DB, mark primary as destroyed and restore from copy)



restore DB

startup server (I startup with a "runfile={script} to do the rest of the steps)

mark all primary volumes destroyed

mark all primary pools unavailable

redefine library

redefine devclass (if different, but shouldn't be)

redefine drive

redefine paths

restore client data



-Aaron

 

[n9kws]

Arron is in the right track, in a DR situation you can restore the DB then reconfig it for the alternate hardware. Review the other posts in the thread for additional details.



Andy.

 

[MarcBouchard]

Thanks a lot Aaron for the info. The end result is what I wanted to achieve... I was hoping there was an easier way (of course) but your summary of the steps helped me figure it out.



I've marked all my tapes as destroyed, deleted my old disk pools, now i'm left with 2 pools. My tape pool full of destroyed tapes and my copypool with my offsite tapes. Is there a way to remove the tape pool or flush everything since they are all "destroyed"?



Also, my web interface isnt working since I restored the database. Any reason for that?



Thanks,



Marc

 

[heada]

I don't know about the web interface, but you may want to check the dsmserv.opt for port settings or the like. Normally the server will say it is starting the web interface when it first starts up so you may want to start the server in the forground to make sure it is. (This is TSM 5.2 or below, right? 5.3 doesn't have the web interface anymore)



As for deleting the destroyed volumes, don't. If you delete the primary copy of a file (which you would do if you delete the volume) then the copy is also deleted.



-Aaron