Published on : May 8, 2012
Category : BizTalk Server
When it comes to BizTalk environment “Backup and Disaster recovery”, the only official supported option is Log shipping.
This applies to all the versions of BizTalk Servers listed below
BizTalk Server 2004 SP1, 2006, 2006 R2, 2009 and 2010
Log shipping was originally introduced in BizTalk 2006 and back ported to
2004 via SP1. MSDN article contains very good resources, explaining the steps involved in setting up and restoring BizTalk databases.
Microsoft story on BizTalk Server backup/restore has never changed for the past 6 years. When it comes to disaster recovery there are 2 standard industry terms people refer to
- Recovery Point Objective (RPO), and
- Recovery Time Objective (RTO)
RPO is the amount of data loss acceptable for business, and RTO is the amount of time it?s acceptable for business without a live environment. With BizTalk Server log shipping default settings, these values will be RPO value of 15 minutes (
transaction log back up interval, which can be altered), and RTO will be
approximately 1 hour.
Depending on your system volume and amount of background noise it can tackle, you can experiment with reducing the transaction log back up time from default 15 minutes.
Why Log shipping, not any other methods?
BizTalk Server uses multiple databases as part of its runtime requirement. These databases need to be transactionally consistent (including DTC transactions) at any given point of time to ensure integrity of the server.
As part of this solution, BizTalk uses
Marked Transactions (
http://msdn.microsoft.com/en-us/library/aa577848(v=bts.20).aspx) that guaranties the transactional consistency for all of the databases included in the backup. As part of the installation/configuration, BizTalk creates a SQL Agent
Job that uses SQL log shipping for providing backup/recovery of its databases. The backup/restore solution is implemented as an external SQL artifact and is not a native functionality/feature of BizTalk server. The server runtime only expects availability of its databases in a consistent state and does not make any assumptions about the backup/restore mechanism. The task of securing a backup and restoring the database in a transactionally consistent state is assumed to be an external activity.
What’s Microsoft stand on alternate solutions?
If you use BizTalk Server with any 3rd party database solutions other than Microsoft SQL Server Log shipping for backup/restore, your primary support contact is the third-party solution provider for any support issues that are related to this. BizTalk Server was developed and tested by using Microsoft SQL Server Log shipping. The Third-party solution provider should be your primary contact for any installation issues, performance issues, or backuprestoration issues. CSS provides commercially reasonable support for BizTalk server related issues as long as it is not related to the backrestore functionality provided by the 3rd party solution.
Generally, support for any SQL specific 3rd party solutions are within the scope of support as outlined
here.
What does the above mean?
Microsoft as a software vendor provides an out of the box solution for BizTalk backup and restore. If you are choosing a third party vendor or custom crafting something for your own benefit (ex: avoiding the extra SQL server instances required for Log shipping). Then the risk is either with you or with the third party vendor to restore the data/environment back. If in case you can?t restore your DR site using a third party solution, then simply don?t call Microsoft support.
If you look at the SQL server case, there are dozen third party vendors who supply backup/restore tools for SQL server. If you use any of them and you can?t recover the data, then logically you call the third party vendor helpline or sue them, rather than calling Microsoft.
Unfortunately for BizTalk server there are not any third party solutions available that can certify and take the risk. So you are left with Log shipping.
Nandri!
Saravana Kumar
Founder –
BizTalk360
