When you look at Microsoft’s documentation about restoring your BizTalk databases they always talk about restoring your databases by using log shipping. Most of my client have various reasons (unfamiliarity with the technique, requires extra servers and licenses, etc.) for not wanting to use log shipping. Alternatively you can manually restore the BizTalk databases.

My concern with manually restoring the databases is that it can take a lot of time and is prone to errors. By default the Backup BizTalk Server job creates a full backup once a day and a log backup every 15 minutes. Worst case scenario you will have to restore one full backup and (24 * 4) 96 logs times at least 5 databases. That means you will have to do 485 restore actions to restore the BizTalk databases to the latest state!

The first chapter has been written by Howard Edidin and myself. It is all about Backup and Recovery. A good backup and recovery strategy is key to keep essential data safe and recover quickly after a disaster. The chapter has the following goals.

• We will discover that Backup and Recovery is a Team effort.
• We will learn about the steps involved to create a proper Backup Plan.
• We will learn about the types of Backup Storage available.
• We will discover open-source tools that will help you implement your backups.
• We will learn how to recover from a Disaster.
• We will walk-thru actual Backup and Restore scenarios provided by some of your peers.

You can download the pdf below or by clicking here.

Off course you make backups of your BizTalk databases! You have set the Recovery Model from the databases to Full and every single day your Maintenance Plans or (actually) the SQL Server Agent jobs make Full and Log backups. So in case you need to restore your BizTalk databases, you are safe... Well, I've got some news for you... You're not so safe...

If you make BizTalk Backups like described above, you could be in deep trouble in case you need to restore. When it comes to making backups from your BizTalk databases, Microsoft supports only one way. I'll describe this way, and some insides about it, in this article.

I regularly install upgrades of BizTalk applications for clients. Before I delete the BizTalk application that is being upgraded I export the MSI and binding file. If needed, you can easily restore the old application. Also it is normally easier to edit (if needed) the old binding file then the one supplied by a developer. Besides being able to reinstall the old BizTalk application in case of upgrades, I am definitely not looking forward to the day that I am called in to completely reinstall a live production server for whatever reason. Just try and find all the sources that were installed in the production environment! Not only do you need the correct MSI but also an up-to-date binding file. To overcome this problem I created a backup-script for BizTalk applications for a client of mine. Today they gave me the OK to share scripts I wrote for them with the community. So here’s the first one.