locked
Options for BizTalk Disaster Recovery RRS feed

  • General discussion

  • Hi All,

    Can any one tell me the alternative plan for disaster recovery with BizTalk 2013 . i dont want to with  SQL log shipping as it has very much likely to have failure in case of reverse log shpping  (as i have done in the past with BizTalk 2010 ).

    Thanks

    Abhishek

    Friday, June 20, 2014 6:50 AM

All replies

  • I'm wondering if there is an officialy supported 'alternative' than log shipping + database backups.

    Glenn Colpaert - MCTS BizTalk Server - Blog : http://blog.codit.eu

    Friday, June 20, 2014 7:33 AM
  • Yap I am looking for the alternative approch other than log shipping for BizTalk Disaster Recovery .

    Thanks

    Abhishek

    Friday, June 20, 2014 8:15 AM
  • If you are talking about a cold backup of your BizTalk SQL Server ready to take over if the original Server fails, the out-of-the-box Log shipping features are the only supported way.

    Morten la Cour

    Friday, June 20, 2014 8:35 AM
  • Here's an intresting blog from Saravana on why Log shipping is the only official option: http://blogs.biztalk360.com/biztalk-backup-disaster-recovery-log-shipping-is-the-only-official-option-why/

    Glenn Colpaert - MCTS BizTalk Server - Blog : http://blog.codit.eu

    Friday, June 20, 2014 8:45 AM
  • Hi Glenn,

    I have gone through BizTalk Log shipping for Disaster Receovery  in the past many times and it realy taken has certain disadvantage as there is lot of work required to go ahead with reverse log shipping  and if SQL jobs fails during the tenure of interval.

    Thats the reason I am looking  for any alternative approch .

    Thansk
    Abhishek

    Friday, June 20, 2014 9:01 AM
  • As everyone and Microsoft is pointing out, for BizTalk’s backup and disaster recovery - Log shipping is only supported option.

    The reason for Log shipping is, BizTalk uses multiple databases during its runtime and these databases need to be transactional consistent. Hence Microsoft uses “Marked Transactions” (Marked Transactions, Full Backups, and Log Backups) in SQL back and restore jobs, which provides transactional consistency for the databases while restoring in BizTalk.

    This concept of Log shipping is not related to BizTalk, it’s to do with SQL. And with my knowledge logshipping is the way for maintaining transactional consistency across multiple databases at the same time maintain performance while taking backups. If you can find (fine tune) this process you can use it but at your risk. When you have any issue while restoring or  any performance issue while backing up, Microsoft could help you but not guarantee you to solve the issue or support its interactions with BizTalk server.


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    Friday, June 20, 2014 9:03 AM
  • Do you need to maintain the current state of any processes?  That's probably the biggest influence on what continuity strategy you use.
    Friday, June 20, 2014 1:24 PM
    Moderator
  • Yap Boatseller ,I dont wan to maintain state of process. I am just thinking of restoring the SAN storage in another Data center  in case of failure of my primary data center .

    i thins way i can replicate the SQL instance on 2nd data center and rest is how we can up the biztalk instance.

    I will be going with this approch to see the prons and cons .

    Thanks

    Abhishek

    Monday, June 23, 2014 5:23 AM
  • Yap Boatseller ,I dont wan to maintain state of process. I am just thinking of restoring the SAN storage in another Data center  in case of failure of my primary data center .

    i thins way i can replicate the SQL instance on 2nd data center and rest is how we can up the biztalk instance

    If you mean non-BizTalk databases, sure, if those apps can handle this.

    If there is absolutely no business or technical requirement to maintain any state from one site to the next, then an cold standby of an identically configured BizTalk Group may work.

    But I really do mean no state at all, not a single message, log, transaction, update, anything.  They would be complete separate BizTalk Groups.

    What you're describing above is not supported in any way with BizTalk databases.

    Monday, June 23, 2014 12:11 PM
    Moderator