Skip to main content

Who can explain how to restore the mail server after a crash from logs

 If the server crashed so the logs will lost in this crash!.

Also if you manually copy these logs it will be invaluable as the database signature will be changed, If there's a way to change the signature number it may works but I'm not aware of that.
You should have a full backup taken to use in restoration process and logs are important in the recovery to not lose your messages and changes since the last full backup.


But if you have only a database crash or corruption and you have all logs available from first created log you may have a chance as below:

What happens when the database file is lost? If we have all the log files still available it should be possible to retrieve all information. “everything is logged in the log files, even the creation of database files!”
If you dismount the database, delete the database file “mailbox database.edb” or whatever name you have given the database and try to mount the database again, the following error is raised:


Error message when a mailbox database appears to be missing

In my humble opinion, the yellow exclamation mark should be replaced with a very large red “X” since this is a very important message. When you click “Yes” a new mailbox will be created in the same location as the “old” database. This is a completely new database. Although it has the same name “mailbox database.edb” as in the previous step, it has new signatures, which Exchange Server uses to link databases and log files file together. Recovery of old log files will not result in information being replayed into the database because it is another database in this scenario. And remember, since all information is logged into the log file the creation of this new database is also logged. Choose No, and then delete the checkpoint file E00.chk and try to mount the database again. No error message is raised and the database is mounted. Even better, when you log on to your test mailbox you will see that no information is lost either!
This is what happens when you do click “Yes”: during the mount process Exchange Server cannot find the database file and it cannot find the checkpoint file.

Therefore it starts to recover all information by replaying the available log files. It starts with the oldest log file E0000000001.log which also contains the creation of the initial database file. All information in the other log files is replayed into this database until it reaches the end of the last log file E00.log. The database is mounted and ready to use.

When Exchange Server cannot find the database file but it does find the checkpoint file it will not replay the log files. It starts at the end of the last log file E00.log and it will create a new database.

How can you tell which files belong together?
Dismount the Exchange Server’s database, open a command prompt in the database’s directory and check the header information using the ESEUTIL tool. You will find the following information:


Code:
K:\sg1>eseutil /mh "mailbox database.edb"
  
 Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
 Version 08.01
 Copyright (C) Microsoft Corporation. All Rights Reserved.
  
 Initiating FILE DUMP mode...
          Database: mailbox database.edb
  
      DB Signature: Create time:08/25/2008 22:54:52 Rand:4416518 Computer:
  
     Log Signature: Create time:08/25/2008 22:54:50 Rand:4412688 Computer:
  
 Operation completed successfully in 0.140 seconds.
K:\sg1>
When you check the header information of the log files with the ESEUTIL tool you will find corresponding information:


Code:
L:\sg1>eseutil /ml e000000001a.log
  
 Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
 Version 08.01
 Copyright (C) Microsoft Corporation. All Rights Reserved.
  
       Signature: Create time:08/25/2008 22:54:50 Rand:4412688 Computer:
  
       1 k:\sg1\Mailbox Database.edb
                  Signature: Create time:08/25/2008 22:54:52 Rand:4416518 Computer:
  
 Operation completed successfully in 0.60 seconds.
  
 L:\sg1>
Note: both screen outputs have been edited for readability



As you can see both the log file signature and the database signature match, so these files belong together. When you (accidentally) create a new mailbox you will find other information in the database header:


Code:
L:\sg1>eseutil /ml e000000001c.log
  
 Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
 Version 08.01
 Copyright (C) Microsoft Corporation. All Rights Reserved.
  
       Signature: Create time:08/25/2008 22:54:50 Rand:4412688 Computer:
  
       1 k:\sg1\Mailbox Database.edb
                  Signature: Create time:09/02/2008 07:27:28 Rand:963593 Computer
 :
 Operation completed successfully in 0.70 seconds.
  
 L:\sg1>
As you can see the log signature hasn’t changed (still the same set of log files) but the database has a new signature, meaning that although the database has the same name and it is in the same location it is a new database!


Key take-a-way: the checkpoint file determines if log files are replayed and where log file replay will start and therefore what happens during the mounting process.

-----------------------------

As used in Microsoft® Exchange Server , the word recovery must be distinguished from the word restore. Restore is the act of putting database and log files back into place on a server, and recovery is the act of replaying transaction logs into the restored database.


  • Soft Recovery A transaction log replay process that occurs when a database is re-mounted after an unexpected stop, or when transaction logs are replayed into an offline file copy backup of a database.
  • Hard recovery A transaction log replay process that occurs after restoring a database from an online backup.



First Can you please share some information like what you means by crash (Is it Exchange Server failure or OS failure?), Your Exchange version (2003, 2007, 2010). DO you have backup for your OS or just the transaction logs ? Does this server running another roles or just the mailbox role?

Here is how to repair an Exchange database that won't start:

1. Make a copy of the database files before you repair them. (cause you never know)
If you're not sure where your database files are, or what they are called, you can find out in Exchange System Manager by accessing the database properties. The Database page lists the paths and names.

2. Verify that you have sufficient disk space to do the repair. As a general rule of thumb, you should have the equivalent of 20% of the database size. If you don't have that much free space on the drive where the database files are, you can use command line switches to redirect the temporary files created during repair to a different drive.

3. Run Eseutil in /P (repair) mode.
The easiest way to do this is to have both database files (.EDB and .STM) in the same directory (which they usually are). If they're in different places, you're going to have to point to the files on the command line.
Eseutil is located in the \exchsrvr\bin directory

Example:

eseutil /p c:\exchsrvr\mdbdata\db1.edb /sd:\exchsrvr\mdbdata\db1.stm /te:\temp.edb

This command line will repair DB1.EDB located on C: along with its matching .STM file located on D: and will put the temporary file on the E: drive.

If your streaming database file (.STM) is not matched to the database file (.EDB) or it has a problem that is blocking repair, you can add the /i switch to the repair command line.
The /i option ignores the signature mismatch error in the check phase. The database and streaming file will receive new signatures in the repair phase.

Repair can take a while--hours. When it finishes, it will leave you with a very detailed log file of what it did called .integ.raw.

Not quit finished yet, there are two more steps to complete.

4. Run Eseutil in /D (defragment) mode.
Repair may leave index and space allocation problems in the database. Along with compacting the physical size of the file, defragmentation rebuilds the indexes and space trees.
To defragment the database, you need space equivalent to 110% the size of the database.

As with repair, you can redirect the temporary file to a different drive if necessary, but this will take considerably longer.

5. Run Isinteg in -fix -test alltests mode.

Note: when you run Eseutil, you can move database files to temporary locations to make repairs. But to run Isinteg, you must put the database back in the location from which it is normally mounted.

At the end of an Isinteg fix run, you will probably see hundreds of warnings. This is normal as Isinteg was originally created as an internal test utility. Just make sure that at the end of a successful Isinteg run, you have zero errors reported. If there is even one error, you should run Isinteg again.

If a few runs of Isinteg do not decrease the error count down to zero, then you should not rely on this database in production. You should move mailboxes from it.

Some say you should expect to spend an hour per gigabyte of data to get through the whole repair process.
It took me 3 hours on a 9gb database though.

6. It is now safe to go home and get a heart attack. 

Recovering an Exchange Database
http://technet.microsoft.com/en-us/l...CHG.65%29.aspx

Exchange Server Log File Replay
http://www.simple-talk.com/sysadmin/...g-file-replay/

Restoring Exchange Server 2003 on SBS 2003
http://www.youtube.com/watch?v=KQWrY_3pLRw&feature=related

Exchange 2007 Database Backup and Restore
http://technet.microsoft.com/en-us/library/bb124515%28EXCHG.80%29.aspx

Comments

Popular posts from this blog

Recreating a missing VMFS datastore partition in VMware vSphere 5.x and 6.x

    Symptoms A datastore has become inaccessible. A VMFS partition table is missing.   Purpose The partition table is required only during a rescan. This means that the datastore may become inaccessible on a host during a rescan if the VMFS partition was deleted after the last rescan. The partition table is physically located on the LUN, so all vSphere hosts that have access to this LUN can see the change has taken place. However, only the hosts that do a rescan will be affected.   This article provides information on: Determining whether this is the same problem Resolving the problem   Cause This issue occurs because the VMFS partition can be deleted by deleting the datastore from the vSphere Client. This is prevented by the software, if the datastore is in use. It can also happen if a physical server has access to the LUN on the SAN and does an install, for example.   Resolution To resolve this issue: Run the  partedUtil  command on the host with the issues and verify if your output

ما هى ال FSMO Roles

  بأختصار ال FSMO Roles هى اختصار ل Flexible Single Operation Master و هى عباره عن 5 Roles فى ال Active Directory و هما بينقسموا لقسمين A - Forest Roles 1- Schema Master Role و هى ال Role اللى بتتحكم فى ال schema و بيكون فى Schema Master Role واحد فى ال Forest بيكون موجود على Domain Controller و بيتم التحكم فيها من خلال ال Active Directory Schema Snap in in MMC بس بعد ما يتعمل Schema Register بواسطه الامر التالى من ال Cmd regsvr32 schmmgmt.dll 2-Domin Naming Master و هى ال Role المسئوله عن تسميه ال Domains و بتتأكد ان مفيش 2 Domain ليهم نفس الاسم فى ال Forest و بيتم التحكم فيها من خلال ال Active Directory Domains & Trusts B- Domain Roles 1-PDC Emulator و هى ال Role اللى بتتحكم فى ال Password change فى ال domain و بتتحكم فى ال time synchronization و هى تعتبر المكان الافتراضى لل GPO's و هى تعتبر Domain Role مش زى الاتنين الاولانيين و بيتم التحكم فيها من خلال ال Active directory Users & Computers عن طريق عمل كليك يمين على اسم الدومين و نختار operations master فى تاب ال PDC Emu

Unlock the VMware VM vmdk file

  Unlock the VMware VM vmdk file Kill -9 PID Sometimes a file or set of files in a VMFS become locked and any attempts to edit them or delete will give a device or resource busy error, even though the vm associated with the files is not running. If the vm is running then you would need to stop the vm to manipulate the files. If you know that the vm is stopped then you need to find the ESX server that has the files locked and then stop the process that is locking the file(s). 1. Logon to the ESX host where the VM was last known to be running. 2.  vmkfstools -D /vmfs/volumes/path/to/file  to dump information on the file into /var/log/vmkernel 3.  less /var/log/vmkernel  and scroll to the bottom, you will see output like below: a. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)FS3: 130: <START vmware-16.log> b. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)Lock [type 10c00001 offset 30439424 v 21, hb offset 4154368 c. Nov 29 15:49:17 vm22 vmkernel: gen 664