Hello, Is it possible to have Exchange 2007 regenerate new set of transaction logs after I dismount a database? For some reason my backup through Backupexec won't allow me to perform a granular restore. It says it missing some log files. I ran eseutil /mh last week and the system didn't find anything wrong. Below is the result of the eseutil dump file. Thanks in advance, 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:01/23/2009 14:07:26 Rand:70193565 Computer: cbDbPage: 8192 dbtime: 879195690 (0x3467762a) State: Clean Shutdown Log Required: 0-0 (0x0-0x0) Log Committed: 0-0 (0x0-0x0) Streaming File: No Shadowed: Yes Last Objid: 127396 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: (0x34F7B,73A,119) 12/03/2010 20:20:02 Last Attach: (0x2EE9A,9,86) 10/06/2010 23:33:34 Last Detach: (0x34F7B,73A,119) 12/03/2010 20:20:02 Dbid: 1 Log Signature: Create time:01/23/2009 14:07:26 Rand:70209288 Computer: OS Version: (6.0.6001 SP 1 NLS 500100.50100) Previous Full Backup: Log Gen: 216210-216230 (0x34c92-0x34ca6) - OSSnapshot Mark: (0x34CA7,8,16) Mark: 12/02/2010 19:52:56 Previous Incremental Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Previous Copy Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Previous Differential Backup: Log Gen: 215307-216232 (0x3490b-0x34ca8) - OSSnapshot Mark: (0x34CA9,8,16) Mark: 12/02/2010 19:59:21 Current Full Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Current Shadow copy backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 cpgUpgrade55Format: 0 cpgUpgradeFreePages: 0 cpgUpgradeSpaceMapPages: 0 ECC Fix Success Count: none Old ECC Fix Success Count: none ECC Fix Error Count: none Old ECC Fix Error Count: none Bad Checksum Error Count: none Old bad Checksum Error Count: none Operation completed successfully in 0.249 seconds. C:\Program Files\Microsoft\Exchange Server\Bin>eseutil /mh "c:\program files\microsoft\exchange server\mailbox\sipa.edb" Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 08.01 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating FILE DUMP mode... Database: c:\program files\microsoft\exchange server\mailbox\sipa.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:02/23/2009 12:39:53 Rand:678656 Computer: cbDbPage: 8192 dbtime: 2755001 (0x2a09b9) State: Clean Shutdown Log Required: 0-0 (0x0-0x0) Log Committed: 0-0 (0x0-0x0) Streaming File: No Shadowed: Yes Last Objid: 5321 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: (0x1DE5,8,E9) 12/03/2010 20:56:33 Last Attach: (0x1B07,9,86) 10/06/2010 23:33:29 Last Detach: (0x1DE5,8,E9) 12/03/2010 20:56:33 Dbid: 1 Log Signature: Create time:02/23/2009 12:39:53 Rand:675649 Computer: OS Version: (6.0.6001 SP 1 NLS 500100.50100) Previous Full Backup: Log Gen: 7613-7631 (0x1dbd-0x1dcf) - OSSnapshot Mark: (0x1DD0,8,16) Mark: 12/02/2010 19:58:38 Previous Incremental Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Previous Copy Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Previous Differential Backup: Log Gen: 7613-7633 (0x1dbd-0x1dd1) - OSSnapshot Mark: (0x1DD2,8,16) Mark: 12/02/2010 19:59:21 Current Full Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Current Shadow copy backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 cpgUpgrade55Format: 0 cpgUpgradeFreePages: 0 cpgUpgradeSpaceMapPages: 0 ECC Fix Success Count: none Old ECC Fix Success Count: none ECC Fix Error Count: none Old ECC Fix Error Count: none Bad Checksum Error Count: none Old bad Checksum Error Count: none Operation completed successfully in 0.31 seconds.

If I understand your question correctly you are asking if you can generate the missing logs? No thats not possible I am assuming this is an incremental backup/restore thats giving you problems? Are there any even log messages that occur when the restore fails? I assume you are trying to do a granular restore via the Symantec GRT technology? Troy Werelius www.Lucid8.com

