Exchange Restore

[CSCKone]

We had an off-site Exchange server go down last night.

Current problem: after restoring the backup, we found it to be incomplete. It is missing the log files (only the *.edb files are in the backup).
You know any means to recover an exchange database without the log files ? I've checked Technet, but all recovery items talk about using the logfiles!


If you have any idea how to recover the email from databases without log-files, let me know.

 

[snotbot]

I have recovered many servers with only the two .edb files
namely \exchsrvr\MDBDATA\pub.edb and \exchsrvr\MDBDATA\priv.edb.

these are the steps that i take

1) reinstall exchange with the original org and site settings.
2) copy the two .edb files to the \exchsrvr\MDBDATA directory
In the command prompt:

3) run eseutil /p - Repair
4) run eseutil /r - Recovery
5) run eseutil /g - Integrity
6) start ms exchange directory and ms exchange system attendant
7)navigate to \exchsrvr\bin directory
8) run isinteg -patch

good luck

 

[CSCKone]

I got it back up and running...but am now getting the "DS_E_Busy" error.

All the microsoft articles say it's because of backsync...but I have SP4 on it..and that's supposed to have been corrected.

Also..I am not getting any erros in the event log.

Any clues?

 

[snotbot]

did you recover exchange to the original service pack that was installed before it crashed? are you using the correct service account for exchange?

I have not seen this message before, i think it has something to do with an incorrect service pack application
exchange service account

 

[xnyer]

The reason you are getting the DS communication error is because you are trying to restore exchange with all of the services stopped. Leave the Exchange Directory started and the system attendant on when you do the restore and that should take care of that problem.

 

[routeconfig]

NO........I had similar problem & solved by "Starting DS" before .. Running isinteg -patch...yehhh..

Cheers!!
johndes

 

[routeconfig]

I want to keet this topic open.. Especially for person like "snotbot" since he had lot of expericace with Recovery.. I have more questions on Recovery..
Can I ask "snotbot" to share his view? Also can u let me know your e-mail address..for future ref.

Thanks..

johndes
Technical Specialist

 

[Alshrim]

Lemme start by saying -- If you are doing a restoration - only the System Attendant should be started. Chances are if you are doing a full restore - you are restoring the DS too - and the Service should be stopped.

If there were any changes to the directory store before the back ups were made - those changes will be written in the logs - and the logs will have to update the directory store.

You can indeed restore an exchange server without the logfiles -- but know this - there WILL be data loss: in the form of .. missing attachments, email, and potentially missing objects in the Directory store if any were created after your last full backup.

It is possible, but not always stable. The only time you will get a stable full recovery without Transaction logs, as far as I know - and in my experience, is if you to a full offline backup. Meaning, if you stop all services and backup your PRIV.edb and PUB.edb -- then restore them just like that ... you will not need logs to replay.. because the process of shutting down the services commits all transactions to the database; so your DB's are all up to date by the time they are shutdown. That's why it is always good to have a maintenance window to do at least one Full Offline backup every couple of months.

There are times you will get a 'log not found' error after a restoration, when services try to stop and then fail, then you try to start them again... reason for this is during the replay of the transaction logs, Exchange adds a registry keep, tracking the logs read. Without deleting this key - the exchange will alway spit out a bad log error ...

I have outlined some troubleshooting steps in my faq.. if help - give it a vote....: faq10-2775

To get more info: What kind of back ups are you using, Offline or Online backups? and do you use incrementals over the course of the week?

Hope I was helpful. Alshrim
System Administrator
MCSE, MCP+Internet

 

[Alshrim]

i'm going to add this as well.

Before running ISINTEG -path -- always TRY to start the services first. There are times the ISINTEG isn't needed (it is rare) but if it IS needed the System Attendant will spit out a message .. and that way it keeps track of what's been done to the databases. Alshrim
System Administrator
MCSE, MCP+Internet

 

[Alshrim]

err... lol type-o -- ISINTEG -patch!! duh. Alshrim
System Administrator
MCSE, MCP+Internet

 

[routeconfig]

The Application event shows following:
Event ID:102
Source: ESE97
Type : Information
Cat: Logging/Recovery
MSExchangeDS (222) The database engine is starting a full backup.

Questions:
It looks, Exchange has its own backup process. This happens during the day (our backup runs at night). Why does this event occurs every day? Is it required?
Do I need to watch this event? Will it impact our users?

John

 

[Alshrim]

Question answered here: thread10-479074 Alshrim
System Administrator
MCSE, MCP+Internet

 

[BuffaloMed]

We are having similar problems as others on this topic. We lost the log files, but have the orginal priv.edb. We followed the following steps from snotbot:

1) reinstall exchange with the original org and site settings.
2) copy the two .edb files to the \exchsrvr\MDBDATA directory
In the command prompt:
3) run eseutil /p - Repair
4) run eseutil /r - Recovery
5) run eseutil /g - Integrity
6) start ms exchange directory and ms exchange system attendant
7)navigate to \exchsrvr\bin directory
8) run isinteg -patch

After running eseutil /g, the results were unsuccessful, stating that the database may be corrupted. The priv.edb is consistant though. When an Exmerge is done on a mailbox, the pst file size is considerably smaller than what the mailbox resource actually stats (like is not exporting corrupt data)

Not sure what else we can do to restore our original full priv.edb. We are up and running, but with significant database loss.