Backup/DR Visualizer
  • 19 Jan 2023
  • 4 Minutes to read
  • Dark
  • PDF

Backup/DR Visualizer

  • Dark
  • PDF

Article Summary

In your organization, if the server running BizTalk Server suffers from an unrecoverable hardware failure, then you should replace it with an identical one. If there is any hardware failure for the computer designed with the BizTalk run time server, it may cause system downtime or degraded performance if the 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 backup jobs and clear procedures on how to configure log shipping, standby server, and restore procedures.

The ONLY supported way to back up BizTalk databases is via the Backup BizTalk Server job.

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.
Backup DR Visualizer 1.png

BizTalk Server allows you to set up a Standby environment, which constantly restores backups that 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 backup and log backs and stores 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 a live environment, picks 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 that 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 the 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 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.

  1. Log in to the BizTalk360 application
  2. Select the environment for which you want to set up Backup
  3. Select Administration and expand Advanced Services

Select Backup/DR Visualizer

  • Click on the configure icon (Configure Standby Environment and BizTalk Server Backup Job
  • To configure the Standby SQL instance just provide the standby instance name 
  • Click Save
BizTalk Backup Job(live) field will be pre-populated with the default name say BizTalk Server(BizTalkMgmtDB) 

In case if the customer has customer has custom BizTalk Backup Job name, BizTalk360 will be pop an indication so shall update the custom name.

  • Provide the BizTalk Backup Job name 
  • Click on Save

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.

Let's consider a scenario that the customer holds Always-On SQL Server Instance - we are now allowing to view the details related to the Backup configuration of the configure SQL server instance Always-On availability groups.
In addition we are now accepting some optional parameters such as @ForceFullBackupAfterPartialSetFailure, @BackupHour, @UseLocalTime,.. so that user can now able to view the above details too.

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 is enabled correctly
• Whether there are any errors in job history

Note: One of the SQL restore jobs is supposed to be in a 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 standby 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
  • The 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

Was this article helpful?

What's Next

Eddy, a super-smart generative AI, opening up ways to have tailored queries and responses