Hello all! I have a bit of an issue, I have an exchange 2007 SP3 server with only a couple people on it. Up until the time I upgraded away from SP1 it backed up successfully using windows backup, but now it won't, it says that the consistency check failed, and exchange won't be available for restore. (I'm running this on a Windows Server 2008 x64 machine) The error I get in the event log is this: eseutil (3296) The log file \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\E00000064D7.log is missing (error -528) and cannot be used. If this log file is required for recovery, a good copy of the log file will be needed for recovery to complete successfully. There right,.. I've scoured the entire hard drive, and that log is not there,.. but it does have over 25,000 other ones to choose from. Eseutil, and Isinteg run fine, Exchange works, and the database mounts without issue - but I would like to get my backups working again. Is there a way that I can remove this insane number of logfiles safely? That way I don't need to worry about the one that's missing? If not can I recover the missing logfile? I'm assuming it was lost during my upgrade to SP2. Thanks for your help! J~

Yes, you can safely remove any commited log files without affecting restores. Your backups will continue to fail since it can't find this missing log file. What you need to do is dismount your databases, and remove the commited logs files (copy to another location rather then delete). Also don't delete the most current log file being used. After you removed them, mount your DB then take a full back up. How to remove Exchange Server transaction log files http://support.microsoft.com/kb/240145 James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Thanks James! I checked the databases, both public and first storage group are in a clean shutdown state. I'm moving the logfiles out of their current directory now, but it will take a while,.. it's 25 gigs worth of data in allot of 1 meg files, and that's just the first storage group directory. I will report back about how it works. If the exchange database mounts successfully after the move, is it safe to remove the old logfiles entirely? Thanks, J~

Yes if DB dismounts\mounts sucessfully all required log files are commited and you can remove. You can run eseutil to confirm but not necessary. To be safe, move the log files to another location before you delete.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

It looks like that solved it!!! I moved all the log files to another drive temporarily, re-mounted the databases (they mounted fine) and started the backup. The exchange consistency check went much faster, and it didn't produce an "Error" tab. The backup is still continuing but my bet is that there will be no problem. Plus I just got 35 gigs of hard drive space back, and a much smaller backup. Since it's all working now, there is no reason to keep these log files right? Can I save them for a week to be sure everything is okay, then just delete them? Or is there something I might use them for later? Thanks! James

From a practical standpoint not really after you have a sucessful back up. It really depends on whether you will ever need to restore from that back up set when it first started failing. Just ensure you have a good back up now.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

They wont do you much good if you need to do a restore since you are missing that log. :). It will at least prevent restoring to the point of failure. THe bigger question is why that log was missing. Do you run flat-file anti-virus on this server?

From a practical standpoint not really after you have a sucessful back up. It really depends on whether you will ever need to restore from that back up set when it first started failing. Just ensure you have a good back up now. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com Let me try to get a better understanding of these logs,.. They are used to store information until it can be written to the database, is that correct? Once it's written to the database, the information is somewhat redundant right? Are you suggesting that I could rebuild the entire database from the logfiles in the event of database corruption? And that would be their only real purpose now? But if I have a good backup then I really don't need that? Sorry if these questions are juvenile,.. I'm just a desktop support guy, I'm starting down the admin certification path, on the second cert, but I haven't done any formal reading about exchange yet. Thanks! James

They wont do you much good if you need to do a restore since you are missing that log. :). It will at least prevent restoring to the point of failure. THe bigger question is why that log was missing. Do you run flat-file anti-virus on this server? I really don't know,.. This all happened during my update from SP1 to SP2. There were some issues getting this update to go through,.. when it came up the event log was flooded with errors, one of the services failed to start, and after allot of googling I got it working again, but ever since then my backups stopped working, it wasn't until now that I had the time to deticate to figuring out why. BTW - if I dismounted the database the backup would work :) J~

Yes thats the fundamental process, the transactions are loggedfirst to dicks first before the information can be commited from memory to the DB. Once it's written it is "redundant" so that it can be used in the event of a restore. You're not necessarily rebuilding the DB from scratch, (though it can) you're basically replaying the transactions into the DB.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Yes thats the fundamental process, the transactions are loggedfirst to dicks first before the information can be commited from memory to the DB. Once it's written it is "redundant" so that it can be used in the event of a restore. You're not necessarily rebuilding the DB from scratch, (though it can) you're basically replaying the transactions into the DB. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com Provided I have a good backup of the database, and it's current log I can always just replace what's there with that right? I might loose a couple days info since the last backup, but really nothing that important is on this server,.. if a couple days email was lost it would be less than ideal, but nobody would cry about it,.. I just can't loose the last year's worth lol. Thanks, J~

Yes, you can always overwrite the existing store with a previous online backup and then the backup software will replay any logs you have. If they are all there, you can bring the store back to the point of failure using this method.

Awesome,.. Thanks everyone for the help! I think I have a better understanding of the log files now, and my backups are all up and working again :) J~