Search code examples
sql-serverbiztalkdisaster-recoverybiztalk-2016

BizTalk Disaster Recovery


We would like to leverage our existing database mirroring and see if it could be used for BizTalk disaster recovery.

Our DBA uses SQL mirroring to different server for DR. The server is located at in a different physical location and has a different IP address. If something happens to the main server, I was told the DBA could easily switch to the mirrored location and business will continue as usual. Our BizTalk databases are mirrored and protected by the scheme described above. This is to set up the context of my question below.

My question is: when disaster strikes, is there a way that I can quickly configure BizTalk to look at the mirrored database? When BizTalk was configured, there was a place to put in the SQL server location. So, I wonder if any BizTalk guru has tried to set up some type of "a dual configuration" to point BizTalk back and forth between the main SQL Server and the mirrored SQL server?

I am aware that BizTalk provides some sort of BizTalk database backup for disaster recovery but I think the backup is just for use of recovering data back to the point before the disaster strikes. My scenario is perhaps a little bit different: it provides the continuity of the operations during the disaster because BizTalk databases are mirrored. Does my question make sense? I am new to BizTalk, if someone knows a better way to deal with the DR or continuity of operation during the disaster, please advise.


Solution

  • From High Availability using SQL Server Always On Availability Groups

    BizTalk Server 2016 supports synchronous-commit mode; asynchronous-commit mode is not supported. For disaster recovery, it is recommended to configure the Backup BizTalk Server job, and use log shipping. See Backing Up and Restoring BizTalk Server Databases for specific details.

    The issue with mirroring is that BizTalk has multiple databases, if they aren't all restored/mirrored to exactly the same point, then it will cause unexpected behaviour in BizTalk.