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

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

Article: 100023275
Last Published: 2009-01-16
Ratings: 0 0
Product(s): NetBackup


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


As per theVeritas NetBackup for Microsoft Exchange Server Administrators Guide, upon asuccessful restore of an Exchange 2007 CCR Cluster, you need to reseed(resume-storagegroupcopy) and then resume replication(resume-storagegroupcopy)

If you chooseto backup only the uncommitted log files you may get an error when you attemptto resume replication. The following error appears in the event applicationlogs:
Log Name:Application
Date:28/08/2009 15:45:19
Event ID:2059
TaskCategory: Service
User: N/A
Description:The log file 897 for Exchange2007server\First Storage Group is missing on theproduction copy. Continuous replication for this storage group is blocked. Ifyou removed the log file, please replace it. If the log is lost,  reseedthe passive copy  using the Update-StorageGroupCopy cmdlet in the ExchangeManagement Shell. The log file mentioned in the event id 2059 matches the lastlog in the previous backup set.
Microsoftacknowledges that the replication service is not designed to handle all thecases where NetBackup only backs up  the uncommitted logs. For moreinformation on this, see KB 976592.
This behaviorwill not be changed in Exchange 2007. Veritas is awaiting confirmation fromMicrosoft on whether the same behavior occurs in Exchange 2010.
Up until thisconfirmation, Veritas has changed the default behavior for log file backups.All logs are now backed up, not only uncommitted log files. The option to backup only uncommitted logs still remains for customers who want to take advantageof that feature. You can configure log file backups in the host properties forthe Exchange client.
From theNetBackup administration console:
Select NetBackup Management > HostProperties > Clients.  Right-click on the Exchange client(s)and click Properties. Expand Windows Client and click Exchange.

Note:This behavior will change from NetBackup 6.5.6 and 7.0.

There areseveral ways to work around this problem:
  • Beforeyou reseed and resume replication run a Full backup.
  • Beforeyou resume or update the storage group copy, copy the database and the log filesmanually to the passive node. Use Windows Explorer or another tool, such asxcopy.
  • Resetthe log generation asfollows:
(a)When you restore the storage groups, do not commit and mount them. (Uncheck the Commit after last backup set is restored in  the Restore markedfiles dialog box in NetBackup Backup, Archive and Restoreinterface.)
(b)Run eseutil /r <log generation> in each log folder. This ensureseach database is in a clean shutdown state.
(c)To reset the log generation, delete all the files in each log directory(including checkpoint files).
(d)Mount all stores. This action starts the logs at 001 again.
(e)Continue with the reseed and replication.

Was this content helpful?