2. Backup Procedures
This subsection
covers the backup procedures for BizTalk applications; however, a
BizTalk application is usually just one part of an overall solution that
includes other applications, servers, and databases. In general,
backing up an application solution that includes BizTalk requires the
following general procedures:
Backing up application code, artifacts, and documentation
Backing up server configuration documentation
Backing up BizTalk servers and BizTalk Group databases
Backing up related non-BizTalk databases
The following subsections focus
on the last two items listed including backup procedures for BizTalk
runtime servers and for the BizTalk Group.
2.1. BizTalk Servers
The
servers where BizTalk is installed and configured should be backed up
using your corporate standards for server backup. In addition, the
config.xml file used to configure each server should be backed up along
with documentation on what host instances, receive ports, and send ports
are installed on the server. This information can be stored in your
source code control system as solution artifacts. Essentially, the
procedures used to perform the following steps must be in a format that
administrators can use to perform a restore or disaster recovery event:
BizTalk installation:
Document what features/service pack/hotfixes are installed on the
BizTalk runtime server. Document what other products such as SharePoint,
IIS, or third-party adapters are installed.
BizTalk configuration:
Back up the config.xml file that was used to configure the server. This
file can be reused to configure the server with minor edits depending
on whether the BizTalk Windows server name changed or the SQL instance
location of the databases has changed.
Master secret:
This is an extremely important backup item. Without the master secret, a BizTalk Group cannot be
restored. The master secret is encrypted and stored in the registry of
the master secret server. It is required in order to access the
credential (SSOdb) database.
BizTalk application configuration: Document host instances, receive ports, send ports, and of course versions of BizTalk application binaries.
Maintaining the
preceding documentation is the minimum requirement necessary to restore
the BizTalk runtime servers. It is recommended to automate installation,
configuration, and application deployment as much as possible to
support normal operations as well as to provide an automated method to
restore the BizTalk runtime servers.
The next subsection covers procedures for backing up the master secret.
2.2. The Master Secret
BizTalk Server 2009 uses
the Microsoft Management Console snap-in for managing Enterprise SSO and
the master secret, as shown in Figure 1. To launch the SSO Administration tool, go to Start => All Programs => Microsoft Enterprise Single Sign-On => SSO Administration. To back up the master secret, right-click the System node, and select Backup Secret within the GUI.
Clicking Backup Secret displays the dialog box shown in Figure 2,
where you enter a location for the backup file, a password, and
optionally a password reminder. This file should be removed from the
server and stored in a safe place such as a source control system
locally as well as at an offsite location.
The Enterprise SSO tools
SSOManage.exe and SSOConfig.exe are still available in the C:\Program
Files\Common Files\Enterprise Single Sign-On directory to support
scripting, so the master secret can be backed up using the command-line
tool SSOConfig.exe with the -backupSecret switch as well.
Next, we cover procedures for backing up the BizTalk Group.
2.3. BizTalk Group
This subsection covers
backup procedures for the BizTalk Group, which consists of a set of
databases created by BizTalk Server 2009 during configuration. All of
the normal requirements when performing SQL backups apply: allocating
sufficient storage space where backup files are stored, copying backup
files to an offsite location, testing restore files on a regular basis
such as monthly, and so on. Another consideration is to ensure backup
devices and media are secure to protect business-sensitive data.
NOTE
BizTalk Server includes a SQL
Server role named BTS_BACKUP_USERS so that BizTalk databases can be
backed up without requiring System Administrator permissions within SQL
Server, except for the primary server controlling the backup process.
If not done already,
configure the Backup BizTalk Server SQL Agent job following the
instructions in the earlier subsection titled "Configuring the Backup BizTalk Server SQL Agent Job." The Backup BizTalk Server SQL Agent job backs up the following databases:
BizTalk Configuration (BizTalkMgmtDb)
BizTalk Messagebox (BizTalkMsgBoxDb)
BizTalk Tracking (BizTalkDTADb)
Rule Engine (BizTalkRuleEngineDb)
BAM Primary Import (BAMPrimaryImport)
Trading Partner Management (TPM)
Credential Database (SSOdb)
You must also back up the
following BizTalk Group databases, which are not part of the Backup
BizTalk Server SQL Agent job because they do not participate in DTC
transactions:
These databases can be
backed up using normal SQL Server backup procedures because they do not
participate in distributed transactions; however, these databases
require special consideration, described in the next subsection, if BAM
is configured with BM.exe and used as part of a BizTalk solution.
BizTalk Server 2009 includes a
table named adm_OtherBackupDatabases in the BizTalk Management database
(BizTalkMgmtDb). Other application databases that participate in DTC
transactions (i.e., accessed within an atomic scope in an orchestration)
should be added to adm_OtherBackupDatabases to remain transactionally
consistent with the BizTalk databases. Table 2 lists the column names.
Table 2. Columns in the adm_OtherBackupDatabases Table
| Field Name | Value |
|---|
| DefaultDatabaseName | The alias for the database. Can be the same as the database name or the application name. |
| DatabaseName | The actual name of the database. |
| ServerName | The name of the SQL Server instance hosting the database. |
| BTSServerName | Name of a BizTalk server. Not used, but required. |
Databases added to the
adm_OtherBackupDatabases table will automatically be backed up by the
Backup BizTalk Server SQL Agent job.
|
You must
add any non-BizTalk custom database that performs distributed
transactions with BizTalk to this table so that the table can be
restored to the same log mark and remain transactionally consistent. For
example, if you have an orchestration that updates a database named
App1 within an atomic scope in BizTalk, the database App1 must be added
to the adm_OtherBackupDatabases table.
|
|
The next step is to add the
necessary schema changes to the databases added to the
adm_OtherBackupDatabases table. Otherwise, the Backup BizTalk Server SQL
Agent job will fail. Browse to the <installation
directory>\Program Files\Microsoft BizTalk Server 2009\Schema
directory, and then run Backup_Setup_All_Procs.sql and
Backup_Setup_All_Tables.sql in the destination database. This creates
the necessary procedures, tables, and roles to participate in the Backup
BizTalk Server SQL Agent job and assigns permissions to the stored
procedures.
Now let's take a look at backup procedures for the SQL Server Analysis Services databases.
2.4. BAM Analysis Services and Supporting Databases
BizTalk leverages SQL
Server Analysis Services for reporting and analysis functionality as
part of the Business Activity Monitoring features. In BizTalk Server
2009, the Tracking Analysis Server OLAP database is available in BizTalk
installations as part of the BizTalk Group to support the service
metrics and message metrics functionality for SQL Server 2000 Analysis
Services only. The Tracking Analysis Server database is not supported on
SQL Server 2005 Analysis Services and is not available as an option
when configuring the BizTalk Group with a SQL Server 2005 database back
end.
A BizTalk Group configured
with BAM enabled in the BizTalk Configuration Wizard results in two
additional SQL Analysis Services OLAP databases if the Tracking Analysis
Server database is present:
These Analysis Services databases must be backed up following the procedures for backing up SQL Analysis Services databases.
There are two scenarios for backing up BAM SQL Server databases when BAM is enabled through the BizTalk Configuration Wizard:
BAM enabled for the BizTalk Group but not configured
BAM enabled and configured with BM.exe (i.e., the BizTalk solution includes BAM features)
The next two subsections cover these scenarios.
2.4.1. BAM Enabled but Not Configured in a BizTalk Group
Since BAM is not
configured with BM.exe, there are not any BAM-related SSIS packages
present in the solution. Therefore, the BAM SQL databases can be backed
up using regular SQL Server backup procedures or can be added to the
Backup BizTalk Server SQL Agent job by adding the table to the
adm_OtherBackupDatabases table for convenience. Here is a list of the
BAM SQL databases that must be backed up:
This will ensure that a full set
of databases for the BizTalk Group is maintained. The next subsection
covers backup procedures when BAM is enabled and configured with BM.exe.
2.4.2. BAM Enabled and Configured in a BizTalk Group
When BAM is enabled and
configured for a BizTalk Group using BM.exe, it results in the creation
of one or more SSIS packages that must be backed up in case they are
accidentally deleted as well as duplicated on the disaster recovery
site.
Before backing up the BAM
databases, ensure that neither the BAM cube process nor the data
maintenance DTS packages are running when the backup package is
scheduled to run.
Ensure consistent schema
across all BAM databases by backing up the BAM databases and DTS
packages each time a BAM activity is deployed and not deployed.
The BAM Analysis and BAM Star
Schema databases should be backed up each time a BAM view is deployed
and undeployed. Follow these procedures when backing up BAM databases:
Run the Backup BizTalk Server job to back up the BAM Primary Import database as well as the other BizTalk Server databases.
Run the BAM data maintenance SSIS package for all activities.
|
Incorporate these
steps into an SSIS package, scheduling it to run on a regular basis. To
guarantee data integrity, ensure no other BAM cubing or SSIS packages
run when this DTS package is scheduled.
|
|
Back
up the BAM Archive database after the partition is copied into the BAM
Archive database but before the partition is deleted from the BAM
Primary Import database so that a complete set of archived data is
maintained. This can be achieved by modifying the data maintenance SSIS
package for each activity to add a step to back up the BAM Archive
database before the last step in the SSIS package called End Archiving.
Back up the BAM Archive database and then the BAM Star Schema database.
Next, we cover backup procedures for Business Activity Services.
2.5. SSIS Packages
All SSIS packages that are
part of the solution must be duplicated at the disaster recovery site.
The BizTalk Configuration Wizard does not create any DTS packages.
However, if Business Activity Monitoring is part of the solution and is
configured with the BAM monitoring tool (BM.exe), there will be DTS
packages created that generate/update the OLAP cubes. The DTS packages
have names like the following:
BAM_AN_<ViewName>
BAM_DM_<activity name>
NOTE
There are no DTS packages that require backing up if BAM is not configured using the BM.exe tool.
To back up SSIS packages with SQL Server 2005/2008, follow these steps:
Open SQL Server Management Studio, and connect to Integration Services.
Expand the Stored Packages folder in Object Explorer.
Expand the subfolders to locate the package that needs to be exported.
Right-click the package, click Export, select File System, and then browse to a location to save the package.
To back up SQL Server Integration Services packages with SQL Server 2005/2008, follow these steps:
Open SQL Server Management Studio, and connect to Integration Services.
Expand the Stored Packages folder in Object Explorer.
Expand the subfolders to locate the package that needs to be exported.
Right-click the package, click Export, select File System, and then browse to a location to save the package.
There may be additional
non-BizTalk DTS packages related to the solution. These DTS packages
must also be duplicated at the disaster recovery site as well.
2.6. Backing Up SQL Agent Jobs
BizTalk Server 2009 Log
Shipping will re-create the SQL Agent jobs running in production on the
disaster recovery site; however, it is still a best practice to maintain
backups of the SQL Agent jobs in case they need to be restored outside
of a disaster recovery event.
For SQL Server 2005/2008, the steps are similar:
Connect to the database instance using SQL Server Management Studio.
Expand SQL Server Agent, and click Jobs.
Right-click each job, and select Script Job as => Create To => File.
Enter a file name, and click Save.
Go through the preceding steps for each job.
The next subsection covers backup procedures for related non-BizTalk applications and databases.
2.7. Related Non-BizTalk Applications and Databases
How related non-BizTalk
application databases are backed up depends on the BizTalk solution. As
mentioned earlier, if an orchestration updates another database from
within an atomic scope that results in a distributed transaction, the
other database must be added to the adm_OtherBackupDatabases so that it
is backed up by the Backup BizTalk Server SQL Agent job and can be
restored to the same log mark as all other databases that participate in
distributed transactions as part of the solution.
For applications and
databases that do not participate in distributed transactions with
BizTalk but are still part of the overall application solution, these
applications and databases should be backed up following your corporate
standards/guidance. Essentially, the same requirements apply in that the
source code, code documentation, runtime environment, and so on, must
be backed up such that the application and database can be restored
successfully. Always practice a restore in a lab environment to confirm
that enough information is available to be successful as well as
automate as much of the process as possible.
Next, we cover restore procedures for a BizTalk solution.
