Export (0) Print
Expand All

How to Restore Your Databases

[Unless specifically noted, the content in this topic applies to BizTalk Server 2013 and 2013 R2.]

You must restore all databases to the same mark to ensure a consistent transactional state among the databases. See Marked Transactions, Full Backups, and Log Backups.

If there is only one server in the destination system, make sure that all of the log backup sets (except for the most recent set) have been restored. See Viewing the History of Restored Backups. If all the log backup sets have not been restored, and the restore job is not currently running, run the restore job (manually if necessary). If there are outstanding backup sets that can be restored, the job processes them until they are all restored.

If there are multiple servers in the destination system, all servers must be restored to the same backup set. View the restore history on each server and make sure that the most recent log backup set restored is the same on all servers. If it is not, you must manually run the restore job on each server that needs the most recent log backup set restored.

After all of the servers are on the same backup set, the final set can be manually restored.

The adm_BackupHistory table is the central history point for the log shipping process for the source system. All backup work performed is recorded to this table. All servers in your destination system read from this table to receive the information needed to perform their restore work.

noteNote
If you restore the BAM Primary Import database from a backup, then you should also restore the BAM Archive, BAM Star Schema, and BAM Analysis databases by using a backup older than the BAM Primary backup. See Backing Up and Restoring BAM.

noteNote
If you move the full or log backups for a source database from the location in which the Backup BizTalk Server job put them, you should update the associated row for that database in the bts_LogShippingDatabases table on the destination system by setting the LogFileLocation or DBFileLocation to the new location where the destination system should read the full/log backup files. This table is populated when you run the bts_ConfigureBtsLogShipping stored procedure. By default, these columns are set to null, which indicates that the destination system should read the backup files from the location stored in the adm_BackupHistory table.

ImportantImportant
Always keep a copy of your backup files in a secure location. Even if you have log backups, you cannot restore your databases without the backup files.

Log in to SQL Server using an account that is a member of the sysadmin SQL Server role.

  1. On the destination system, open SQL Server Management Studio, and connect to your SQL Server.

  2. Expand SQL Server Agent, and expand Jobs. Do the following:

    1. Right-click the BTS Log Shipping - Get Backup History job and select Disable. The status changes to Success.

    2. Right-click the BTS Log Shipping - Restore Databases job and select Disable. The status changes to Success.

    3. Right-click the BTS Log Shipping - Restore To Mark and select Start Job at Step. Select Step ID 1 and select Start.

      When the status changes to Success, the SQL Server Agent jobs and BizTalk Server databases are restored to the destination system.

    ImportantImportant
    If the Status is Error, select the link in the Message field to determine the cause. These jobs should have a Success status before continuing.

  3. On the BizTalk Server where you edited the SampleUpdateInfo.xml file, open a command prompt, and go to:

    32-bit computer: %SystemDrive%\Program Files\Microsoft BizTalk Server <version>\Schema\Restore

    64-bit computer: %SystemDrive%\Program Files (x86)\Microsoft BizTalk Server <version>\Bins32\Schema\Restore

  4. At the command prompt, type:

    cscript UpdateDatabase.vbs SampleUpdateInfo.xml

    This script updates all tables that store information about the location of other databases.

    ImportantImportant
    Run UpdateDatabase.vbs on one server in the BizTalk group.

    On 64-bit computers, you must run UpdateDatabase.vbs from a 64-bit command prompt. Note that the default command prompt on 64-bit computers is a 64-bit command prompt and is located at %SystemDrive%\windows\System32\cmd.exe.

    If EDI is configured, open the SampleUpdateInfo.xml file for editing (%SystemRoot%\Program Files\Microsoft BizTalk Server <version>\Schema\Restore). Add the following text in the <OtherDatabases> section:

    <Database Name="MsEDIAS2" oldDBName="old dta db name" oldDBServer="old dta server" newDBName="new dta db name" newDBServer="new dta server" />

    Save the edited SampleUpdateInfo.xml file.

  5. Copy the edited SampleUpdateInfo.xml file to the following folder on every computer running BizTalk Server in this BizTalk group:

    32-bit computer: Copy to %SystemDrive%\Program Files\Microsoft BizTalk Server <version>\Schema\Restore

    64-bit computer: Copy to %SystemDrive%\Program Files (x86)\Microsoft BizTalk Server <version>\Bins32\Schema\Restore

  6. On each computer in the BizTalk Server group, open a command prompt, and go to:

    32-bit computer: %SystemDrive%\Program Files\Microsoft BizTalk Server <version>\Schema\Restore

    64-bit computer: %SystemDrive%\Program Files (x86)\Microsoft BizTalk Server <version>\Bins32\Schema\Restore

  7. At the command prompt, type:

    cscript UpdateRegistry.vbs SampleUpdateInfo.xml

    This script updates all registry entries that store information about the location of other databases.

    ImportantImportant
    Run UpdateRegistry.vbs on every server in the BizTalk group.

    On 64-bit computers, you must run UpdateRegistry.vbs from a 64-bit command prompt. Note that the default command prompt on 64-bit computers is a 64-bit command prompt and is located at %SystemDrive%\windows\System32\cmd.exe.

  8. Restart all the BizTalk Server services. See How to Start, Stop, Pause, Resume, or Restart BizTalk Server Services.

  9. After restoring your databases, restart the Windows Management Instrumentation service:

    1. Open services.msc.

    2. Right-click Windows Management Instrumentation, and then select Restart.

  10. Open BizTalk Server Administration. Do the following:

    1. Right-click the BizTalk Group and select Remove.

    2. Right-click BizTalk Server Administration and select Connect to Existing Group.

    3. In SQL Server name, select the name of the SQL Server instance that hosts the BizTalk Management database. When you select the SQL Server instance, BizTalk Server automatically detects the BizTalk Server databases on that computer.

    4. In Database name, select your BizTalk Management database (BizTalkMgmtDb by default), and then select OK.

    The BizTalk Server Administration console adds the BizTalk group to the Administration console.

    Your BizTalk Server is now restored and should be running. Next, configure the Backup BizTalk Server job to start writing backups to a new destination server. You should also reconfigure a new destination system.

ImportantImportant
If you are using the Rules Engine, after restoring the databases, you must restart the Rule Engine Update Service on every server in the BizTalk Server group. See How to Start, Stop, Pause, Resume, or Restart BizTalk Server Services.

noteNote
If you are using BAM, this is the time to restore the BAM databases. See Backing Up and Restoring BAM.

© 2014 Microsoft Corporation. All rights reserved.

Community Additions

ADD
Show:
© 2015 Microsoft