DR via replication rather than copy pool?

[Jeff_Jeske]

We currently use copypools to backup all primary pools. We deploy matching hardware at the primary and dr sites.

We have two:
IBM 3584 physical libraries
EMC DL720 VTL's
CX3-80 SATA frames

We are preparing to upgrade our EMC VTL's. However discussing our upgrade options with EMC they mentioned that a rather popular approach was to eliminate the copypool by replacing it with some kind of replicated storage device.

This is not a new technique as we use replication to protect our Tier1 and Tier2 storage. It just seems out of place for TSM.

I'm curious if any of you are utilizing this approach. In the event of a disaster, how do you present the copy storage at the DR site? How is the "copy" protected from corruption? Does this speed up normal migration and reclaimation? What are the known pros and cons?

 

[dms19]

Depending on how you plan to accomplish the replication, you'll get different answers. I know that Datadomain runs an inline replication (of the deduped data) to a DR site.

From there, in the event of a disaster it will again depend on configuration, but as I understand the direction we're going, we'll need either the copy of the TSM DB sent to the DR site for TSM Server recovery and move forward from there (attaching to the replicated device), or will need connectivity to the 2nd Datadomain device from the original site, change the pointers for stg pool volumes and return to business as usual.

The up site of this is there is no need to backup stg pools or migration. Your primary pool/replicated pool takes care of copy/tape pools freeing up a lot of time during the 24 hr cycle within TSM.

 

[Jeff_Jeske]

I'm just thinking if your primary pool takes a hit it that hit will be replicated to the secondary and may be data destructive. This is especially true for servers with direct attached storage. We have a TSM instance with 50TB of SATA storage visible to the OS. If a virus or click happy server admin decides to delete volumes bad things will be replicated to both sites.

 

[dms19]

I'm not sure about the virus portion of your post, but I believe (as I understand it, and I'm no Datadomain wiz by any means) the virus would have little impact on the datadomain (specifically) because its only data read, not execute. So if a file was backed up with a virus, its coming over in blocks, it wont/shouldnt spread to anything else.

As for the trigger happy admin, there is (again on the DataDomain devices) a built in snapshot that doesnt take up space because its deduped, and can be set for x number of days for retention....but its still an issue

As far as corruption, etc - if corrupted data is backed up, its garbage in/garbage out, no way around that. But if the 1st device has a hardware issue it should not impact the data or the 2nd device, as its a hardware issue and has raid and redundancy built in. The replication happens on the device after the data is deduped (outside of TSM) and written to the local directory - as long as the data gets commited to the first device, it will get commited to the second.