Troy, I want Exchange to start fresh with a new sequence of log files. The problem is the log files are not flushing/deleting even after a full backup, whether Windows NT 2008 backup or 2010 Backupexec. I'm not sure if this is a BackupExec problem or a Exchange/Windows issue.

If your logs are not flushing then the backup is more than likely not completing. However, before we go down that road, how do you know the logs are not flushing and how many logs do you have? Troy Werelius www.Lucid8.com

It keeps the log on a daily basis and never flushes. In fact, I had logs going back over a year and a half.

Ok yeah thats not right and I suspect you may have larger issues going on so look at your event logs for ESE errors and warnings and see if anything jumps out. If not then; Save and then clear out your event logs Run a full backup Look for errors and warnings within the event logs and report back Also examine the backup applications report for errors/clues as to whats going on, i.e. it should tell you if it succeeded or not but don't let that fool you i.e. many products adhere to the successful failure of a backup i.e. the job finished but the backup failed. Confusing as heck so just look really close at the report Report back with your findings on the event logs and the backup report NOTE: Only use one backup product otherwise you are just complicating the problemTroy Werelius www.Lucid8.com

Troy, Pardon my ignorance. I did what you suggested, but I do not not see anything that sticks out other than the following. Information Event ID 200 Instance 2: Database headers have been successfully validated. All databases are in a dirty shutdown state. To bring these databases to a clean shutdown state, log generations 220164 (0x00035c04) to 220183 (0x00035c17) will be required. Event ID 9780 Exchange VSS Writer (instance 18126b87-60dd-4893-ab90-7bc1deb93766:49) has successfully completed the full or incremental backup of storage group 'Second Public Folder'. The database engine has also successfully executed log file truncation procedures for this storage group. (Note that this may or may not have resulted in the actual truncation of log files, depending on whether any log files existed that were candidates for truncation.) Event ID 225 MSExchangeIS (1580) First Storage Group: No log files can be truncated.

It says it did the file truncation for those databases. Could be you have some old logs that don't belong to this group in the folder. Once thing you cant try is this. Dismount all the databases in the group - this will cause all transaction logs to be committed properly Move all the logs to an alternate location or if its a unique path i.e. say Exchsrvr\Logs you can rename the directory to OLDLogs and then recreate a new Directory called logs. Once you have a clean directory Mount the databases again and you will see new logs being created immediately and as also messages are sent/received. Get your backup ready to execute open a command prompt and navigate to the Log directory. Then do a dir *.* >logs.txt which will create a listing of the logs that are in the directory at that point in time Fire the backup off Once its complete go to the directory and run dir *.* >LogPost.txt which will create a listing of all the logs that are available post backup. Now this wont be perfect since logs are always getting created but you should then be able to open the two txt files and see that the LogPost file is missing some of the log files that were in the Logs.txt file which will confirm that truncation took place. If this happened then all is well and I would guess the the logs in the OLDLogs directory are residual logs from a previous data set. If you want you can back them up as flat files in case you ever need them and then delete them from disk. Make sense?Troy Werelius www.Lucid8.com

Troy, I was told old log files (from last year) were deleted manually while the database was mounted. I am not sure if that had anything to do with it, but yes, your instructions make perfect sense. I will do this tomorrow morning. Thanks you very much for your time.

Thats probably whats happening then, i.e. bunch of old items. But this will help us dig through the issue to see whats happening. Thanks for the update and I look forward to hearing the resultsTroy Werelius www.Lucid8.com

Hi Microsoft_moron, Sure, Troy gave a very good suggestion. The other way is manually delete the log, but remember, I would check the checkpoint file and the backup log to confirm what log could be deleted. That means, the logs which are before a special log could be delete, you could confim the log through the check point file. Regards! GavinPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Troy and Gavin, All is well now. My transaction logs weren't flushed because there was a problem with LCR (local continuous replication) - external usb drive to where LCR was replicating to was disconnected. I ran a a full backup and the logs finally cleared. Thank you all very much for your help!

Excellent to hear and thanks for the update and good to know the resolution although I was unaware you were running LCR :-(Troy Werelius www.Lucid8.com