Hi there,

Firstly, can you confirm what app/database resides on the file systems?

Secondly, what I would recommend is that you create a bookmarked snapshot for the CG and then use logged image access to select this bookmark and check the integrity of the file systems again. If everything works OK, then you can move to direct image access and then disable the CG.

Regards,

Rich Forshaw

Consultant Corporate Systems Engineer - RecoverPoint &VPLEX (EMEA)

Data Protection and Availability Solutions

Thanks for the info Rich.  The LUNs hold a Cache 2007 database.

So do think my original problem is because I didn't turn on image access before disabling the CG?

Ah, Cache 2007 database. I think the issue here is consistency with the Cache 2007 database. Most databases will rollback cleanly from a RecoverPoint crash-consistent snapshot simply because they have the inherent architecture capability. Unfortunately some do not and this is not the fault of RecoverPoint as the crash-consistent snapshots it generates and are in consistent write order.

The way to test that this is the case, is to quiesce the Cache 2007 database in whatever way you can (and this could mean shutting it down), then generating a RecoverPoint bookmarked snapshot and then un-quiescing the database or starting it back up again. Once the RecoverPoint bookmarked snapshot is in the replica copy journal and accessible, invoke image access and try to mount the file systems as you have been doing.0

Regardless of the consistency issue at the application/databases level that reside on the LUNs. I would think that the LUNs should still be able to mount to the remote host.

I can see consistency issues causing problems with the application/DB, but to the OS I would assume it should still be able to mount the filesystem, esp if replication was stopped when the LUNs were in a consistent state.

OK, cool. Can you confirm that the source and replica volumes are attached to the splitters. If they are then perform the verification test as stated previously.

VNX and RP version 4.*?

I would agree with that but the suggestion was part of a process of elimination.

Question for sparky - do we have the same OS and file system type/version being used on the Prod and DR hosts?

Yes, both the same OS version & same patches

I'm not sure how to confirm that.  Could you please provide a little bit of instruction?

Looking at the splitters, I've got 2 for each site (2 sites total) and all 4 display a checkmark under status and RPA Link.

VNX

Block Software Version: 05.32.000.5.215

File Software Version: 7.1.76-4

RP

Version: 3.5.SP1(o.143)

From the UI, click on splitters from the left-hand side pane and when you select each splitter you will see which LUNs are attached.

You will see four entries in total, two for each VNX, as each VNX will show a splitter per each of it's two SP's.

OK, yes there are 4 total.  I looked inside of them and I show all my replication sets in each one.  The access says "writable but not splitting to RPA".  Again, the CG is disabled currently.

Once you start the CG, the Prod LUNs will be "writable and splitting to RPA" and the Target LUNs will be "No access". I suggest you start the CG, let it reach an Active state and then refer back to my comment 3 as a process of elimination test.

OK, this is my game plan so please tell me if you see any problems with this:

• Quiesce the Cache on Production
• Pause for a little bit to ensure replication is caught up
• Create a bookmark snapshot on the RecoverPoint
• Restart Cache on Production
• Enable physical/direct image access on the RecoverPoint using the snapshot
• Mount and test the LUNs on the DR box

If the LUNs are good, then is my next step to just disable the consistency group and remove it? (I no longer want replication) Or do I need to do something else to enable these LUNs for long term use?

Correct, Logged Image Access to Direct Image Access and the disable/remove the CG.