- Updated on 01 May 2018
- 4 minutes to read
In your organization, if the computer running BizTalk Server suffers with an unrecoverable hardware failure, then you should replace it with an identical one. If there is any hardware failure for the computer designed with BizTalk run time server, it may cause system downtime or degraded performance if BizTalk group is not designed for high availability. In this situation, having a good backup plan enables you to recover with little or no data loss. BizTalk server comes out of the box with predefined back up jobs and clear procedures on how to configure log shipping, standby server and restore procedures.
The Backup BizTalk Server Job ensures that synchronized backups of all BizTalk Server databases by using full database backups and transaction log backups, in conjunction with a type of transaction known as a marked transaction.
BizTalk Server allows you to setup a Standby environment, which constantly restores backups which are created on the Live environment. Having such a Standby environment allows you, in case of a DR situation, to switch between environments in a matter of minutes, instead of hours when such an environment is not at hand. To have such an environment you need to perform the following:
- You configure the backup job in the live environment, which takes periodic full back up and log backs and stored it in a highly available UNC path.
- You configure a stand by SQL server in a remote location, which got access to both the UNC shared drive and to the Live SQL Environment (as linked server).
- Both the environment maintains a bunch of SQL tables in management and master databases respectively keeping the history of backup and restore activities
- Standby environment reads the history from live environment, pick up the data and log files from UNC share and restores it on the standby environment.
To make sure the backup, log shipping and standby restore activities work correctly, a BizTalk administrator or DBA needs to perform various checks periodically. There are many points they need to be verified, which include:
- Are the SQL Server agents running correctly on both sides?
- Are the BizTalk backup jobs in SQL Server configured correctly and enabled?
- Are there no errors in the back-up/restore job history on live and standby environments?
- Need to understand the adm_BackupHistory table to see whether the backup is working as expected
- Need to understand the bts_LogShippingHistory table in standby environment to check whether restore is working as expected
- May need to look at the configuration of backup job to check the configuration (full backup frequency, log back schedule, UNC path etc,)
All these steps just make BizTalk backup/log shipping/DR as an expert activity and it is nearly impossible for a non-BizTalk employee to understand all these steps.
BizTalk360 solves all these challenges by providing a BizTalk backup/disaster recovery visualizer as shown below.
BizTalk360 understands the configuration and displays all the details in a simpler/graphical way. Let’s look into each section:
- Backup job configuration right in the user interface
- Graphical view of Live/UNC/Standby environment
- Live and Standby backup/Log shipping, job history
Backup job configuration right in the user interface The lower part of the screen has 2 tab pages from which the Live tab page displays the current backup job configuration in an easy to understand way. Behind the scene, BizTalk360 parses the backup job configuration (all the job steps, parameters, schedule etc.) and presents it in a nice UI.
Graphical view of Live/UNC/Standby environment The next stage shows the graphical representation of the LIVE/UNC/Standby setting showing how the environments are configured.
The live as well as the standby environment displays the health of important parameters like: • Whether SQL Agent is started • Whether the backup/restore job are enabled correctly • Whether there are any errors in job history
Note: One of the SQL restore job is supposed to be in stopped state. This will be enabled only during the real disaster. BizTalk360 has the capability to understand this configuration and ignores the job while calculating the health. On the UNC share box it displays the path, names assigned to full and log names in the backup job configuration.
As mentioned earlier, it’s important to keep an eye on the backup/log shipping history records to see whether the backend is working correctly and data/logs are restored correctly in the stand by environment. The Backup/DR Visualizer enables you to view:
- You can visualize the databases being backed up/restored
- The frequency of full backup
- The frequency of log backup
- Last set of successful full backup records
- Last set of successful log backup records
- Last set of successful full restore records
- Last set of successful log restore records
- Notes clearly showing what you need to look for (ex: Restore backup set id must be live -1 to be healthy)
- Displaying the history records for backup/restore jobs