Event ID 2059 is logged after a successful restore on an Exchange 2007 CCR Cluster service

View products that this article applies to.

Expand all | Collapse all

SYMPTOMS

Consider the following scenario:

You are running a Microsoft Exchange Server 2007 Cluster Continuous Replication (CCR) Cluster service
You use Symantec NetBackup v6.5.3 or a later version to perform a full system backup

In this scenario, Symantec NetBackup has an optional feature that lets administrators perform a full system backup. This only keeps the uncommitted transaction log files instead of all the log files. If you use this feature to back up an Exchange Server 2007 CCR cluster and you later decide to restore the second cluster or a later cluster in your series of backups, restoring to the active node may complete successfully and the database can be mounted. However, the replication to the passive CCR node fails and a 2059 event that resembles the following message is logged in the Application Event log:

Log Name:      Application
Source:        MSExchangeRepl
Date:          28/08/2009 15:45:19
Event ID:      2059
Task Category: Service
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Exchange2007server.domain.com
Description:
The log file 897 for Exchange2007server\First Storage Group is missing on the production copy. Continuous replication for this storage group is blocked. If you removed the log file, please replace it. If the log is lost, the passive copy will need to be reseeded using the Update-StorageGroupCopy cmdlet in the Exchange Management Shell.
The log file mentioned in the event id 2059 matches the last log in the previous backup set.

If the passive node does not have a copy of the database and transaction logs, then, you have to use the Update-StorageGroupCopy command from the Exchange management shell or the Exchange Management Console interface to reseed the copy. After that, the database is copied to the passive node. However, the reseed fails when it tries to copy the transaction log files to the passive node.

Back to the top

CAUSE

When the Microsoft Exchange Replication service determines which transaction log files have to be replicated to the passive node, the Exchange Replication service checks which log files are present on the disk on the active node. Then, the Exchange Replication service compares the log files that have the value of the previous Full Backup Log Gen. If the value of the Previous Full Backup Log Gen is less than the lowest log generation present on the active node, then the 2059 event will be logged and the replication will fail.

Back to the top

WORKAROUND

You can work around this problem in several ways. To work around this problem, follow one of the two examples that are shown here:

If you complete another full backup after the successful restore, then the database header is updated and the next try to resume or update the replication will succeed.
Alternatively you can copy the database and log files manually to the passive node by using windows explorer or another tool, such as Xcopy, before you resume or update storage group copy.

Note The information in this article is only applicable if Symantec NetBackup is used with the option to perform a full system backup and only keeps the uncommitted log files, and you restore the second cluster or a later cluster in the series of backups. If the first backup is used, then these symptoms will not be exhibited. Similarly, if a regular full system backup with all log files is performed, then these symptoms will not be exhibited.

Back to the top

MORE INFORMATION

When this issue occurs, the database header that resembles the following text is shown:

Initiating FILE DUMP mode...
         Database: Mailbox Database.edb

        File Type: Database
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
 Format ulVersion: 0x620,12
 Engine ulVersion: 0x620,12
Created ulVersion: 0x620,12
     DB Signature: Create time:08/13/2009 17:01:41 Rand:2941307 Computer:
         cbDbPage: 8192
           dbtime: 47189 (0xb855)
            State: Dirty Shutdown
     Log Required: 913-913 (0x391-0x391)
    Log Committed: 0-913 (0x0-0x391)
   Streaming File: No
         Shadowed: Yes
       Last Objid: 372
     Scrub Dbtime: 0 (0x0)
       Scrub Date: 00/00/1900 00:00:00
     Repair Count: 0
      Repair Date: 00/00/1900 00:00:00
 Old Repair Count: 0
  Last Consistent: (0x380,8,143)  08/24/2009 10:20:49
      Last Attach: (0x381,9,86)  08/24/2009 10:27:08
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00
             Dbid: 1
    Log Signature: Create time:08/13/2009 17:01:41 Rand:2968206 Computer:
       OS Version: (6.0.6001 SP 1 NLS 500100.50100)

Previous Full Backup:
        Log Gen: 897-897 (0x381-0x381) - OSSnapshot
           Mark: (0x382,B,15E)
           Mark: 08/24/2009 10:26:40

Back to the top