Replication Requirements

GregE

ADSM.ORG Senior Member
Joined
May 12, 2006
Messages
2,089
Reaction score
31
Points
0
Website
Visit site
TSM Server 5.5
Solaris 10

Searching the forum, I've seen some discussion of this, almost. So I thought I'd post a new thread.

In reading this technote, I'm now starting to think about how "consistency" can be achieved..
http://www-01.ibm.com/support/docvi...=swg21205074&loc=en_US&cs=utf-8&cc=us&lang=en

We're now looking at IBM XIV SAN storage, and likely DataDomain storage (file and VTL) for deduplicated file/VTL storage. We'll have a production site, and a DR site with another identical TSM server, offline, and another XIV SAN and DataDomain device. So we'll be replicating DB, logs, and storage pools to the DR site. I know we can use the XIV and DataDomain replication software, BUT that doesn't address the "collective consistency" requirement of the vital TSM pieces. The TSM pieces need to replicate as a group, otherwise the DR site may have something in a storage pool that it doesn't yet have in it's copy of the TSM DB....etc etc..

How is this achieved?

***Update: OK I found something in the XIV Copy Services redbook....
Consistency groups (CG): A consistency group is a set of related volumes on the same
XIV Storage System that are treated as a single consistent unit. Consistency groups are
supported within Remote Mirroring.


The XIV documentation answers how it's done inside XIV, where the TSM db, logs, and primary disk storage pools are. Then a question is, how to ensure that the TSM db, logs, and DataDomain file/VTL primary storage pools remain consistent as a group since the live TSM db and logs are on the XIV system, not DataDomain.
 
Last edited:
Does anyone replicate/mirror their primary disk pools to a DR site?

Am I correct to be concerned?
 
Last edited:
Personally, I don't need a "Hot" site. I can have a failover site from which I will be serving yesterday backups from the last database backup after restoring my TSM instance. So the "synchronous" database/log replication was never an issue (and too much of an hassle frankly). I'm replicating the DBB and active data pool once a day, and have agreed to a reasonable SLA with my boss.

Are you in such an High availibility environnement that you need to be able to serve backups the minute after a disaster?

Good question nonetheless, I will be following this thread with interest as I do aspire to be that efficient ;)
 
Well, this will be a new architecture for us, and the restore point objective is still not definitely defined. BUT, I have heard 4 hours for the most critical systems. Regular backups will not be able to accomodate that, so we'll have to use synchronization at the SAN/DataDomain level.

I am following this thread with interest as well. :-D
 
We have a similar situation here. Our TSM server setup looks like JeanSeb where we send our DBbackup to DR site via a scheduled SFTP script daily. VTL also replicates to DR site.

Critical servers have their LUNs replicate to the DR site.

In case of DR we send our copypool tapes over to DR site as well (not all servers backup to VTL). We restore yesterday's TSM db

The consistency thing seemed to be too much of a hassle.
 
Thanks all.

Just had a DataDomain tech in for assessment. I asked my question. Apparently I'm thinking too deep in the weeds. A major bank he works with runs TSM and just moved into several DataDomain appliances. They recently did their DR testing and things worked fine.
 
Phil: Do you use TSM to replicate your VTL or you use the VTL replication software?
We have a VTL and maybe looking for another one at or DR site so any hint on this is apreciated!.
 
TSM (any release thus far) is not aware of VTL replication. If you replicate VTL it's done at the VTL level and TSM has no knowledge of that second copy.

TSM would only be doing it if it's a "normal" TSM primary pool to copy pool backup, but I assume that's not what you're referring to.

Here's a discussion on it. The intial post is describing what you are asking, that being can TSM be the pilot that is guiding the VTL replication. Answer to that is no.
http://adsm.org/forum/showthread.php?t=21055
 
Phil: Do you use TSM to replicate your VTL or you use the VTL replication software?
We have a VTL and maybe looking for another one at or DR site so any hint on this is apreciated!.


We use the VTL to replicate and deduplicate (IBM TS7650G)
 
Questions Phil.....
Are you replicating your TSM DB and Logs to your secondary site via SAN replication? Have your DR tests been smooth?
 
GregE: i'm aware that TSM is not "VTL Replication aware" But I know that certain setup use only 1 Online pool, and use the replication software from the VTL to replicate that pool. This with the DB and logs with a sleeping TSM server. If the "Primary crash" they boot the other server with the replicat enable. This setup is reptty interesting but to my eye's one big flaw, if a volumes is corrupted, there is no turning back.

Thank phill will read the info of your VTL. We are using a EMC EDL 4106.
 
if a volumes is corrupted, there is no turning back.

I agree, and that part bothers me. For a DR site, we "could" have primary pools, replicated from the primary site, and that's it, but that brings up what you've mentioned.

Therefore, it will be best to have copy pools at the DR site, and not only replicate primary to primary, but let TSM normal primary-to-copy pool backup happen as well.
 
Back
Top