| Home | Kaiming |
Each storage group has its own set of transaction log files. Periodically, the information in the transaction log is committed—that is, it is written into the storage group’s database file. Not all logs are committed right away. However, committed log is not deleted. Transaction logs are deleted only when you do a full online backup of all the databases in the storage group.
A check point file is used to indicate which transaction log entries have been written to a database file.
Checkpoint file—E00.chk is for first storage group; E01.chk is for second storage group; etc.
![]()
Before any full backup is performed,

After full backup is performed, some log files are deleted.

After sending messages to the mailboxes in the staff mail store:

After incremental backup, some log files are deleted:

After sending messages to the mailboxes in the staff mail store:

After differential backupàlog files are not deleted:

The result of the backup—incremental and differential backups include only the transaction logs

To restore a mail store, you must follow the order: full backup, incremental …
If there is more than one store in the storage group, you can select which store to be restored; however, you still need to follow the backup order to restore the incremental or differential backups.
Because the differential or incremental backups include only the log files, to bring the restore database to a consistent state, you must replay the log files included in incremental backups or differential backups. That replay is referred to HARD RECOVERY.
If you tick "Last Restore Set" option when you restore the last backup set, when NTbackup restore process complete, HARD RECOVERY will automatically start. All the log files from incremental backups or differential backups are replayed.

If you fail to trigger hard recovery from the backup application, you must run hard recovery manually from the command prompt with Eseutil before a restored database can be mounted. You forget to tick "Last Restore Set".
After the hard recovery, the database is in clean shutdown state. You can mount it.
The hard recovery occurs when the database is in unmounted state.
SOFT Recovery--when the database is re-mounted. The log files that have not committed will automatically replay into mailbox database.Scenario 1:
The database is in dirty shutdown state. When you re-mount it, the uncommitted log files will be committed (chk file has the records).--soft recoveryScenario 2:
After hard recovery, you can mount the database. The log directory includes a lot of log files that have not backed up. If you still use the same log directory for your storage group, you can move the chk file away from the log folder, the log files will be replayed into the database. If the soft recovery does not start, you can manually start it as eseutil /R. Please run the command directly from the log directory.
When you cannot mount the database, ESEUTIL /P (repair) and ESEUTIL /D (defrag) can be used. Before using it, back up the database and log files.
After ESEUTIL /P and ESEUTIL /D, run Isinteg -s servername -fix -test alltests
ESEUTIL works on physical level, tables, indexes, etcIsinteg works on application level, relations among tables, indexes, etc.
When you run Database Troubleshooter from Exchange Management Console, it starts both ESEUTIL and ISINTEG.