We are revising our current contingency strategy. We build a standby server at the DR site, which is an exact copy of our current production server. This server is currently not connected to the network, but the drawback is that it will cause issues on the network IF we turn it on to apply OS & SAP patches. So the production server has be off when we do this (on weekends)
My solution to this is , I would like to build a standby server with a different name at the DR , so that we can keep it up to date. However if/when we need to implement the contingency plan to switch server at the DR site, I am concerned that by restoring the production backups to the contingency server I will still need to do some configurations for the standby server to reflect the production database. I am confused about this.
The transport, interface and RFCs will definitely also require re-configuration to point to the appropriate dependant systems.
Also, would this fall under SAP practice , any advise and how anyone has approaced contingency would definitely be helpfull
I would prefer to keep the standby server strategy as is. Where it would be built exactly like the existing with the same server name , ip address and sid as the production server.
during failover it would be an easier transition to restore the database from backups, or point the CA SANs to the DR site server.
However TSS is concerned that we have to keep it up to date (valid) and they would prefer not to schedule time on weekends to do this
when you talk of a DR site,I would strongly suggest you to install a DR server with same SID so it is easy to bring this system up when your main server crashes
Now generally the approach is to restore the DR site with one full backup of main PRD server and then copy the logs daily to DR site so in the case of disaster,DR site can be brought up ASAP.
But I think this is not possible in your case because of network issues.
But this can be tricky for you,suppose your main PRD server goes down,then you will take a lot many hours to bring DR site up
So I would suggest restore a full offline backup of PRD now on DR site and keep the log files with you,so in a disaster situiation you can apply the log files and bring this up
Also I would suggest you to perform the activity of restoring the backup of PRD on DR site once in a month as it would assure that you have less log files to be applied to DR server in the case of disaster.
Also how far is your DR site from your main server,Is it possible for you to have a guy for DR site maintenance permanently
This is correct. What we have done in the past and are revisiting the plan is to build a server at the DR sit with the same server name and sid. and tested... shut down the production server , startup the server at the dr site (which is on DR network , different than production network) , restore full db backup from backup tapes, and voila in business.
The issues were that Operations has not maintained the OS patches, and they cannot unless they shutdown the server at the DR site as the same server name etc.. exists and would cause issues.
I was hoping to have a different server name so that I can maintain thruout the yr, and just restore the prdn system backup to the standby server when a site failer (here , prodn) occurs. BUT that would not save me in terms of time, as I beleive I still have to do the re-config within the application to reflect the different standby server name etc etc...
btw the DR site is about 2 - 5KM away, on a different network and backup SAN
SAP BI & ECC is on Win 2003 SQL 2005
Maria,I would strongly suggest not to have different SID as it is against the SAP best practices and also as you say a lot of reconfiguration will be required
But I dont understand how will OS team have issues since they are on 2 different networks
and since your DR site is very nearby I dont think you will need do it through network,the team can go there shutdown DR server,apply OS patches and then perhaps SAP team can restore the backup and bring up the server since they both are in different network.
Also do you have cluster implemented,if yes they you can maintain the same virtual ip for DR server and PRD server and have different real ip's for these two servers
This will be great
But I dont think a different SID is a feasible option as if your PRD goes down,then you will have a big downtime for PRD server which I dont think you can afford
we do not have different SIDs
We actually have a server at the DR site that was built with the same server name and same SID name. This server is turned off to avoid issues with the production server that is of the same server name and same SID and same IP address.
No we do not have clustering implemented yet. This will probably be coming in the next year or so. I am currently investigating what it will take for the ideal GEO Clustering , which would buy us site failure insurance (which is really the disaster we want to cover for)
Hardware failure can be addressed thru regular MS clustering.
Any info you can provide with GEO Clustering and what future plans for SAP to support would greatly be appreciated! As well as for Clustering.
SAP still doesnt support GEO Cluster and well no idea about the future,perhaps you can write to SAP and ask them if they will be supporting in future
Refer to for clustering questions,it will be highly useful
Let me know of any questions
I have following and read many articles on HA, however I am not certain / clear as to what our HA options are for SAP .
We have a separate server (exact config as one in production) as to the one in production, and want to put together a HA strategy, with Win 2003, sql 2008. The plan I am visualizing would include automatic switch over in case the computer center here in the build (where production server is) is distroyed, or no longer available, the switch would be to the DR site which is located on a different IP network but accessible to me.
I am confused on how this would all come togehter?
Anyone have a similar infrastructure and has implemented a High Availablity contingency plan, infrastrucure? I would really be interested in speaking with you or at least maybe you could provide some insights
Thank you in advance
Geo clustering would be an ideal solution. You can run your DR site as one of your node in production cluster. In that way all patches and updates are rolled out with minimal administration effort. In case of production failure, the cluster will fail-over to the DR site and so the up time is faster. To start with, the databases needs to be synchronized. There are different ways to do it.
You need to talk to someone like EMC, NetAPP, and VMWARE (Site Recovery Manager) to get the infrastructure setup.