Disaster Recovery without DRM

[khurram]

hi,

I have a TSM 5.3 customer who wants to test Disaster Recovery of TSM without using DRM.

At main site they do have 3583 lib and 3581 Manual Autoloader.

Server OS on both site are AIX



Correct me if i am wrong with the following procedure:



1. Restore mksysb of Main Site TSM AIX server on DR site AIX server.

2. Recreate enough size DB volumes & recovery log volumes on DR site

3. Mirror them as they are at main site

4. Resotore latest volume history file ( from Main to DR site)





5. Place TSM DB tape Restore into 3581 & restore TSM database using restore db command



6. update primary site volume status to destroyed.



7.Clone any AIX client by restoring dsm.opt and then let the data restored from copy storege pool.



Questions:

1. Is the procedure seems ok

2. How can TSM will know that cartridge with TSM DB is now loaded into 3581 ( as the element addresses will be quite different )

does restore db command provide any parameter to specify volume ?



3. while restoring TSM db , TSM server should be running or stopped?



Thanks in advance

 

[Harry_Redl]

Hi,

as far as I understand your configuration

1) production site has 3583

2) DR site has 3581 (not on the prod. site, so not in the device config file)



I am not familiar with the AIX but these steps should work ...



1) install OS and TSM server



2) configure the TSM server to use the autoloader - drives, paths

3) define devclass using the autoloader (preferably the same name as devc used on the prod. site on 3583)

4) backup devconfig (to create devconfig file)





5) define db and rlog volumes with enough capacity (preferably the same as they were)

6) shut down the tsm server

7) get the volhistory file (not necessary - you can specify the volume name in dsmserv restore db command - see admin guide)

7a) update the devconfig file with the element number and the tape label with the DB



8 ) use the dsmserv restore db - the server is STOPPED



9) start the server

10) now I believe you have to redefine the drives again to use the 3581 (in the prod. DB it points to 3583)

11) checkin the volumes

12) update primary pool volumes to destroyed

13) ....



If anyone has a better solution, share





Hope it helps



Harry

 

[khurram]

Harry,

thanks for your reply.... It is 100% same as you described .... except the difference that i first checkin TSM DB cartridge into 3581 and then issue restore db command.



Infact you can use devclass and volume parameter with restore db command also



Now i have two questions in my mind :



How i can know exactly what are the sizes of db volumes & recovery log volumes at prod... because i have defined database expansion triggers.



Or just write an admin schedule to get these sizes .....



Also is there any way to not to get 3583lib defination when i issue restore db command.... it is cumbersome to delete this library defination and redefine 3581 for reuse.



Thanks!!

 

[Harry_Redl]

Hi,



1) your new db volumes do not need to be the same for the DB restore - they have to be big enough (the same for log)

So define the new volumes to your fresh server (before restoring the DB) - it will create the dsmserv.dsk file for you (which is used during the restore) and then restore db as usual

The DB is going to be loaded into new volumes ...





2) I do not see a way to avoid the library reconfiguration - the info is in the DB which you restore ... so after restore it becomes active



Hope it helps



Harry