Unsolved
This post is more than 5 years old
2 Posts
0
2551
March 13th, 2013 09:00
SRM - Recoverpoint
We recently purchase Site Recovery Manager. We have been using Recoverpoint for a while now and it works great. We set our Recovery Plans and tested them out and they work flawlessly. But every year we do a Disaster Recovery test and we bring down communication between our Production site and our DR site. Which consists of a Layer2. And in the past it wasn't an issue. However now with SRM when we bring down communication and Test our recovery plan SRM fails. It fails at presenting the storage. But if we put the Recoverpoint segment back in the Layer2 every works great. Which naturally worries me if there is a actual failure. I'm under the impression everything would work if we actually did a Recovery. But am I mistaken that the test should work with the connection down?
Thank you.
joeym819
2 Posts
0
March 13th, 2013 09:00
Yes the SRM test fails. It fails with the error Failed to create snapshot of replica consistency
group 12044. SRA command 'testFailoverStart' failed for consistency
group '12044'. Replication is not active for some reason in group
copy.
etaljic81
1K Posts
0
March 13th, 2013 09:00
When you say "....we bring down communication and Test our recovery plan SRM fails," what exactly fails? Does the SRM test failover fail?
etaljic81
1K Posts
0
March 13th, 2013 13:00
Sounds like a bug in SRM. What version of SRM are you running?
vflands
1 Message
0
March 16th, 2013 19:00
Based on the issue described, I believe the issue would be with the SRA if it was an application issue. When you run the test are you selecting "Replicate recent changes to recovery site"? If so, try without that option. Another question would be which SRM instance are you running the test from the primary site or the secondary site? If the primary site, then try from the secondary site as the primary site will be unable to talk to the secondary site RPA instance. What version of SRM and RPA are you running?
kastlr
26 Posts
0
April 3rd, 2013 14:00
Hi,
I think your yearly disaster recovery test isn't really valid and that might be the reason for the seen behavior.
In your scenario you don't have a disaster, you only lost the replication link.
So neither VMware Servers nor VM's are affected, if this would be a "real incident" you wouldn't perform any SRM activity.
Additionally, in your yearly disaster recovery test you didn't even don't perform a SRM failover, instead you tried to access snapshot'ed devices.
VMware declares such approach as a Test, and by design a SRM test would leave the replication untouched to guarentee your "recovery site" will be kept up to date regardless of how long you'll "test".
So I assume the RecoverPoint SRA developers simply doesn't expect to handle a screnario you described.
Regards,
Ralf