Using an RM Clone as a Production LUN

Bing,

You are on the right course and do have options.

The type of disaster of the source LUN is going to dictate the recovery method in my opinion. For example, if the Exchange database was corrupt but the LUN was still intact then I would do a reverse synch of the clone to bring the source LUN back to a known good state.  I really cannot imagine a situation where the source LUN is completely unusable and would require the promotion of the clone to become the production LUN. With RAID, hot spares and redundant hardware on all modern arrays this is not something that I think is worth planning for. In the completely rare case that did happen though you could always mount the clones to the host, but if that is part of your strategy then I would design the clones to offer the same level of performance as the production LUNs. That being said though I do see as an option planning on a complete array failure and replicating the clone to a remote array. If you have more than one array in your infrastructure you could replicate the clone over to another array and have the zoning and registration of the host already setup on the second array so that in the case of a complete array failure you could mask the host to the clones on the second array.

If you need to provide read/write access of the clone, then a snapshot is the best solution. I use that solution to seed our devlopment environments with copies of the production databases. I have one clone of the production database and then take snapshots of that clone and mount the snapshots to our developement environments. I will have anywhere from 2 to 6 snapshots on multiple servers active at one time using this process. So the clone doubles as local DR copy of the production data, and a source for development and backups (the backup server gets a snapshot too). The data written to a snapshot is discarded when the snapshot is refreshed or deleted.

My process is basically listed below. The order is different depending on the array type. I have done this on CLARiiONs and DMX, the below order is for DMX.

1. Nightly at 10pm synch up clone LUNs with production LUNs

2. Snapshot jobs are linked to clone job, so as soon as the clone job finishes the snapshot jobs run

3. Snapshot jobs mount snapshots on developement and backup servers

     a. If development server a postscript runs that mounts attaches the database to a SQL instance and prepares it for use by developers

     b. If backup server a postscript is run that starts the backup process

4. The next night at 10pm the snapshots are dismounted from all mount hosts, the snapshots are deleted, and then the clone synch runs.

AranH,

Thanks for the advise.

Your thought on a total disaster are true.  My thinking was how to provide a source lun and still ensure that we had a gold copy at all times.

We are just getting our DR site setup and this is part of it.

We have been tasked to provide our messaging team with a R/W copy of the Exchange Clones for being able to restore email that might have gotten inadvertently deleted during the monthly email deletion process.  We have been using SecureCopy to do this which requires a complete set of disks the same size as the clones.  That got me to thinking about using a SnapShot to provide them with their volumes.  My understanding is that within Replication Manager you can create a snapshot of the clone as R/W and present that to another host.  Is there any caveats to this , such as having to ensure that no changes to the snapshot are written to the clone, etc???

AranH,

This process is automated in the Replication Manager once it is setup and configured.  Correct.  Meaning: There is no need to do the mounting / dismounting and deletion of the snaps manually

And Again Thanks for the advice and quick responses.

Bing