1. Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING) Click the link to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This message will disappear after you have made at least 12 posts. Thank you for your cooperation.

Disaster recovery - two sites

Discussion in 'BCP / DRP' started by ljoobo, Mar 17, 2009.

  1. ljoobo

    ljoobo New Member

    Joined:
    Mar 10, 2009
    Messages:
    8
    Likes Received:
    0
    Hi all,
    what is the best way to achieve two-way disaster recovery between two TSM servers in two sites? One idea is electronic vaulting of TSM DB and some critical data over thin IP link and offsite tapes for the rest.
    One way is using virtual volumes. What about mirroring DB & log over distance?
    Can you help me with these and maybe some other options?
    Thanx for any suggestions/advice
     
  2.  
  3. Eldoraan

    Eldoraan Senior Member

    Joined:
    Feb 19, 2003
    Messages:
    288
    Likes Received:
    10
    Occupation:
    Data Protection
    Location:
    Charlotte, NC
    If you're talking about internal TSM db/log mirroring - don't do that over a WAN type link. Too much lag will be tough to keep copies in sync.

    We use the unsupported config of SRDF on EMC storage to replicate our db/logs to remote site. It works pretty well but IBM will not support us if we have trouble.
     
  4. heada

    heada Moderator

    Joined:
    Sep 23, 2002
    Messages:
    2,560
    Likes Received:
    168
    Occupation:
    Storage Administrator
    Location:
    Indiana
    Remote vaulting of the TSM DB Backup with server-to-server over the IP link is your easiest and most supported option. That gets the database to the remote location, you still need to do the copy pool volumes. You can do that also with remote vaulting but make sure your pipe if big enough to handle that (your nightly backup volume over the WAN might be too much)

    -Aaron
     
  5. GregE

    GregE Senior Member

    Joined:
    May 12, 2006
    Messages:
    2,100
    Likes Received:
    31
    I'm looking at the same things sometime in the next few months. What does IBM support if not that?

    Right now we have a single TSM server. What we will probably have (options are still not definite) is a hot standby server at the DR data center. This server will not normally take any backups and will be the same name as the primary in the event of DR or DR testing, so server-to-server is out of the question.

    I like the option of replicating not only the DB, but also the logs, with SRDF. Getting the logs will allow a great recovery point objective. Have you tested recovery at your DR site with that setup?
     
  6. Eldoraan

    Eldoraan Senior Member

    Joined:
    Feb 19, 2003
    Messages:
    288
    Likes Received:
    10
    Occupation:
    Data Protection
    Location:
    Charlotte, NC
    As for what IBM will support, in the 5.x and earlier versions, no method of replicating db/log as far as I know. We've basically designed our DR environment to fire up the offline replicas after an SRDF split. If they don't come up, we use DR Plan file and do tape restore. So far, all of our DR tests of the SRDF replicated db/logs has been successful. We are running in syncronous mode, not sure what async would do to replication since you could get a snap while transactions are being committed. We've been running this way for about 5 years and so far it's worked through 5.1 to 5.4. Haven't moved our AIX servers past that since new direction is NBU and TSM will eventually become legacy platform.... unless NBU blows up and we have to reverse!
     
  7. Jeff_Jeske

    Jeff_Jeske Senior Member

    Joined:
    Jul 17, 2006
    Messages:
    485
    Likes Received:
    7
    Occupation:
    Storage Engineer - DR Coordinator
    Location:
    Stevens Point, WI
    We are also an EMC shop. We use SRDF to replicate the data to the DR site storage frame via private fibre.

    Our setup is this... we backup only production servers at the primary site. We backup our qual and test servers at the DR site. The prod and test TSM servers are identical. In the event of a disaster we bring up production at the DR site on the test server. This is all scripted and has been tested to be functional.

    The thing that gets tricky is the zoning. It took quite a bit of planning to sort out all the details but it works flawlessly.
     

Share This Page