Remote real-time replication of the TSM database

B

BrianP

ADSM.ORG Member
Joined
Feb 24, 2008
Messages
16
Reaction score
0
Points
0
Location
Dearborn, MI
Could anyone provide some advice on how they replicate their TSM database to a remote server in "real time?" We currently have a second TSM server and a VTL at another site for DR purposes, but right now we have to restore the DB from a DB backup that is replicated over to the site via the VTL. I want to have the TSM DB ready to go in the event of an incident. I am thinking that I will need something like EMC's recoverpoit or MIMIX, but I wanted to see if anyone had a tried and true method.

Thanks
 
Maybe one way is to backup the database into a DEVCLASS=file instead of a tape or VTL. All you have to do is copy the file over and restore.

I don't believe that the TSM database is open to "active" replication as available with other databases.
 
If you have acces to a LUN at your DR site and it's fast enough to do syncronous copy, Have your TSM server see the other lun and create a database copy within TSM?
 
THE_WIPET said:
If you have acces to a LUN at your DR site and it's fast enough to do syncronous copy, Have your TSM server see the other lun and create a database copy within TSM?
Click to expand...

Be careful with this - mind the latency which can degrade performance of TSM.. If it isn't too far and you have native FC infrastructure it can work well...
 
Hi,

We use SRDF async replication of our database and logs to a remote site. For our tests, we have a TSM server at the remote site that mounts the replicated disk when replication is stopped. We run various scripts to change the ip, serverurl, and another series of scripts to define the library and to re-setup paths and drives on the remote server. As our copypools are all CDL devices at the remote site, we are up and running in under an hour. We have successfully tested restores, but we have a very limited set of servers depending on TSM for DR recovery, as the time constraints would not be advantageous.

JANECB
 
Brian
If you and Gary have set up Sepaton to replicate volumes between libraries - then all you have to do then is create a cron job to restore the DR box using the latest volume received.
This is as real time as you're going to get. As recommended, you can also send the "file" over to the DR server and then apply from there.
Its going to be some TSM scripting on Gary or your part. And support from Sepaton.

Good luck
 
Last edited:
Real-time replication

Has anyone played with MIMIX or RecoverPoint (Formerly Kaysha).
 
Since the database and logs may be changing, how do you ensure a consistent state on the remote server?


janecb said:
Hi,

We use SRDF async replication of our database and logs to a remote site. For our tests, we have a TSM server at the remote site that mounts the replicated disk when replication is stopped. We run various scripts to change the ip, serverurl, and another series of scripts to define the library and to re-setup paths and drives on the remote server. As our copypools are all CDL devices at the remote site, we are up and running in under an hour. We have successfully tested restores, but we have a very limited set of servers depending on TSM for DR recovery, as the time constraints would not be advantageous.

JANECB
Click to expand...
 
We're running GSCC cluster on our bigger boxes and it provides us with a synchronous, remote mirror plus a delayed standby currently set to lagging half an hour. The cluster always tries the synchronous mirror first and resorts to recovering the asynchronous if the synch won't come up due to corruption or whatever.

PJ
 
Last edited:
It can be done. We replicate our DB and logs between sites to a disk target which in a DR would be used as is to start up the instance on it's standby DR host. Works fine with synchronus replication, a bit iffy with asynchronous replication.
 
Interesting. Makes sense though.

We would likely be using EMC SRDF. For the entire SAN I don't know which method. Hopefully the methods can be specific to a disk set and not one or the other for everything on the SAN storage (VMax in our case).
 
We are using SRDF to replicate primary disk (TSM and its DB) but we also backup our DB to a file device class at the DR site.

In our environment the DB backup is really only to protect against database corruption. Keeping that in mind a single copy at the DR site should be plenty as it is unlikely to be needed.

We have tested and successfully recovered TSM at the DR site using the SRDF copy and new hardware.

Outside of the actual live server.... why would you need the same version of the database in more than one location?
 
Jeff_Jeske said:
....but we also backup our DB to a file device class at the DR site.
Click to expand...

We're not doing SRDF yet, so my question on that is, when you backup to that file device class offsite, are you able to exclude that database backup file from the SRDF replication it doesn't needlessly push a copy back to your onsite SAN? Does SRDF allow you to pick things to exclude from replication?
 
If you aren't using SRDF all that means is you don't have an live offsite copy to fall back on in the event of a total disaster like total loss of primary site. Even with SRDF you are still at risk of data corruption/virus/deletion that would wipe both copies immediately.

Basically... having one copy of the TSM DB offsite is plenty. For us using the DR site devc prevents the creation of any additional copies. Our storage pools are not replicated but rather copied via TSM processes. Therefore the DB backup is unaffected and not copied anywhere else.
 
Got it, thank you.
____

Jeff_Jeske said:
Our storage pools are not replicated but rather copied via TSM processes. Therefore the DB backup is unaffected and not copied anywhere else.
Click to expand...

TSM processes would get your primary pool backed up to copy pool, but what about the duplication of your primary pools to the DR site? Don't you replicate those to the DR site in the event that you need to actually run full time at the DR site for any period of time and take backups from there if that site has to be production?

Or do you only have primary pool at the current production site and only copy pool at the DR site, and in the event of disaster you would use your DR site copy pool to completely recreate a DR site primary pool using the DR TSM server?
 
For us, we just have copypool tapes for the DR site. If we hit actual disaster we'd allocate the disk we'd need at that time to run production at that site. Otherwise, you have disk platters spinning with nothing on them wasting both disk storage space as well as power/cooling.
 
GregE said:
Or do you only have primary pool at the current production site and only copy pool at the DR site, and in the event of disaster you would use your DR site copy pool to completely recreate a DR site primary pool using the DR TSM server?
Click to expand...

^ We have only primary pools at the primary site. We have only copy pools at the DR site. In the event of a DR we would mark the primary pools unavailable and if needed recover data from the copy pool.

At the DR site we have additional capacity to create new primary pools. If the DR required us to continue working from the DR site we would create new primary pools at the DR site.
 
All of this is excellent, and I appreciate the responses. Gives me some ideas to bounce around.
 
You must log in or register to reply here.

Data Privacy Impact Assessment

Compliance Assurance in Every Byte: Discover the Impact of Our DPIA Services.

Sponsor ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

Navigation Menu

Forums
   IBM TSM
   EMC Backup and Recovery
   Symantec NetBackup  
   SAN  
   NAS
   Platforms / OS
Mailing List Archives
   ADSM-L
User Groups

NordVPN 3 Months FREE

Help Support ADSM.ORG and Get NordVPN with 64% Off and 3 Months FREE.

NordVPN with 64% off + 3 months FREE

Forum statistics

Threads
31,974
Messages
135,448
Members
21,953
Latest member
jrogers
Back
Top