First time on DR testing

[aixuser]

Hello All,



I'm currently compiling my procedure on how to restore our TSM server to our DR SITE.

My problem is I only have bits and pieces on how to restore our TSM server. Does anyone have steps that I could follow? I just need a road map on how to restore our TSM server.



I guess I can start at restoring the MKSYSB.



Thanks,

aixuser

 

[heada]

mksysb is helpful, but not needed. The DRM Prepare will gather alot of the data needed to recreate your TSM server for you, but I do it by hand (not everything is needed)



This you will need:



volhist file

devconfig file

size of DB

dsmserv.opt



Start off by installing TSM from the lpps (or restore your mksysb) Verify that all the devices/devclasses you need backed up your DB with are listed in your devconfig file. If needed, update them with new paths (rmt devices) Define your DB vols/Log vols (use RAW LVs as then you don't have to format them and they're fast) I always define my volumes a little larger than needed so that I know it wont fail on the restore. Next, examine your volhist to find the latest DBBackup. Restore that DBBackup.(dsmserv restoredb devclass={devclass} volume={vol} commit=yes) After the database is restored, you'll need to mark all the primary pool volumes as destroyed and the primary pools as unavailable. Mark the copy pool volumes as readonly and disable all schedules (expire inv is BAD at this point) Verify all paths to devices are updated and online...and start the client data restore.



-Aaron

 

[aixuser]

Thanks for a great the great advice. One more question i have or may have a problem is my ATL. Here at work we use SERIAL connection to the ATL, but at the DR site IBM will provide us with an ATL that uses An IP ADDRESS. Do I have to make any changes in the DEVCONFIG file or will the TSM server overwrite the devconfig file?



Thanks

aixuser

 

[heada]

Depending on the ATL. If it is a 3494, then you'll need to change the ibmatl.conf (part of atldd) file in /etc and redefine the control point (/dev/lmcp0) If it is something other than a 3494, then you'll have to find it's config file.



-Aaron

 

[nbs03]

aixu,

You may also want to review and run the TSM "PREPARE" command which will create a file containing the commands and parameters to restore your system. After you run the command, create the individual scripts with awk and then review each to see how they work together.

Also review the recovery instructions in the TSM manual but remember that you do NOT have to fully recover the disk pools unless you want to. You can start recovering client servers direct from tape after the TSM server recognizes the copy pool volumes are in the library. If you have several small clients to recover and their data is intermixed on several tapes, you might be better off by restoring a disk pool to allow simultaneous client access to data for restore. The key is remembering that tape allows single, serial access while disk allows multiple simultaneous access.

Cheers,

Neil

 

[aixuser]

Thank you both for the great advices...

 

[jordan]

Hi,

I am going to perform a DR test soon. my qestion is as follow.

after installing the OS and TSM I need to format tsm volumes to be able to restore volumes.

this process takes a long time. what is the best way to reformat (recreate) tsm volumes before the restore. Heada worte the following, Can you please explain.



" (use RAW LVs as then you don't have to format them and they're fast) "



thanks,



Jordan

 

[heada]

I was refering to the database and recovery log volumes that must be created for formated for TSM to restore it's database into.



TSM can use a file (/usr/tivoli/tsm/server/bin/db001.dsm) or a raw logical volume. If you use a file, you must use the dsmfmt command to create and format that volume. Depending on the size and count of your volumes, this can take considerable time. If you use a RAW LV (a logical volume without a filesystem) then TSM will format the volume MUCH faster (10GB LV in just a few minutes) TSM can also use direct I/O and/or async I/O to access the RAW LV so performance is not lost.



TSM can use the same process for disk-based pool volumes as well, but that was not what I was describing when I suggested using RAW LVs.



the difference in commands is this:



dsmfmt -g -db /{filesystem}/{dbvol} 10 (process takes 30 to 90 minutes)

dsmfmt -g -db /dev/r{lv_name} 10 (process takes 5 to 10 minutes)



There is another option... you can create the file via dsmfmt (if using files) and just copy it.



-Aaron

 

[drax]

Alternately you could only specify one of several log files and that should get things up and running quicker. Then add the other volumes in later once TSM is up.



Il experience a delay with raw logical volumes but it's not enough to worry about in my case.