Restoring Database to new HW Config

[mccleld]

The devconfig file you use during a DR is just enough to get your TSM Server to see a tape drive in order to perform a restore. Once your TSM Server is up and running after the DSMSERV RESTORE, it will remember its source drives/libraries/paths as they were at the time of the DB backup - if they're different in your DR site/hardware (very often the case) then you'll need to redefine them. As for DISK storage pool volumes - what's the purpose of the DR? If it's to perform recoveries for client systems that have also gone up in smoke, then you unless you're planning on pre-staging your client data from copy storage pool tape onto disk, their benefit is questionable. If the DR is just to protect the TSM Server instance itself so it can continue normal operations, then yeah run the macro that gets created by your recovery plan.

In my experience, I've found the initial DR of a TSM Server can sometimes be fiddly. BUT once you've got your DR server's drivers/devices/paths mapped, got your DB and LOG volumes pre-created and ready for restore and have a dormant TSM Server instance configured and waiting in the wings, that the second, third and (importantly, when you have to do it in the middle of the night) for real times are much more straight forward. I'd urge you, once you've successfully done it, to do it again straight away with your documentation.

</over>

____________________
/David Mc
London, UK

 

[hjeckman]

The devconfig file you use during a DR is just enough to get your TSM Server to see a tape drive in order to perform a restore. Once your TSM Server is up and running after the DSMSERV RESTORE, it will remember its source drives/libraries/paths as they were at the time of the DB backup - if they're different in your DR site/hardware (very often the case) then you'll need to redefine them. As for DISK storage pool volumes - what's the purpose of the DR? If it's to perform recoveries for client systems that have also gone up in smoke, then you unless you're planning on pre-staging your client data from copy storage pool tape onto disk, their benefit is questionable. If the DR is just to protect the TSM Server instance itself so it can continue normal operations, then yeah run the macro that gets created by your recovery plan.

In my experience, I've found the initial DR of a TSM Server can sometimes be fiddly. BUT once you've got your DR server's drivers/devices/paths mapped, got your DB and LOG volumes pre-created and ready for restore and have a dormant TSM Server instance configured and waiting in the wings, that the second, third and (importantly, when you have to do it in the middle of the night) for real times are much more straight forward. I'd urge you, once you've successfully done it, to do it again straight away with your documentation.

</over>

Yes, the dr test is mainly to make sure that if our main site burns to the ground or even if just a few machines are fried that we can restore the TSM server at the DR site and bring back the servers that were destroyed.
So... Is all I really need to do this the DB Backup, devcnfg, volhist, and dsmserv.opt?
I also have the copy pool tapes that are sent to the DR site daily and locked in a cabinet.
If there's anyway you can simplify this just a bit for me I'd appreciate it.
These drplan scripts are driving me nuts. I just went through each file and edited them to match drive letters, etc that I have at the DR site, but it seems like it's hanging now.
If the script doesn't work this time my next step is just to get the db restored and then??? Manually create all of the volumes and drives at the DR site and restore the client data to them? I'm not sure where to go next.

I hate to be a PITA, but I'd hate to have to get a consultant in here for something that shouldn't be as hard as it seems I'm making it.

Thanks!!!!

____________________
/David Mc
London, UK[/QUOTE]

 

[hjeckman]

So at this point was the restore of the DB/TSM Server successful? If so had you tried rebooting? The entry in the ISC may have been updated, or the instance removed and readded with the "updated" status.

We normally stay clear of the ICS as well...but theres a possiblity all devices (paths/drives) have to be remapped because the OS seems them different than the other OS did.

Yes, I can get the DB to restore, but then it goes looking for paths etc that don't exist on this server. I've edited the files in the DRPlan to account for this now, but it still wants the tape library from the other server. I haven't tried rebooting, but I've stopped and started the TSM services.
There's a point at the end of the process where you're supposed to wait until the server is started and then press enter to finish the recovery, when I do this, I get an error because MSVCR80.dll cannot be found. I'm trying to find where it is located on my production server to replace the missing file.
Not sure if any of this is even necessary, but it's the end of the day and this is my last attempt.
Hopefully there will be some replies overnight so I have some new info for the fresh start in the morning.

