Need to export my applications from DC environment to DR environment in RSA archer
I have a DC / DR environment. They work in active and passive mode. I have built new applications in DC and made some changes in the existing applications. Need to export those applications from DC to DR.. Please advise how to do that?
Is your DC environment database being replicated over to DR? If so, there's nothing you need to do for your applications, as they will move with the database as part of replication.
If they run separately, then you'd want to use the application's Packaging functionality to move the applications over.
I agree with Scott. If you use log shipping or some other data replication method to your DR environment, both environments will always be in sync (application and data) in the event you need to switch over.
Thanks Scott & Douglas for your valuable guidance.
Yes, my DC-DR site environment has SQL 2K8 DB & we've configured DB mirroring between Active (DC) & Passive DB (DR).
How can i confirm whether DR environment is having all application level changes before making system live from DR site?
If the DC database is being replicated to DR, it doesn't have any choice but to contain the application changes. The currency would depend on your replication frequency.
To test, you would schedule a split of the BCV (Business Continuity Volume) such that they'd stand up the last completed replication in the DR site. You can then turn on Archer services and visit the DR site in a browser to confirm it's a copy. You can also do database side queries to check the last_updated dates on fields, content, users, etc.
I do not have BCV copy, can i create another instance of DB (exporting current back up in DB instance).
What all minor changes are to be done in Archer Application & DB to make application live temporarily for testing?
I'm confused. You said you were mirroring your DC database to DR, so you have to have a BCV. Perhaps your company doesn't call it that, but if you are having your DC database replicated to somewhere else, a BCV exists that is always a copy of DC, but isn't available to the DR systems until you request a split. When this happens, the replication is halted, the last completed replication is stood up in the OS, and your DR system can access it for testing. When you are done testing, you then request a resync of DR to DC, they take down the BCV and begin replication again.
Again, your company may use different terms, but if you have log shipping or replication enabled, this is happening somewhere in the background.
Perhaps instead of replication/shipping you've actually setup High Availability whereby both DC and DR have the same database, and either system can act as primary?
We do not have BCV or SAN device level replication.
We've SQL DB level mirroring enabled via log shipping at back end, data-sync is happening over network in near real time.
As per your recommendations all DC changes should be replicated in DR (if DC & DR db are in sync).
Additional I was exploring how DR can be tested/checked without disturbing DB mirroring. I can create test DB & point application towards & check functionality.
Please advice if this is possible.