Thank you for the reply but I think you lost me, I lost you or maybe I didn't explain very well our situation.
This is not a backup, I use CommVault for that purpose and it works well.
The disaster that this solution is for is if my primary data center fell off the map, I would then transfer all operations over to our disaster recovery data center which is about 300 miles away. It was mandated by my management that they do not wish this to be synchronous and wanted at least a 6 hours difference between the systems. This provides further protection for viruses, maleware, cryptolocker, etc. This initial version of the script does not cover this requirement because I am triggering it to run every 6 hours but will eventually modify it to run once per hour keeping only 6 snapshots. I haven't work though all of the logic on that yet but it will most likely look something like this:
-When the script runs, and after setting the environment variables it will create a virtual copy of the VV at the disaster recovery DC. The name of these snapshots will be predetermined for obvious reasons.
-it will then delete the oldest snapshot
-Then it will continue on with the script
I'm not sure what you mean when you say that this is not what remote copy is meant for, with my conversations with HPE and from the user guide this is exactly what it is meant do to, the only twist I have is that the 3PAR scheduling capabilities doesn't allow us to do what we need nor is it capable of intelligent communication with Oracle on Windows so I am forced to improvise which is what I have done here. I have several feature requests in and support has "grudgingly" agreed that this works, plus I have tested it exhaustively with my DBA's and SAP application teams and it worked well.
I came from the EVA world using RSM, this is pretty much the same process I did with RSM except for the EVA HP actually had a solution, they do not for the 3PAR.
I am unable to use Recovery Manager for Oracle, as I stated in my post it is not available on the Windows platform therefore it is not an option which is why I am in this position to begin with. When working with our local sales rep prior to the purchase this was discussed in detail, and we just learned a couple of months ago when we went to deploy that recovery manager would not work for Windows, when I pushed back on my sales guy he said that it did, then a few days later confirmed that it didn't. He bought me lunch though so its all good.
With Oracle you can't just replicate the database without putting it into backup mode, you have to freeze the headers or it will come up 100% of the time as corrupt and will require a restore from backup (ComVault), the point of this is to avoid that lengthy process. So instead what I do is run the process that I laid out and in addition to that I am synchronously pushing archive logs, via Oracle, to the recovery site to further minimize dataloss.
Now it is a different story on my SQL servers, I am able to use Recovery Manager for this, although it is still not as flexible as I require it to be.
The remote copy group is not in a stopped state, I put that logic in the script to cover an event in which it may be in a stopped state, for whatever reason. I'm the lead SAN guy here but not the only one who manages it so it's a safety net.
For my VMware environment I use Zerto, and it work splendidly!
I am fully licensed on all of my 8000 series arrays.
