TSM DB restore on a new server

[epeterson]

Hi there. I am attempting to test an upgrade from v5.5 to v6.2. I would like to be able to restore the production DB onto this new server. I was thinking about doing a DR kind of scenario where I use my DR TSM server (it has copies of our PROD database) to restore from. We do this during DR tests - I fire up a second instance of TSM on my DR server then restore the prod db from dr. This works perfect, but in this case we are on a dedicated network and the new "prod" server that gets restored still maintains the prod name and such.

Can I restore my prod DB (from the DR server) onto a test server, and have it renamed so as not to blow up my prod system?

Any other thoughts as to how I might do this?

Our TSM database is huge (475GB) and I can't afford days of downtime to extract the v5.5 database and import to another server, so I want a duplicate to play with.

Any thoughts or advice would be greatly appreciated.

Thanks

 

[terlisimo]

If your test system has a different IP address there should be no problems... TSM doesn't advertise itself on the network so the production server and its clients shouldn't be aware that it exists.

Did I get this right? You have physical server A which is primary, physical server B which is used for DR and also has a second instance which is used for tests?

If your primary server uses your DR server for virtual volumes or as a target of some other server-to-server operations you may wish to stop your DR instance before starting the restored instance so it doesn't corrupt volumes for server B.

Maybe the best way would be to backup server A, then change TCPIP port on server B to a new one, reconfigure server A so it uses the new port and then restore primary DB in a new instance... so if the restored instance tries contacting server B it will fail because it will use the old port.

If you're running Linux you could take extra precautions by limiting connections to the DR instance from localhost using IPTABLES.

Did this make any sense?

 

[epeterson]

Wow, reading all of this makes my head hurt! It sure is convoluted. To try to clear it up...

Our DR server (B) is used for virtual volumes from A (database backup). I have a second instance built (not used) on B. During our tests, I have a devconifig.out and volhist.out files from A that I modify a bit, then I restore the full database backup from B into the "test A". B must be up and running of course to feed the restore request. Works perfect. All the test, however, occur on a dedicated network - we split from prod to test DR for obvious reasons - so there is no chance of confilict with the real A.

Now, what I want to do is introduce a brand new server C with TSM 6.2. I want (need) to test the db upgrade from 5.5, but of course that means A must be down for that period of time - not cool. So I thought maybe I could configure C to talk to B for a restore. C would have to pretend it is A, and that is where my concern comes in.

Now that I think about it, that's messy too. I will have to build C as a TSM 5.5 server, do the restore, then the upgrade in place on that server. I really wanted to be able to move to a net new 6.2 server. I guess that means I need a 4th server - restore A from B onto D (new temp 5.5), then upgrade to C (6.2). Yuck.

This is all on AIX, by the way.

Thanks again.

 

[terlisimo]

I see how upgrade may become a problem with such a large DB.

So I thought maybe I could configure C to talk to B for a restore. C would have to pretend it is A, and that is where my concern comes in.

The smart thing to do would be to back up B's DB and set all volumes to readonly while this is happening just in case C tries to change something while pretending it's A. During that time the real A should be disconnected from B meaning you'll have degraded DR capabilities. I think this is inevitable during an upgrade.

Once your restore is complete, disconnect C from B and do a restore DB on server B... just because you set the volumes to readonly doesn't mean C didn't change anything in the DB. The alternative to restoring the DB to a previous state would be to do AUDIT on server A for all virtual volumes located on server B. This could possibly take longer than just restoring the DB.


Alternative approaches... if your environment is not too complex, maybe you could just set up the new "clean" 6.2 server and then gradually move nodes and their data from the old server to the new one using EXPORT NODE commands? This may get a bit complicated if you're using tape libraries which would need to be set up in a shared mode so both the old and the new servers can use them simultaneously.

This way you wouldn't have reduced DR capabilities during the transition, if you can afford the extra disk space (if a node has, for example, 10TB of data then at some point both servers will have a copy of all node data so that means 2x disk space per migrated node).

And then there's the "hybrid" migration method which uses a combination of extract/insert of DB along with EXPORT commands... described here:

http://www.ibm.com/developerworks/w...ger+Version+6+Hybrid+Upgrade+Migration+Method

It's not officially supported or recommended but it seems logical to me... and the benefit is that you can tinker with the new server without shutting down the old one.

 

[jrf0114]

AIX to Linux Red Hat

I am in a simliar circumstance. One other thing I have added to the mix is I am going from an AIX server to a Linux server and have not located any specific things I need to watch out for. Any hints/tips? Thank you in advance.

 

[epeterson]

I am still working through my scenario, and I am hardly an expert (obviously!) but you cannot upgrade from dissimilar platforms (ie AIX to Linux). This is from the TSM v6 upgrade guide:

Restriction: You cannot upgrade your server to run on an operating system
that is different from the operating system it currently runs on. For example,
you cannot upgrade a server running on an AIX system to a server running on
a Linux system.

 

[jrf0114]

That is exactly what I had read. So since I can not upgrade from AIX to Linux, what is my option for getting the data from the AIX platform to the Linux platform, then perform the update once I get the data where I want it to be. There must be someway to do this, without the need to recreate all the source data. I too am not an expert, so any direction is appreciated. Thank you

 

[tariq.kaifi]

Very old post. Let's see if this helps you. Tried to search IBM documentation, but seems there isn't any. Hope someone else can find out.

http://adsm.org/forum/showthread.ph...IX-operating-System-to-Linux-Operating-System

 

[jrf0114]

Thank you, that at least gives me a place to start. I will document and anything that does not function as planned. I would like to be able to share the knowledge. Thanks again.