Start a Conversation

Unsolved

This post is more than 5 years old

2746

June 17th, 2016 03:00

VNX reverse sync error

Hi All,

while doing the reverse sync on vnx source lun after making the clone protected restore we are getting error stated "operation not allowed on a Recoverpoint target replication volume" error_vnx.JPG.jpg

43 Posts

June 20th, 2016 00:00

Hi,

DB349_ORA_AIL_ARCH_LUN01 is a target RSet LUN for EMC RecoverPoint CG Replication (This LUN is controlled by EMC RecoverPoint) and you can NOT do a reverse sync. on it from the Clone unless you disable the RecoverPoint CG (which will cause the snapshots history/Journal to be lost, full sweep will be required on resumption!).

Can you please let us know what is the reason that you want to reverse sync. from the clone to this LUN?

Regards,

M Makadmeh

7 Posts

June 20th, 2016 06:00

Hi Mohammad,

DB349_ORA_AIL_ARCH_LUN01  is a source live RSet LUN for EMC RP CG replication.

The reason for reverse sync was just to get the live DB up from its clone instead of going back to backup team for restoration as there was some corruption in live db.

So this cause a limitation to vnx on reverse sync when there is setup of RPA. One would not recommend to disable the CG at any case.

43 Posts

June 20th, 2016 23:00

Hi,

As long as the DB349_ORA_AIL_ARCH_LUN01 is a (((source))) live RSet LUN for EMC RP CG replication; the reverse sync. should work fine with no issues.

You can recover/get the live DB up from the RecoverPoint DR for now until you solve the Reverse sync. issue.

Open an SR with the support or you can post the same on the RecoverPoint Community page ...we might get some helpful answers

Regards,

Mohammad Makadmeh

7 Posts

June 21st, 2016 04:00

Hello,

As of now everything gets restored and db is up and running fine. we have restored db from backup. I have opened a SR on that day itself and EMC technical support were clueless why it does not allow to do reverse sync.

Later on we our self tried with pausing the RP replication,this also didn't work. Finally we got to know if we disable the CG it works but this is not the right solution to get restored by using reverse sync.

I dont know if I am missing something to get this worked. All I found that one need to disable the CG in case of live DB to be restored from its clone.

1.1K Posts

June 21st, 2016 05:00

Hi,

Quite simply the RP splitter does not track the writes from the clone volumes to the source volumes. The only VNX array based resync that is supported is Advanced Snapshots. You can refer to the RP with Midrange Array Tech Note on EMC Online Support for more information.

Regards,

Rich Forshaw

RecoverPoint Corporate Systems Engineering

43 Posts

June 21st, 2016 13:00

Hello,

For the target RP LUN reverse sync is not applicable unless you disable the CG.

For the Source RP LUN:

I have performed a reverse sync. test in the source RP LUN and it worked successfully in my environment with NO issues (straight forward without pausing or disabling the CG) ..

After the reverse sync. was complete and the clone was fractured; the RP automatically reacted on this change by a fast initialization for that particular CG and sent the new data/update to the DR site.

I think EMC support will investigate this further and revert back to you so please share the updates with us

Regards,

7 Posts

June 22nd, 2016 06:00

Hi Mohammad,

If that is the case I must go back to EMC to find what went wrong in our case. But as Rich said in his previous post that RP splitter does not track the writes from the clone volumes to the source volumes and only advance snapshot is helpful on resync.

This confuse me which statement is true.

could you please elobrate how you start with reverse sync :

1) Clone state - administrative fracture

2) fs unmount on source host

3) checked protective restore

4) start reverse sync

5) completed and auto fracture ?

after that RP auto start the fast sync..

Also we using RM for clone jobs so the clone auto administratively fracture once job completed.

43 Posts

June 23rd, 2016 01:00

Hi,

I agree with Rich. "Technically Speaking" ... RP splitter does not track the writes from the clone volumes to the source volumes.

However, the test was successful in my environment (RP V4.1.1, VNX OE 05.32.000.5.216)! there could be some sort of integrations.

Disabling the CG each time we want to reverse sync. the source LUN is not affordable. I can understand it and agree on it for the target LUN.

that's why I want to hear more from EMC Technical Support Engineer and asked you to share the updates

What I have done is:

1) Clone State - Administratively Fractured.

2) FS unmount on source host.

3) Start Reverse Sync

4) Make Clone State - Administratively Fracture after reverse sync. completion.

5) Checked the status of the RP ... fast initialization was automatically progressing and didn't lose any of the journals!

6) Tested the DR copy and found the data that has been cloned.

- To confirm the steps, go to the CG, Expand it, click on the DR copy, open the Journals tab, you will find a new bookmark automatically created by the system immediately after the reverse sync. named as " Synchronization Completed (DR_RP_Cluster ...etc).... old journals are available and the system still progressing normally.

Best Regards,

Mohammad Makadmeh


1.1K Posts

June 23rd, 2016 08:00

I’ll try and test this independently and then come back to you.

Regards,

Rich Forshaw

Consultant Corporate Systems Engineer - RecoverPoint & VPLEX (EMEA)

Data Protection and Availability Solutions

EMC Europe Limited

Mobile: +44 (0) 7730 781169

E-mail: richard.forshaw@emc.com

Twitter: @rw4shaw

EMC Europe Limited

Registered in England with Company No. 00990752 Registered office address: Level 1, Exchange House, Primrose Street, London C2A 2EG

The information contained in this e-mail message and any files transmitted with it are confidential. It is intended only for the addressee and others authorised to receive it. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are advised that you have received the e-mail in error; please delete it and notify the sender immediately. You should not retain the message or disclose its contents to anyone. Any disclosure, copying, distribution or action taken in reliance on the contents of the e-mail and its attachments is strictly prohibited.

1 Message

June 27th, 2016 05:00

Hello Rich ,

Did you get a chance to test reverse sync on source Rpa volume /?

Pb

1.1K Posts

June 27th, 2016 07:00

Not yet.

Rich Forshaw

Consultant Corporate Systems Engineer - RecoverPoint & VPLEX (EMEA)

Data Protection and Availability Solutions

EMC Europe Limited

Mobile: +44 (0) 7730 781169

E-mail: richard.forshaw@emc.com

Twitter: @rw4shaw

EMC Europe Limited

Registered in England with Company No. 00990752 Registered office address: Level 1, Exchange House, Primrose Street, London C2A 2EG

The information contained in this e-mail message and any files transmitted with it are confidential. It is intended only for the addressee and others authorised to receive it. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are advised that you have received the e-mail in error; please delete it and notify the sender immediately. You should not retain the message or disclose its contents to anyone. Any disclosure, copying, distribution or action taken in reliance on the contents of the e-mail and its attachments is strictly prohibited.

1.1K Posts

June 30th, 2016 13:00

Now tested and the behaviour is a volume sweep on the affected RecoverPoint rsets, hence why you see the short init and no impact to the journal.

We will update the RP with Mid-Range Arrays Tech Note accordingly.

No Events found!

Top