Thanks, again.

 

[mccleld]

"I hate to be a PITA, but I'd hate to have to get a consultant in here for something that shouldn't be as hard as it seems I'm making it."

Hey, I am a consultant - it's my job to make it all sound simple! But like I say, it sure can be a bit fiddly sometimes. Really, both the IBM docs (chapter 23 and 24 of the TSM admin guide) and especially your own documentation is your best friend here - especially in the heat of the moment when you're doing it for real, you really don't want to be trying to figure things out on the spot.

"So... Is all I really need to do this the DB Backup, devcnfg, volhist, and dsmserv.opt? ... These drplan scripts are driving me nuts. I just went through each file and edited them to match drive letters, etc that I have at the DR site, but it seems like it's hanging now."

Honestly, for the DR work I've done with a customer over the last couple of weeks, I haven't gone near the recovery plan once - just the devconfig.out, volhist.out and I like to have a copy of their dsmserv.opt file stashed away just in case there's anything hinky configured in there too. These, and a an inkling of what the original TSM Server instance would have looked like before it blew up. Obviously it depends upon your requirements, but if all you need to do is get your TSM Server up and running to restore some clients' data, then the above files, the admin guide and reference (at the back), your DB Backup and your copy pool tapes should be all you'll need.

_____________________________
/David Mc
London, UK

 

[dms19]

Honestly, for the DR work I've done with a customer over the last couple of weeks, I haven't gone near the recovery plan once - just the devconfig.out, volhist.out and I like to have a copy of their dsmserv.opt file stashed away just in case there's anything hinky configured in there too. These, and a an inkling of what the original TSM Server instance would have looked like before it blew up. Obviously it depends upon your requirements, but if all you need to do is get your TSM Server up and running to restore some clients' data, then the above files, the admin guide and reference (at the back), your DB Backup and your copy pool tapes should be all you'll need.

I agree. Ive done plenty of restores - some for PoC and others for production. I've never used a plan and have relied on the volhist, dbb and devconfig. Essentiall set up TSM in a fresh version - do the CLI restore, when its complete tweak paths/disk etc as necessary and move on.

Different hardware is of course an issue and making sure the proper/same levels (patches and all) are installed on the recovery server is important. This is why we normally have a database or copy on the share of revs/updates/patches we've done to the TSM servers (OS and Application alike). Keep trying and keep asking questions, we'll get it knocked out sooner or later.

 

[hjeckman]

Thanks guys.. I've been working on a firewall install today while I'm at the DR site (Got too much going on!) but I'm going to fire up TSM now and delete and readd the Server1 and start from scratch. I'll try putting volhist, devcnfg, and dsmserv in place and restore the DB. After that I'll configure the devices attached here and see what happens. I'll get the chapters you referenced up on my screen as well.
I'm guessing when I actually try to do a client restore is when I'll be prompted for copy tapes?

 

[dms19]

Thanks guys.. I've been working on a firewall install today while I'm at the DR site (Got too much going on!) but I'm going to fire up TSM now and delete and readd the Server1 and start from scratch. I'll try putting volhist, devcnfg, and dsmserv in place and restore the DB. After that I'll configure the devices attached here and see what happens. I'll get the chapters you referenced up on my screen as well.
I'm guessing when I actually try to do a client restore is when I'll be prompted for copy tapes?

Once you are running a recovered system TSM will refer to the db and volhist - so when you run a restore it will try to call for either the tape pool or copy pool take to mount (where ever the data was at the point of recovery).

 

[hjeckman]

Ok, DB is restored. TSM Was looking for my tape drive from the main site, so I deleted it and tried to define my tape drive that it's connected to at the DR site and got "ANR8744E DEFINE PATH: Current license terms do not permit this operation."
If I do a q license I can see that it's licensed for basic and extended edition, but says that the Server License Compliance FAILED.

