Exchange Server 2007 log shipping and continuous replication

Continuous replication in Exchange Server 2007 incorporates log shipping. Learn about the log shipping process and how it relates to all three types of Exchange continuous replication: standby continuous replication (SCR), local continuous replication (LCR) and cluster continuous replication (CCR).

In Exchange Server 2007, continuous replication incorporates log shipping. This tip by Microsoft Exchange expert Brien Posey explains the log shipping process as it applies to all three types of continuous replication: standby continuous replication (SCR), local continuous replication (LCR) and cluster continuous replication (CCR).

Before diving into log shipping, you must know a few Exchange server-related terms. The active copy is the primary copy of the database; the replica is referred to as the passive copy. For this tip, we will assume that a passive copy of the database is in place already and in a consistent and current state.

The Exchange 2007 log shipping process

The Microsoft Exchange Replication Service, which is often called the Replication Service, performs log shipping. The Replication Service consists of numerous subcomponents. A working knowledge of most of the subcomponents isn't necessary, but if you want to know what all of the subcomponents do, then I recommend reading Microsoft's continuous replication deep dive white paper.

More on Exchange 2007 backup methods:
Managing an Exchange 2007 CCR setup

Managing LCR in Exchange 2007

How to install Exchange 2007 on the passive node and active node

When an active Exchange server closes a log file, it updates the LastLogCopyNotified variable, which contains the number of the log file that closed. The server containing the passive copy of the database watches this variable for notification that a transaction log has been closed.

At this point, the server containing the passive database pulls the log file over a Server Message Block (SMB) connection. Once the log file arrives on the target server, it moves to a temporary folder known as the inspector directory. When the copy process is complete, the LastLogCopied variable updates to keep track of which log files moved to the target server.

Exchange Server then inspects the newly copied log file to make sure it isn't corrupt. This prevents the replay of corrupt data in the passive copy of the database.

What happens next depends on whether or not the server detects any corruption. Assuming that the transaction log file is clean, a LastLogInspected variable is updated with the number of the log file that was most recently inspected. The log file then is replayed into the passive database, and the LastLogReplayed variable is updated to show that the log file has been committed on the database's passive copy.

Database seeding in Exchange Server 2007

If log file inspection fails, then the file is recopied from the server containing the active database. If the log file continues to fail inspection, it is recopied up to three times before Exchange Server determines that the original log file on the server that contains the active database is corrupt. In such a case, Exchange considers the log file unrecoverable and requires that the database is reseeded.

Seeding (or reseeding) in Exchange Server 2007 is the process of initially creating the passive database. Exchange Server 2007 offers three different methods for seeding a database:

  • Automatic seeding is the easiest method. Unfortunately, automatic seeding only works when a new server or a new storage group is created, partly because this seeding method requires a full history of transaction logs. A full transaction log history, however, generally isn't available on existing servers.
  • Another seeding method involves using either the Update Storage Group Copy Wizard or the Update-StorageGroupCopy command. It also uses the Streaming Copy Backup API to copy the database from the active location to the passive location.
  • The final option for seeding a database is to perform an offline copy. This manual process takes a database offline, meaning that it is unavailable to users until it's brought back online.

About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.

Do you have comments on this tip? Let us know.

Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.

This was first published in December 2008
This Content Component encountered an error

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close