Configuring BizTalk Server Backup Jobs for Azure Blob Storage

Modernizing your BizTalk Server infrastructure doesn’t always require re-architecting your integrations. Sometimes, small and targeted improvements can significantly increase resilience, simplify operations, and reduce long-term risk. One of those improvements is moving your BizTalk database backups to Azure Blob Storage.

In this article, I’ll walk you through how to configure the native BizTalk Backup Jobs to store backups directly in Azure, using SQL Server’s BACKUP TO URL feature. This approach allows you to keep your BizTalk environment unchanged while benefiting from the durability, scalability, and geo-redundancy of cloud storage—without introducing new components or custom code.

Why move BizTalk backups to Azure?

By default, BizTalk Server stores its backups on local or network-attached storage. While this works, it introduces several challenges:

• Limited scalability
• Higher risk of data loss
• Manual offsite replication
• Higher infrastructure overhead

Azure Blob Storage provides a modern alternative:

• ✔ Geo-redundant storage
• ✔ Built-in durability
• ✔ Pay-as-you-go pricing
• ✔ Offsite protection by default
• ✔ Easy integration with SQL Server

By redirecting the BizTalk backup job to Azure Blob Storage, you significantly improve your disaster recovery posture with minimal changes to your architecture.

Architecture overview

Nothing changes in how BizTalk triggers its backups. The difference is in where SQL Server writes the backup files.

• Before: BizTalk Backup Job → SQL Server → Local/NAS storage
• After: BizTalk Backup Job → SQL Server → Azure Blob Storage

BizTalk itself remains unaware of Azure. The entire integration happens at the SQL Server level using the BACKUP TO URL feature.

YouTube walkthrough

If you prefer to follow along visually, you can watch the complete step-by-step walkthrough here:

Prerequisites

Before you begin, make sure you have:

• BizTalk Server 2016 FP2 or later (2016/2020 recommended)
• SQL Server with support for BACKUP TO URL (you will have in the versions supported by BizTalk Server)
• An Azure Storage Account
• Permissions to create SQL credentials
• Access to the BizTalk Management Database

Step 1 – Create the Azure Blob container

• Go to Azure Portal
• Open or create your Storage Account

• Navigate to Containers
• Create 3 new containers, for example:
  • full-backup
  • logs-backup
  • dta-backup

Step 2 – Generate a SAS token

You must generate a Shared Access Signature (SAS) for each container created previously with the following required permissions:

• Write – mandatory
• Read – optional

This is critical. A missing permission will cause SQL backups to fail.

To create a Shared Access Signature (SAS) for each container, you need to:

• Enter each container.
• Access Shared access tokens, under Settings.
• Set the proper permissions and the Expiration date and click Generate SAS token and URL.

You need to copy the SAS token and part of the SAS URL that point the container.

Step 3 – Create the SQL Credential

Now that we have everything set up in Azure, we need to go to the BizTalk layer and, in SQL Server, create the SQL credentials and configure the jobs.

SQL Server stores the SAS token inside a credential. And for us to create those, we need to:

• Open SQL Server Management Studio (SSMS).
• And execute the following query

CREATE CREDENTIAL [https://<storageaccount>.blob.core.windows.net/<container>]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = '<your_sas_token_without_question_mark>';

To validate:

SELECT * FROM sys.credentials;

Step 4 – Test with BACKUP TO URL (optional)

Before touching BizTalk, validate that SQL can write to Azure.

BACKUP DATABASE BizTalkMgmtDb
TO URL = 'https://<storageaccount>.blob.core.windows.net/<container>/BizTalkMgmtDb_test.bak'
WITH INIT, COMPRESSION, STATS = 10;

If this fails, BizTalk will fail as well.

Step 5 – Update the BizTalk Backup Job

BizTalk Server uses a SQL Agent job named Backup BizTalk Server to perform full backups and transaction log backups of the BizTalk Server databases. We must modify its steps to replace local disk paths with Azure URLs. For example:

• In the BackupFull step
  • Replace: ‘D:\BizTalkBackups\Full’
  • With: ‘https://biztalkserversa.blob.core.windows.net/full-backup’

• In the MarkAndBackupLog step
  • Replace: ‘D:\BizTalkBackups\Logs’
  • With: ‘https://biztalkserversa.blob.core.windows.net/logs-backup’

Repeat the same logic for the DTA Purge and Archive (BizTalkDTADb) job.

Step 6 – Validate the end-to-end flow

1. Run the Backup BizTalk Server job manually
2. Open Azure Blob Storage
3. Confirm .bak files are appearing

Redirecting BizTalk Server backups to Azure Blob Storage is one of the easiest ways to modernize your platform without touching your integrations.

• You get:
• ✔ Better resilience
• ✔ Offsite protection
• ✔ Reduced infrastructure
• ✔ Cloud-native durability

All while keeping BizTalk exactly as it is.

Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son. 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira