• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2658
  • Last Modified:

Exchange Database Restore Without Transaction Log Files

Hypothetical:
If I have a copy of the .edb file from a 2003/7/10 email server that has only one mailbox store and I have the system state backup, but I don't have any transaction log files, will I still be able to restore a working copy of the mailbox?
My understanding is that it will be a working mailbox store, but it won't have any of the changes made to the database that are still in transaction log files.
0
jjh2010
Asked:
jjh2010
  • 4
  • 3
  • 2
  • +2
1 Solution
 
Manpreet SIngh KhatraSolutions Architect, Project LeadCommented:
If you have a Online Backup ... that will have .edb and .stm if Exchange 2000 or 2003 ......

If Exchange 2007 or 2010 you will have just the .edb .... you will be able to work with it only if Exchange DB backup was taken if the Database is in clean shutdown :)

Try to restore and lets than see what happens ?

- Rancy
0
 
S_K_SCommented:
Firstly if it is Exchange 2003 then you would need the EDB as well as the STM file. Log files would not be needed if the copy of the database you have is in clean shutdown

Your undersdtanding with regards to the last point quoted below is correct
"My understanding is that it will be a working mailbox store, but it won't have any of the changes made to the database that are still in transaction log files."

You would not need the System State backup if you have the online backup of the database\Store in question
0
 
jjh2010Author Commented:
I think it is safe to say this would be an offline backup.
0
Easily manage email signatures in Office 365

Managing email signatures in Office 365 can be a challenging task if you don't have the right tool. CodeTwo Email Signatures for Office 365 will help you implement a unified email signature look, no matter what email client is used by users. Test it for free!

 
Manpreet SIngh KhatraSolutions Architect, Project LeadCommented:
I too guess so but that too depends if its in Clean shutdown state or Dirty .... lets first start the restore and then proceed what information we get :)

- Rancy
0
 
S_K_SCommented:
Well then as I stated on my first post....database clean\dirty....all depends on that as to which direction you need to move ahead
0
 
Simon Butler (Sembee)ConsultantCommented:
Whether the database is dirty or not, you should still be able to mount it. The only difference is whether it requires a repair or not. Data loss could occur during a repair, and in the small window between the data being written to the logs and then the database - unless this is a backup of course, but then you will lose everything from the last backup.

However you can recover data from OST files, so data recovery from Exchange should not be considered in isolation.

Simon.
0
 
S_K_SCommented:
Sembee2: It always depends from scenario to scenario. One can come across scenarios where even blank database also does not mount and the reason in that case would be permissions issue. If database goes in Dirty shutdown then soft recovery option is available provided the required log files are available and REPAIR is an option that should be the last resort in any Case.
0
 
Manpreet SIngh KhatraSolutions Architect, Project LeadCommented:
Yeah ..... but its not that easy as if its a Offline backup even as the time for Data to be written to log file and then to Database might be short but E00.log or whatever the Generation Log is always and a;ways locked by the Information store service ..... and if the Offline backup was taken at the time database was mounted its Bound to be Dirty shutdown.

As i said if its Exchange 2007 or 2010 .... .edb will work but if its Exchange 2000 or 2003 you will need ".edb and .stm".

And no data will be available since the Backup date ...... if the server or DB crashed recently and users have the Outlook in cache we can convert the data from OST to PST using Outlook itself.

- Rancy
0
 
jjh2010Author Commented:
I really appreciate all the concern from members here. The idea about .ost files is a great idea.

Maybe a more specific hypothetical will help.

Server 2008

Exchange 2010

Windows Backup is not a solution I can use because it wants to backup EVERYTHING and there is not enough space to do this.

I awlays have a system state backup that is a week old or less because it is relatively easy to create it with powershell.

I have to leave the office for three days and I don't have another tech around. I have to leave in a hurry.

I find the EDB file and a lot of transaction transaction log files.

I open shadow copies and copy off the EDB to a removable hard drive. I abandon the transaction log files.

I come back after the trip and the server will not turn on.

I replace hardware, including hard drive, get a fresh install of Windows and Exchange, patch it, and I am ready to try to restore email.

Can I put the EDB in a folder and mount it, or is it preferrable to run eseutil on it to check for errors? Will having the transaction logs and the check file in the folder help? Or, is this approach not viable at all?
0
 
Manpreet SIngh KhatraSolutions Architect, Project LeadCommented:
Run a command
eseutil /mh "location of the .ed file" and check if it shows dirty or clean shutdown ?

- Rancy
0
 
lucid8Commented:
OK so all sorts of great information from the others however

One thing to understand here is that when an Exchange database is mounted it is ALWAYS in a DIRTY/INCONSISTENT state because its open for transactions to take place, i.e. new items sent/received, state changes (read, unread, task completions etc)  and deletions.  So regardless of the type of backup taken IF it happens while the DB is mounted its going to be DIRTY, period.

in terms of handling that database and needing the logs or requiring a /p or not it all comes down to how the backup was made.

1. If the backup was made while the Exchange DB is online via straight shadow copy or open file agent and not an Exchange Compliant backup product then I guarantee you its going to be DIRTY/INCONSISTENT and more than likely even CORRUPT because just copying the Exchange database files without putting the DB into a quiesced state is going to have ill effects on that database since you could have one or more transactions in process  with some things in memory and therefore what you will end up with is a DIRTY/INCONSISTENT and CORRUPTED database.  If you get lucky and somehow its just DIRTY you must either have the logs to rollup any uncommitted changes OR do an eseutil /P to repair the db.  Once you do a /p all the historical logs are useless

2. If the backup was made with an Exchange aware backup agent then the db will be quiesced before backup and all uncommitted logs that are part of the backup and MUST be used during restore.  

As stated above the database will be DIRTY/INCONSISTENT as well but since it was done with an Exchange Aware backup it was quiesced, backed up and then validated as part of the backup process it will not be corrupted, unless the backup detected some problem with the database during backup or it failed validation.  

To get that DB back into an operable state the DB must be restored along with the uncommitted log files included with the backup AND if there are other log files available post backup those can be rolled up as well but it must happen all in one step, i.e. you cannot rollup the required logs and then come back to do a secondary rollup later.

3. The ONLY way a database has the chance of NOT BEING DIRTY from a backup process is IF you take an offline backup,  When you dismount a database one of the steps taken is that all uncommitted logs are committed to the database and then its marked as being consistent/clean.  Then you can use that database without having to commit any logs and without having to do a repair.  However that said the downsides are

A: you have to take the DB offline during the backup process
B: If you have logs that transpired post offline backup process they cannot be committed whereas with an Exchange Aware backup you could.
0

Featured Post

Free tool for managing users' photos in Office 365

Easily upload multiple users’ photos to Office 365. Manage them with an intuitive GUI and use handy built-in cropping and resizing options. Link photos with users based on Azure AD attributes. Free tool!

  • 4
  • 3
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now