1) Is it possible to run a recovery test plan on the dr site ,while the connection to the primary site is broken?
2) What is the safest method to initiate a disaster recovery but with the primary site alive (of course with no connection between them) , test the dr site functionality, and finally shut down the dr and bring up the connection again ?
If the connection to primary site is broken u cant do a recovery test .
There are many ways and method to do a safe disaster recovery plan or even use a VMware vCenter Site Recovery Manager which can automate it for u and give u many options for it .
If you need more help let me know .
Many thanks Oscar
We have srm 5.1 with array-based replication.
Because of free storage unavailability in the dr site (which means that we cannot use snapshots for test plans), which is the safest way to test the dr configuration?
You cannot test the plan AND have the Primary Site unaffected without additional space.
Say that i cut the lines between sites
Primary is working
DR recovery is done at the dr site
do tests in dr
shutdown everything in dr
delete srm configuration in dr , and do the same at primary
connect sites again
restart storage replication
Will this procedure cause problems to my primary environment?
There is a flaw in your plan at step 3. You cannot do a DR Recovery without having a mirrored copy of your VM data files replicated by your array. You said earlier that you cannot do a test because you do not have space at the Recovery Site to have a copy of your data.
There is a missunderstanding about dr site
There is no free storage space for making snapshots at the dr site if we procceed to recovery plan test
That's why i' m asking for a scenario with both sites functioning (with no communication between them )
Ok. I think I understand you. I assume you already have a copy of VM data replicated at Recovery Site. When you run a "Recovery Plan" not test, the VMs at Protected Site are Shutdown. These VMs are powered up at the Recovery Site and you run tests. You then shutdown VMs at Recovery Site. So at this point in time ALL VMs configured for protection are Shutdown at both sites. I hope I have understood you to this point.
You now want to delete your SRM configuration. I assume you mean delete recovery plan(s) and protection groups(s). Then connect sites again and restart storage replication. Finally you want to "reconfigure SRM". What do you mean at this point ?
Remember, at this point you have the SAME VMs shutdown at both sites. The question I would like to know is what is your VM Network configuration at both sites ? Do you have a "stretched subnet" where the same network(s) for the Protected Site VMs is available at the Recovery Site and they are a mapped resource or are they re-configured to a different subnet(s). If they are different, is there still a route to each other ? Do they register to the same DNS servers ?
Basically if you start up BOTH sets of VMs, will you have a conflict in your DNS and/or IP ?
Let me tell my thoughts again.
1) Primary site with srm and storage replication to dr site
2) Protection groups and recovery plans formed
3) disable communication between sites
4) Disaster recovery at DR site. Everything is up an running
5) Still no communication between sites. Primary is in production mode. DR site is isolated from outside world
6) Tests at dr site
7) Shutdown everything in DR. Remove recovery plans and protection groups. Delete everything from inventory. Remove SRA, and break connection pair with primary
😎 Remove recovery plans and protection groups at primary site. remove sra and break connection pair with DR
9) Reestablish communication, and storage replication
10) reconfigure srm
Will i have problems with that ?
From what you describe above, there should be no issues as long as the DR site is network isolated and never able to talk to the Primary Site VMs. However, having never done this, i would suggest to test with test VMs in a test datastore only. I would be interested in results !
Also I think you may need to SVMotion the VM disks to a non-replicated datastore at the Recovery Site before you remove the SRM config.