Problems accessing some records in myE2k3 database turned out to be caused by a failing disk. In investigating, it became clear that backups hadn't been running for ages, and the DAT drive has chewed what I do have.I tried to take a copy of priv1.edb, but there must have been bad sectors under the file or something because the copy operation consistently froze at about 98%. I didn't get the .stm file, butI did manage to get a copy of all the logs that had built up. Despite the database copy being (presumably) incomplete, I was able to mount it after performing eseutil /p /createstm. However, quite a lot of the more recent message items seem to be 'headers only', i.e. the subject appears in Outlook but the content is unavailable when selected. If I understand correctly, the logs should automatically be incorporated into the database and deleted when it is mounted, which I hoped would fix these 'phantom' messages. However, although the logs are evidently processed (they show up in the Event Log), they aren't deleted. I'm assuming the Repair has disassociated the database from the logs in some way. Running isinteg -fix gets rid of these 'phantom' messages and leaves a usable database (from which I can extractcontents into a new one via .pst files). Is there any chance I could get the missing messages back from the logs somehow? They're an unbroken sequence going back earlier than the first of the phantoms, so I was kind of hoping...

It depends on a lot of factors. I would start by checking all those logs files to make sure none of them are corrupt, rare but it can happen. http://support.microsoft.com/default.aspx/kb/248122 If the logs look good, review this article and make sure your situation fits either scenario, your case it would be "hard recovery" http://technet.microsoft.com/en-us/library/aa997761(EXCHG.65).aspx Make sure you have a Full backup of the database before trying either the soft or hard recovery!

Please also refer KB 823168, which provide the procedure for log replay as well Please confirm if therere any POP/IMAP users in the environment. Since you have lost the STM file, these users will lose tremendous mails even if we replay the log file

Since You have already repaired and mounted the store. The database signature has changed. so in the present scenario it is not possible to commit the old logs to database. You may have to opt for different recovery server or recovery storage group and the check for the log files sequence and states of the log files you can run the below command to check the state of log files eseutil /ml eoo Vinod |CCNA|MCSE 2003 +Messaging|MCTS|ITIL V3|

Thanks for the responses, folks, and sorry for the delay in acknowledging (email notifications were going to hotmail and I didn't think to check there!). I'll digest all the information and report back, but to answer the points raised: I have copies of the originally-recovered (i.e. unrepaired) .edb file Clients are Outlook so, if I understand correctly, the loss of the .stm file shouldn't be of much concern

OK, I've checked the logfiles (eseutil /ml) and that stepped through all the log files (including E00.log) and reported no problems. I went back to the unrepaired .edb file and forced a log replay.VAs Hachi Rokumentioned that my case would involve a 'hard recovery' but, from reading the articles referenced, it seemed to me that 'soft recovery' was my only option because I have a copy of the .edb file rather than a backup (.bkf file). Please shout if I have misunderstood. On the assumption that soft recovery was the correct thing to do, I performedeseutil /r E00 /i which appeared to complete successfully. Event log reports: eseutil (192) The database engine has successfully completed recovery steps. (The log files were not deleted as this progressed, though - I thought they were supposed to be removed as they were incorporated?) I then had to run eseutil /p /createstm (because the database won't mount without a .stm file). I could then mount the store, but the affected items were still 'phantoms' (header only, apparently no content).

Any further thoughts on this, guys? To my uninformed eye it looks like the logs aren't being incorporated into the edb, but there are no warnings or errors during theeseutil /r E00. I don't know if it's possible to raise the logging level or something? If the 'phantom' messages (headers only, apparently no content) are likely to be irrecoverable then I'll just accept it and move on. If there's still a chance, though, it would really be quite useful to get them back.

No the longs do not delete as they are being replayed into the database, did you check your event viewer as your replay logs it will generate an event with the log number in it, that is one way of telling how far along when mounting a recovered db that has thousands of log files and your not sure if Exchange is doing anything or hung. Check through your event viewer (application log) and see if they are in there. You created a blank stm and if you don't have the original there is not way to get those "header" information back, unless I'm missing something and I re-read it this time looks like something some users will just have to deal with, but if they have some of the message they can always ask the send to resend it. Now that you have recovered take a minuet to look into a few things Backup solutions Recovery solutations Disaster Recovery Testing Recovery soltions It could had been a lot worse so on the bright side gives you a chance to make sure it doesnt happen again and you're better prepared!

No the longs do not delete as they are being replayed into the database OK, thanks for confirming. did you check your event viewer as your replay logs Yes, the replays all appear in the event logs with no indications of warnings or errors, but nothing seems to get written to the .edb file. That's why I wondered whether there was a way to ramp-up the level of logging detail to see what was (or was not) happening with the content of the log files. You created a blank stm and if you don't have the original there is not way to get those "header" information back, unless I'm missing something and I re-read it this time looks like something some users will just have to deal with My understanding of the way these things work is very limited and evidently quite flawed. I thought that: a) All traffic was captured in log files a) Stuff in the .stm file got moved into the .edb file once messages had been opened with clients such as Outlook I've still got all the log files, and all the 'phantom' messages had already been viewed. That's why I was clinging to the possibility that I just might be able to recreat the content of the phantoms. If that's definitely not the case, I'll stop thrashing away at this, I just don't want to give up on it if there's still some hope (if you see what I mean). It could had been a lot worse so on the bright side gives you a chance to make sure it doesnt happen again and you're better prepared! You're absolutely right, of course, and I do intend to look into the points you mention. I thought I had it covered, but the arrangements I had were clearly woefully inadequate. It's only a tiddlytwo-userhome-office setup so we're not talking mission-critical stuff here but, even so, this episode has been problematic (not to mention personally embarrassing). One thought that occurred to me when pondering backup strategies: although I should be able to create a pretty good system, I can't think of a way that a single-server setup like mine can feasibly ensure no loss of messages between backups. Even with a RAID mirror (which I have, incidentally, but the Exchange message store somehow missed getting moved onto it!), a PSU failure could take out the whole array. Something like rsync cloning changes in real time to an external drive sounded like it could be an excellent compnent of a strategy, but I don't suppose that will be much use with permanently open files such as Exchange datastore files...