Going into the Admin Command Line is also giving me the name of my prod server in the prompt rather than the name I configured for my DR server. Something seems goofy. I'm not sure if this is the expected result or not.

Tried to register the license file and it gave me "License Registration is not supported on this server"

 

[mccleld]

Like I said, your TSM Server instance will have one helluva headache after it's been through a DR :O)

You'll need to perform a REGISTER LIC on your new TSM Server if you don't have the nodelock file (where TSM Server keeps its licence information - rather than in its DB) synced with your DR TSM Server.
___________________
David McClelland
London, UK

 

[dms19]

Be sure you are taking step by step notes - this is (while frustrating) a GREAT way to document the DR process so in the event of a real disaster you have a manual to follow.

You'll learn twice as much TSM as you thought you knew working on projects like this!!

 

[hjeckman]

Like I said, your TSM Server instance will have one helluva headache after it's been through a DR :O)

You'll need to perform a REGISTER LIC on your new TSM Server if you don't have the nodelock file (where TSM Server keeps its licence information - rather than in its DB) synced with your DR TSM Server.
___________________
David McClelland
London, UK

That's the problem, it won't let me perform a REGISTER LIC... I keep getting "License Registration is not supported on this server" whenever I try to do it and it's not letting me add storage w/out the license.


DMS,
I'm taking all my notes. What a pain though, I keep having to go back and edit steps in the notes that I thought were good, but found out later I had to do something a different way to get it to work. UGH! I'm sure I'll appreciate it someday, though.

 

[mccleld]

That's the problem, it won't let me perform a REGISTER LIC... I keep getting "License Registration is not supported on this server" whenever I try to do it and it's not letting me add storage w/out the license.

Look here: http://www-01.ibm.com/support/docview.wss?uid=swg21177577 - you may need to verify your code/licenses package installation.

HTH,

___________________
David McClelland
London, UK

 

[hjeckman]

Wooohoo! That worked. I just copied the .dll from my prod server to the SERVER directory on my DR server and registered, it came right up!

 

[hjeckman]

Alright.. I've got everything up and running, but when I attempt to do a client restore I'm not prompted for the tape. I've been watching the activity log, but it seems to be requesting a tape that is NOT one of the copy pool tapes. I've updated TSM w/ the available tapes and the ones that arent available, but I'm kinda stumped here.

 

[dms19]

Any chance its looking for the DR tape volume and not the tape that would normally be onsite in the library?

In our DR exercises, we would recall tapes necessary to recover certain servers/apps from our offsite and have them on hand at the DR site.

 

[hjeckman]

It's looking for the tape that would normally be onsite in the library. I want to do a restore solely w/ the DR Tape volumes.

I would think it's cheating to use tapes that you would consider "unrecoverable" in a real DR event.

I think I screwed up by restoring my policy domain that I had backed up from my prod site. Will recovering a policy create storage pools, etc? I didn't think it would, but it seems to have

 

[dms19]

We would get the server restored and functional and check in the DR volumes we had and run the client restores off those.

Even if the restore of the PD created the stg pool, without volumes to populate it (disk or tape), it would be of little use.

 

[hjeckman]

We would get the server restored and functional and check in the DR volumes we had and run the client restores off those.

Even if the restore of the PD created the stg pool, without volumes to populate it (disk or tape), it would be of little use.

Well, Friday was my last day at the DR Site. Luckily I can do most of this remotely and I have a guy on site that can shove tapes into the library at my request.
I'm still not sure why when the tape it wanted wasn't available it didn't request the copy pool tape. Is there somewhere I need to set in TSM to restore client data from copy pool, rather than backup pool?

 

[dms19]

Did you say you restored and defined the primary pools and not the copy pools? Perhaps trying restoring/creating only the copy pool and check the tapes you have on hand for restores into that, with nothing checked into the primary pools?

 

[hjeckman]

I actually didn't define any pool, just the db, log, and library storage.
I guess when I did a restore of the policy it added the pools as well, because I didn't see them at all until then.
I'm going to do it over again and NOT install my exported policy, just set up the copy pool and see what happens.