Our Exchange 2007 server has a corrupt transaction log file. It was picked up by the Symantec Backup Exec store backup during verification of the log file. The server error numbers are 483 General, 440 Logging/Repair, and 305 Log File Validation. I am thinking the best way to handle this is to 1) dismount the database 2) shut down exchange services 3) run Eseutil /mh 4) run Eseutil /d 5) delete all of the transaction log files 6) restart exchange services 7) mount the database 8) run the backup jobs on the exchange store and server. If this is not the best plan then what should I do? Thanks - NC Beach BumNC Beach Bum

On Sun, 19 Sep 2010 01:43:51 +0000, NC Beach Bum wrote: >Our Exchange 2007 server has a corrupt transaction log file. It was picked up by the Symantec Backup Exec store backup during verification of the log file. The server error numbers are 483 General, 440 Logging/Repair, and 305 Log File Validation. I am thinking the best way to handle this is to 1) dismount the database 2) shut down exchange services 3) run Eseutil /mh 4) run Eseutil /d 5) delete all of the transaction log files 6) restart exchange services 7) mount the database 8) run the backup jobs on the exchange store and server. If this is not the best plan then what should I do? Thanks - If the log file that's damaged is one that contains only committed transaction then it isn't needed to bring the database back to a consistent state after you dismount that database. Assuming you have only one database in the storage group, if the "eseutil /mh" shows the dtabase to be in a consistent state you can move (don't copy) all the log files and the chk file to another directory and remount the database. That will start a new log file generation. Make a backup of the storage group as soon as you can. Once you're happy the backup is okay and things are running okay you can remove those old log and chk files. There shouldn't be any need to use "eseutil /d". --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Agree with Rich, eseutil /mh will give you idea about status of database about consistancy. Also if /MH shows that database is healthy then just run a online backup and again check event log for said event.Anil

Rich and Anil - The Eseutil /MH turned up with all logs committed and a clean database. Whew! Turns out there was a Trojan Redirect virus that was causing the issue. I deleted the log files and immediatly ran a virus check and then a backup. Everything is now back and cleaner than before. Thank for being there and providing excellent advice! NC Beach BumNC Beach Bum

What if the transaction log file get corrupted before the transaction gets completed. How to restore it?

In this situation, there is no option to recover damaged log files. You can try to run one full backup which help sometime to make healthy damaged logs. But again, Its weird situation. Have a look of this. http://blogs.technet.com/b/appssrv/archive/2010/04/19/data-recovery-out-of-lost-or-corrupted-transaction-logfiles.aspxAnil MCC 2011,ITIL V3,MCSA 2003,MCTS 2010, My Blog : http://messagingschool.wordpress.com