Article ID: 296788
Article Last Modified on 12/3/2007
APPLIES TO
- Microsoft Exchange Server 2003 Enterprise Edition
- Microsoft Exchange Server 2003 Standard Edition
- Microsoft Exchange 2000 Server Standard Edition
- Microsoft Windows Small Business Server 2003 Premium Edition
- Microsoft Windows Small Business Server 2003 Standard Edition
This article was previously published under Q296788
SUMMARY
This article describes methods you can use to bypass the online backup application programming interfaces (APIs) and manually back up and restore Exchange information store databases. If you have multiple storage groups on a single Exchange server, each storage group must be considered an independent, self-contained unit for the purposes of offline backup and restoration.For additional information about offline and snapshot backups, click the article number below to view the article in the Microsoft Knowledge Base:
296787 XADM: Offline Backup and Restoration Procedures for Exchange Server 4.0, 5.0, and 5.5
MORE INFORMATION
Before You Begin
Before you perform an offline backup, make sure that you have the following information:
- Determine whether or not circular logging is enabled for the storage group. (Circular logging is disabled by default in Exchange.) To determine whether or not circular logging is enabled, open the properties of the
storage_groupobject in Exchange System Manager, and then view the General page. To disable circular logging, click to clear the Circular Logging check box. Changes to circular logging do not take effect until you stop each database in the storage group.
You do not need to disable circular logging to perform offline backups. However, you must disable circular logging if you want to replay transaction logs into restored offline backups. - Determine the path locations for your Exchange database, streaming, transaction log, and checkpoint files, and the log file prefix for the storage group.
To locate this information, open the properties of thestorage_groupobject in Exchange System Manager, and then view the General page. Record the values for the following three boxes:- Log File Prefix (E0n, where E0n can be E00, E01, E02, or E03)
- Transaction Log Location (E0n*.log)
- System Path Location (E0n.chk)
Database paths are listed in the Database properties of each
database_nameobject. Record the values for the following two fields for each database in the storage group:- Exchange Database (.edb)
- Exchange Streaming Database (.stm)
If Exchange System Manager is unavailable, you can find all of the preceding information by directly reading raw attributes from Active Directory with a tool such as ADSIEDIT or LDIFDE. You can use the following LDIFDE command to output information for all of the Exchange servers in an Active Directory forest.
NOTE: The text for this command has been wrapped for readability.
LDIFDE -F EXPATHS.TXT -D "CN=CONFIGURATION,DC=configuration_container_domain,DC=top_level_domain" -L MSEXCHESEPARAMLOGFILEPATH,MSEXCHESEPARAMSYSTEMPATH,
MSEXCHESEPARAMBASENAME,MSEXCHESEPARAMCIRCULARLOG,MSEXCHSLVFILE,
MSEXCHEDBFILE -R"(|(MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
The following is an example of the output from the preceding command:
D:\exchsrvr\mdbdata>ldifde -f con -d "cn=configuration,dc=test,dc=com" -l msexch eseparamlogfilepath,msexcheseparamsystempath,msexcheseparambasename,msexchesepar amcircularlog,msexchslvfile,msexchedbfile -r "(|(msexcheseparamlogfilepath=*)(ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*)(msexchedbfi le=*)(msexcheseparamcircularlog=*))"
Connecting to "dc1.child.test.com"
Logging in as current user using SSPI
Exporting directory to file con
Searching for entries...
<output truncated>
.dn: CN=First Storage Group,CN=InformationStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Excha nge,CN=Services,CN=Configuration,DC=Test,DC=com
changetype: add
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00
.dn: CN=Public Information Store (EXCHANGE1),CN=First Storage Group,CN=Informati onStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Tes t,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm
.dn: CN=Private Information Store (Exchange1),CN=First Storage Group,CN=Informat ionStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Te st,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
To successfully replay transaction logs, you must restore database files (.edb and .stm) to the same path locations from which the files were backed up. For example, if you back up the database file from the E:\Mdbdata folder and the streaming database file from the F:\Mdbdata folder, you must restore the files to E:\Mdbdata and F:\Mdbdata, respectively. This limitation applies even if you want to restore the database to an entirely different server (for example, in a single mailbox recovery situation).
If you change a database path after the last backup, you can only partially replay transaction logs, and you can achieve a partial replay only if you change the path back to the original location. If you revert to the old path, you can replay logs up to the point at which the path was changed.
You can restore transaction log files (E0n*.log) to a different path than the original backup location. This is because transaction logs record the locations of the databases that the transaction logs are attached to, but databases do not record the locations of transaction logs. During replay, the logs "find" the databases by using path information that is stored in the transaction log headers. (The online backup API compensates internally for database path changes, and so this limitation does not apply.)
You do not back up or restore the checkpoint file (E0n.chk), but you must know the current location of the checkpoint file because you may need to examine it or delete it during recovery.
How Exchange Database Files Relate to Each Other
The .edb and .stm files are the final repositories for all database information. For most purposes, treat these two files as if they are a single file; back up and restore these files in tandem. These files must stay synchronized chronologically with each other; an .edb file that is backed up on one day cannot be matched with a streaming file that is backed up on another day.
An Exchange 2000 or an Exchange 2003 server can support up to four storage groups, and each storage group can support up to five databases. A storage group is a set of databases that share a common set of transaction log files. Microsoft Exchange Server 5.5 can support a maximum of one storage group, which supports up to two databases (the private and public information stores).
As changes are made to the database, the changes are first written to the current transaction log file, and then to an in-memory cache. As soon as changes are present in the cache, those changes become visible to users. Pages in the cache are flushed to the database file when it is convenient to do so. The checkpoint marks the point in the log file sequence up to which all transactions have been physically flushed to the database file. It is normal for the checkpoint to lag three or more log files behind the current log file.
To avoid confusion about which log files belong to each storage group, Exchange logs that belong to a given storage group are named with a unique log prefix, which is the first three characters of the file name. Valid log prefixes for the four storage groups that are supported on an Exchange 2000 or Exchange 2003 server are E00, E01, E02, and E03. Throughout this article, the log prefix for a storage group is designated as E0n. The current log file for a storage group is always E0n.log.
Transaction logs are a uniform 5 megabytes (MBs) in size. When the current log file is full, it is renamed with a hexadecimal sequence number, called the log generation number, and a new current log file is generated. Log files are numbered as E0n00001.log, E0n00002.log, and so on. Throughout this article, numbered log files are designated generically as E0nxxxxx.log.
If a database is stopped abnormally, the checkpoint file (E0n.chk) records the transaction log from which recovery must begin replay to restore the database to consistency. This process is called "soft recovery." Soft recovery can be contrasted with "hard recovery," which is the process by which log files are replayed after the restoration of an online backup. The most important difference between soft and hard recovery is the interpolation of patch file data into the log file replay process during hard recovery.
An inconsistent Exchange database file is a file that all of the outstanding transactions have not been written to yet. During normal operation, Exchange database files are inconsistent because there is information in the cache that has not yet been physically written to the file. In general, an Exchange database file can be considered consistent only after a normal shutdown of the database service. Nonetheless, the database, taken as a whole (considered as the sum of the information in both the transaction logs and database files), is always consistent unless necessary log files are prematurely deleted.
Backing Up an Exchange Database Offline
To back up an Exchange database offline:
- Dismount the database that you want to back up. You do not need to dismount all of the databases in the storage group, just the database or databases that you want to back up.
- Verify that the database files (both the .edb and .stm file) are consistent and matched to each other. To do so, run the following command against each file:
eseutil /mh database file | find /i "DB Signature"
NOTE: Exchange 2000 Service Pack 2 and later do not report the database state as "Consistent" or "Inconsistent", but as "Clean Shutdown" or "Dirty Shutdown." The meaning of "Clean Shutdown" is the same as "Consistent", and the meaning of "Dirty Shutdown" is the same as "Inconsistent". For Exchange 2000 Service Pack 2 or later, run this additional command to determine the state of each database:
eseutil /mh database_name | find /i "Shutdown"
The following is an example of the output from the preceding command:
D:\mdbdata>eseutil /mh priv.edb | find /i "DB Signature" DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer: D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature" DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:In the preceding example, the DB signatures are the same, which proves that the .edb and .stm files belong to the same set. (Both signature lines must match character for character in their entirety to be considered a signature match.)
Not only must the DB signatures match, but the files must also be synchronized with each other and consistent. Run the following command against each file:eseutil /mh database file | find /i "consistent"
The following is an example of the output that results from the preceding command:
D:\mdbdata>eseutil /mh priv.edb | find /i "consistent" State: Consistent Last Consistent: (0x2CC7,1F14,1F7) 04/04/2001 18:07:14 D:\mdbdata>eseutil /mh priv.stm | find /i "consistent" State: Consistent Last Consistent: (0x2CC7,1F14,1F7) 00/00/1900 00:00:00In the preceding example, both files report "State: Consistent." The hexadecimal numbers in parentheses for each file (0x2CC7,1F14,1F7) must also match. The Last Consistent time stamp does not need to match. These files are both consistent and matched to each other.
If either file reports "State: Inconsistent" or the Last Consistent log positions are not synchronized, the database was not dismounted cleanly. Mount and then dismount the database again. If the files still do not match correctly or are inconsistent, contact Microsoft Product Support Services (PSS) for further assistance.
- Copy each .edb database file and its corresponding .stm streaming database file to a backup location.
- Mount the backed up databases.
- If circular logging is enabled, skip this step. If circular logging is disabled, and you want to "roll forward" later, you must back up all of the numbered transaction log files (the E0nxxxxx.log files). Do not back up the E0n.log, Res1.log, and Res2.log files.
You can back up numbered log files at any convenient time, even immediately after creation, because after a log file has been renamed from E0n.log to E0nxxxxx.log, Exchange does not alter that file again. However, purge backed up log files only according to the instructions in step 6.
Your log file backups do not have a one-to-one correspondence with your database backups. Each log file backup is a link in a chain of log files that may be playable against any of several different database backups. You can roll forward from a particular database backup as long as you have an unbroken stream of logs starting with the log listed in the "Last Consistent" line of the database's header. In this article, the last consistent log is referred to as the "low anchor log."
If you refer to the preceding example, the last consistent entry is (0x2CC7,1F14,1F7). The three numbers designate a log file, a page in that log file, and a byte offset into that page. Each log file contains approximately 10,000 pages of 512 bytes each. The page offset gives you a good idea of how close the log file is to being full (the log file in the preceding example is about 80 percent full, because 0x1F14 is equivalent to decimal 7956), but is irrelevant to recovery. Recovery always starts at the beginning of a log file.
In this example, the low anchor log file is E0n02cc7.log.
You may not always see the last consistent log on disk as a numbered log, because the last consistent log may still be named E0n.log. You can see the sequence number E0n.log will eventually be given by examining the log file header while the database is stopped (access is denied to the E0n.log header while the database is running).
To view the internal log generation number, run the following command:eseutil /ml [log file] | find /i "lGeneration"
The following is an example of the output from the preceding command:
In many circumstances, it is more important to make sure that your log file backups are good than it is to make sure that each database backup is good. This is because each database backup can provide redundancy for the others, but full recovery from any database backup is dependent on the preservation of each and every log file after that backup.E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration" lGeneration: 11463 (0x2CC7) - Skip this step if circular logging is enabled. Examine the header of the checkpoint file to determine the highest numbered log file that can be safely removed. The checkpoint tracks the lowest numbered log file that is necessary for automatic recovery if the database is abnormally stopped. To examine the checkpoint file, run the following command:
eseutil /mk E0n.chk
The following is an example of the output from the preceding command:
D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint" Checkpoint file: e00.chk LastFullBackupCheckpoint: (0x0,0,0) Checkpoint: (0x2CC7,9607,256)The third line, the Checkpoint line, contains the relevant information (the LastFullBackupCheckpoint entry is used by online backup, and remains all zeroes if an online backup is never performed against the database). The Checkpoint log position format is the same as the last consistent entry in the database header. In this example, the checkpoint is in E0002cc7.log.
In this example, you can remove all of the logs up to E0002cc6.log.
If circular logging is disabled, log files accumulate until they are either manually deleted or removed automatically by the online backup process. If circular logging is enabled, no special management of old log files is required, because the database service automatically deletes old log files after the checkpoint passes through them.
After you back up all of the numbered log files, you can reclaim disk space by removing all of the numbered log files up to, but not including, the checkpoint log.
IMPORTANT: Do not remove the checkpoint log.
- This step is optional. You can use the Esefile utility to verify the page-level integrity of the copied databases.
The Esefile.exe file is available in the Support folder on the Exchange Server 5.5 Service Pack 3 CD-ROM, the Exchange 2000 Server installation CD-ROM, or the Exchange Server 2003 installation CD-ROM. You can also obtain the Esefile.exe file from Microsoft PSS. The Esefile utility works for .edb files from Exchange Server 5.0 and 5.5, Exchange 2000, and Exchange 2003.
There is currently no method other than online backup to verify the checksums for each page of an .stm file. The .stm file contains raw data. All of the indexes and pointers that organize that data are in the .edb file. A problem in the .stm file causes some specific client data loss, but does not compromise the structural or logical integrity of the database as a whole.
To verify the page checksums for an Exchange database, run the following Esefile utility command:esefile /s
database_nameThe following is an example of the output from the preceding command:
E:\mdbdata>esefile /s priv.edb Checksumming 0 10 20 30 40 50 60 70 80 90 100 |----|----|----|----|----|----|----|----|----|----| ................................................... 23042 pages seen 0 bad checksums 241 uninitialized pages 0 wrong page numbers esefile completes successfully after 10 secondsUninitialized pages are acceptable, but in a database with no problems, there are 0 bad checksums and 0 wrong page numbers.
If a database does not pass the Esefile utility integrity check, your best option is to restore an earlier backup that you know to be good, and to roll the database forward. If such a backup is not available, consult PSS for advice about how to repair or salvage the database.
- This step is optional. You can use the following command to verify the integrity of backed up log files:
eseutil /ml E0n
The following is an example of the output from the preceding command:
k:\backups>eseutil /ml E00You must run this command from a folder that contains the backed up log files. You can also run this command against the current running log folder, but if Eseutil tries to read the header of E0n.log while any database in the storage group is running, you receive a -1032 error (JET_errFileAccessDenied).
This command detects corruption in the log files, and also warns you if a log file is missing in the middle of a sequence, or if a signature mismatch exists between any of the log files.
Restoring an Offline Backup of an Exchange Database
This section describes two methods to restore an offline backup:
- "Point in time" restoration. No log files are replayed into the database. All of the data created after the backup is lost.
- "Roll forward" restoration. The log files that were created after the backup are played into the database. If all of the log files are available, all of the data that was created after the backup can be preserved. If circular logging is enabled, you must perform a "point in time" restoration of your offline backup; you cannot choose a "roll forward" restoration.
The file set that you restore must meet the following minimum criteria:
- For point in time restorations, all of the stopped databases in the storage group must be consistent, and there must be a valid checkpoint file. Do not delete the current checkpoint file or any existing log files.
- For roll forward restorations, all of the databases in the storage group must be stopped and consistent, and all of the log files that were created after the time that the backup was taken must exist (including the current E0n.log). The checkpoint file must be deleted.
If the file set does not meet the preceding conditions, restoration and replay might not necessarily fail, but you are likely to receive a -1216 error message (JET_errAttachedDatabaseMismatch) during soft recovery.
Dealing with a -1216 Error
Additional soft recovery safeguards in Exchange 2000 and later cause the -1216 error when Exchange detects data files that have been tampered with manually, and determines that running recovery with the current data set would result in the loss of previously existing data.
In earlier versions of Exchange, if the file set is incomplete, but is valid for a successful replay, soft recovery starts without further warning to the administrator. In Exchange 2000 and later, the administrator must specifically override the -1216 error by using Eseutil.
Point in Time Restoration of an Offline Backup
To perform a point in time restoration of an offline backup:
- If the database that you want to restore is currently mounted, dismount it. If any other databases in the storage group are dismounted, those databases' database and streaming files (.edb and .stm) must each be consistent and matched. (To verify consistency and matching, see step 2 in the "Backing Up an Exchange Database Offline" section of this article.)
If all of the databases in the storage group are dismounted, all of the databases must be consistent, and a valid checkpoint file must also exist. A valid checkpoint file is a checkpoint file that was in use the last time that any of the databases in the storage group were running, that has a header that lists E0n.log as the checkpoint. If any database in the storage group is still mounted, the valid checkpoint file is the checkpoint file currently being used by the system. If any database in the storage group is running, a valid checkpoint exists.
To verify the checkpoint file when all of the databases are stopped, run the following commands:eseutil /mk E0n.chk | FIND /i "checkpoint"
eseutil /ml E0n.log | FIND /i "lgeneration"
The following is an example of the output from the preceding commands:
D:\mdbdata>eseutil /mk e00.chk | find /i "checkpoint" Checkpoint file: e00.chk LastFullBackupCheckpoint: (0x0,0,0) Checkpoint: (0x2cc7,1B59,1A) D:\mdbdata>eseutil /ml e00.log |find /i "lgeneration" lGeneration: 11463 (0x2cc7)In the preceding example, the checkpoint is in the log with the lGeneration of 0x2cc7, which is e00.log. Therefore, the checkpoint can be considered valid.
If the checkpoint is not valid, you might receive a -1216 error message (JET_errAttachedDatabaseMismatch) when you attempt to mount any database in the storage group. This issue can occur even if all of the databases in the storage group are consistent.
- Copy the backed up .edb and .stm files to the appropriate database and streaming file locations. (To find these locations, refer to the "Before You Begin" section of this article.) Verify that the restored files are consistent and matched.
NOTE: If copies of the database files that you want to restore already exist on the server, back these files up before you restore the database, even if the existing files are not startable. They might be repairable, and you might be able to salvage data from them by using the Exmerge utility. - Mount the restored database. The database attaches itself to the end of the E0n.log file. After the database has been successfully started, no previously existing log files can ever be replayed into the database. Public folder databases that contain thousands of folders in the hierarchy may take a long time to start. Allow for at least one minute for every 1,000 folders in the hierarchy.
In earlier versions of Exchange Server, you usually needed to run the ISINTEG -patch command after you restored an offline backup of an information store database, to synchronize the information store database with the directory. When patching for an Exchange database is necessary, that patching is done automatically by the system, unless the database is restored to a different server, storage group, or logical database object, or the Active Directory object for the database has been deleted and re-created in Active Directory. In these cases, the following error message is logged in the Application event log. To resolve this problem, you must click to select the This database can be overwritten by a restore check box in Exchange System Manager, in the Database properties of the database object.
Roll Forward Restoration of an Offline Backup
For the best chance of complete success replaying log files into a restored database:
- Preserve a copy of all of the transaction logs that were created after the time of your oldest full backup.
- Do not change a database path without making a new full backup immediately afterward.
- Do not run ESEUTIL /p or ESEUTIL /d without taking a new full backup immediately afterward.
- Do not add or remove a database in a storage group without immediately making a full backup of all of the databases in the storage group.
To begin the restoration process:
- If the database that you want to restore is mounted, dismount it, and then copy the database files that you want to restore to the appropriate paths on the server. If copies of the database files that you want to restore already exist on the server, back these copies up before you restore the database, even if the existing files are not startable. The files may be repairable, and you may be able to use the Exmerge utility to salvage data from them.
- Dismount all of the databases in the storage group, and then run the following command against each database in the current storage group, and against each restored database file:
eseutil /mh
database_file_name| find /i "consistent"NOTE: Exchange 2000 Service Pack 2 and later do not report the database state as "Consistent" or "Inconsistent" but as "Clean Shutdown" or "Dirty Shutdown." The meaning of "Clean Shutdown" is the same as "Consistent", and the meaning of "Dirty Shutdown" is the same as "Inconsistent". For Exchange 2000 Service Pack 2 or later, run this additional command to determine the state of each database:
eseutil /mh database_name | find /i "Shutdown"
The following is an example of the output from the preceding command:
D:\mdbdata>eseutil /mh PRIV.EDB | find /i "consistent" State: Consistent Last Consistent: (0x2cc7,2692,1ED) 04/12/2001 20:07:46 I:\mdbdata<eseutil /mh PRIV.stm | find /i "consistent" State: Consistent Last Consistent: (0x2cc7,2692,1ED) 00/00/1900 00:00:00 E:\mdbdata>eseutil /mh PRIV2.edb | find /i "consistent" State: Consistent Last Consistent: (0x2cc7,2685,171) 04/12/2001 20:07:41 J:\mdbdata>eseutil /mh PRIV2.stm | find /i "consistent" State: Consistent Last Consistent: (0x2cc7,2685,171) 00/00/1900 00:00:00 F:\mdbdata>eseutil /mh PRIV3.edb | find /i "consistent" State: Consistent Last Consistent: (0x2ac8,87,1FC) 04/12/2001 20:05:04 K:\mdbdata>eseutil /mh PRIV3.stm | find /i "consistent" State: Consistent Last Consistent: (0x2ac8,87,1FC) 00/00/1900 00:00:00 G:\mdbdata>eseutil /mh PRIV4.edb | find /i "consistent" State: Consistent Last Consistent: (0x2cc7,268C,19B) 04/12/2001 20:07:43 L:\mdbdata>eseutil /mh PRIV4.stm | find /i "consistent" State: Consistent Last Consistent: (0x2cc7,268C,19B) 00/00/1900 00:00:00 H:\mdbdata>eseutil /mh PUB.EDB | find /i "consistent" State: Consistent Last Consistent: (0x2cc7,2699,181) 04/12/2001 20:07:46 M:\mdbdata>eseutil /mh PUB.stm | find /i "consistent" State: Consistent Last Consistent: (0x2cc7,2699,181) 00/00/1900 00:00:00This command has three purposes:
- To verify that the database files are each consistent.
- To verify that the .edb and .stm files for each database are a matched pair.
- To identify the low and high anchor log files, which are the first and last log files that are required to successfully recover all data without generating a -1216 error. The lowest last consistent value across all databases is the low anchor log and the highest last consistent value is the high anchor log.
- Verify that the log signature that is recorded in each database header is the signature of the low anchor log. Run the following commands:
eseutil /mh
database_name| find /i "Log Signature"eseutil /ml
low_anchor_log| find /i "Signature"The following is an example of the output from the preceding command:
D:\mdbdata>eseutil /mh priv.edb | find /i "Log Signature" Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer: E:\mdbdata>eseutil /mh PRIV2.edb | find /i "consistent" Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer: F:\mdbdata>eseutil /mh PRIV3.edb | find /i "consistent" Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer: G:\mdbdata>eseutil /mh PRIV4.edb | find /i "consistent" Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer: H:\mdbdata>eseutil /mh PUB.EDB | find /i "consistent" Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer: D:\exchsrvr\mdbdata\save>eseutil /ml e0002ac8.log | find /i "Signature" Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer: Signature: Create time:12/29/2000 21:6:40 Rand:67798 Computer: Signature: Create time:12/29/2000 21:6:41 Rand:58314 Computer:A log file may report several signatures. The first signature is always the log file's own signature; the rest are databases that were running at the time that the log file was created. In the preceding example, the log signatures that are recorded in the database files do match the log signature in the low anchor log.
If you cannot locate the low anchor log, you cannot play logs forward into that database. If you cannot find the low anchor log file, you cannot replay any log files into any databases. There are two methods that you can use to deal with a missing low anchor log:- You can remove all of the log files. Because the databases are all consistent, you can start them without the presence of any log files, but you lose any chance at recovering data that is not already in the database files.
- You can remove databases with the lowest last consistent values, until you can construct an unbroken log series from low to high anchors, and then run recovery on the remaining databases. When you put the removed databases back into the storage group, you cannot replay additional data into them.
- Verify that the current database path locations are the same as they were at the time that you made the backup.
Although you can change the transaction log path or working path after you make a backup, you can only perform log file replay if the database files are in the same places that they were backed up from. If you are unsure of the original locations, run the following command:eseutil /ml
"Last_Consistent"_log| find /i "database name or pattern"The following is an example of the output from the preceding command:
NOTE: If the low anchor log is E0n00001.log, it will not have path information in its header, because the header for the first log in a series is generated before the first database is ever attached to the log. In this case, you must look in the next log's header to view database path information. In rare cases, this may also be true for logs later than the first one, because a database was created or attached to the log stream after the log was created.N:\mdbdata>eseutil /ml e0002cc7.log |find /i ".edb" 1 f:\MDBDATA\PRIV3.edb 2 g:\MDBDATA\PRIV4.edb 3 d:\MDBDATA\PRIV.EDB 4 e:\MDBDATA\PRIV2.edb 5 h:\MDBDATA\PUB.EDB d:\mdbdata>eseutil /ml e0002cc7.log |find /i ".stm" streaming file: k:\MDBDATA\PRIV3.stm streaming file: l:\MDBDATA\PRIV4.stm streaming file: i:\MDBDATA\PRIV.stm streaming file: j:\MDBDATA\PRIV2.stm streaming file: m:\MDBDATA\PUB.stm - Gather all of the logs, from the low anchor number as far forward as possible in unbroken sequence, and copy these logs to the current transaction logs path. Do not overwrite logs that are already in place on the server without backing those logs up first. To do this, you may need to restore log files from more than one type of backup media.
In the preceding example, the low anchor is E0002ac8.log and the high anchor is E0002cc7.log. When you examine available logs, the highest numbered log that you can find might be one number less than the necessary number (for example, E0002cc6.log, instead of 2cc7). This usually occurs because the E0n.log has not yet been filled and renamed to its number in the sequence. To determine whether E0n.log is actually the high anchor log, you must use the following command to examine the lGeneration value in the log file header:eseutil /ml E0n.log | find /i "lGeneration"
The following is an example of the output from the preceding command:
N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration" lGeneration: 11463 (0x2cc7)NOTE: To view the header of a log file with the Eseutil utility, use the /ml switch; to view a database file header, use the /mh switch. If you confuse the switches, the output from the commands is incorrect.
Typically, the high anchor log is also the highest log available, but this is not true if:- Log files have been destroyed in a disaster.
-or- - You are restoring all of the databases at once in a storage group.
- Log files have been destroyed in a disaster.
- Verify that all of the logs share the same log signature and are in unbroken sequence. Run the following command:
eseutil /ml E0n > filename.txt
The following is an example of the output from the preceding command:
d:\mdbdata>eseutil /ml E00 > logverify.txt d:\mdbdata>type logverify.txt Microsoft(R) Exchange Server(TM) Database Utilities Version 6.0 Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved. Initiating FILE DUMP mode... Verifying log files... Base name: e00 Log file: D:\exchsrvr\mdbdata\save1\E0000001.log Log file: D:\exchsrvr\mdbdata\save1\E0000002.log Log file: D:\exchsrvr\mdbdata\save1\E0000003.log Log file: D:\exchsrvr\mdbdata\save1\E0000004.log Log file: D:\exchsrvr\mdbdata\save1\E0000005.log Log file: D:\exchsrvr\mdbdata\save1\E0000006.log Log file: D:\exchsrvr\mdbdata\save1\E0000007.log Log file: D:\exchsrvr\mdbdata\save1\E0000008.log Log file: D:\exchsrvr\mdbdata\save1\E0000009.log Log file: D:\exchsrvr\mdbdata\save1\E000000A.log Log file: D:\exchsrvr\mdbdata\save1\E000000B.log Log file: D:\exchsrvr\mdbdata\save1\E00.log No damaged log files were found. Operation completed successfully in 3.305 seconds.This Eseutil command does three things: checks each log file for damage, reports any gap in the log file sequence, and detects log signature mismatches.
All log signatures must match between all log files that are replay candidates. You must remove any logs that do not have matching signatures before replay begins.
At this point, after you remove the files that did not pass the verification tests, the only transaction log files in the Transaction Logs folder are files that:- Are in unbroken lGeneration sequence, starting with the low anchor log file and continuing up to at least the high anchor log file, and beyond that, if possible.
- Have matching log signatures.
- If the high anchor log is not already named E0n.log, rename it.
- Remove the E0n.chk file from the System Path folder.
In the absence of a checkpoint file, Exchange Server begins to replay the logs from the lowest numbered log file that is available in the Transaction Logs folder: the low anchor log. If the E0n.chk file exists, Exchange Server begins replay at the checkpoint that is recorded in this file. If E0n.chk points past the low anchor log, replay fails entirely for the restored file set. In many cases, if you make a mistake with the checkpoint file, you must start over restoring database files from backup. - As a final check before you mount the storage group, verify that:
- All of the database files are present in their running paths.
- The only log files in the running transaction log path are files that start from the low anchor log and continue at least to the high anchor log, with the highest available log named E0n.log.
- There is no E0n.chk file in the System Path folder.
- If the information store is not already running, start it, and then mount at least one database in the storage group. This causes soft recovery to run against all of the databases in the storage group.
In earlier versions of Exchange Server, you usually need to run the ISINTEG -patch command after you restore an offline backup of an information store database, to synchronize the database with the directory. When patching for an Exchange database is necessary, that patching is done automatically by the system, unless the database is restored to a different server, storage group, or logical database object, or the Active Directory object for the database has been deleted and re-created in Active Directory. In these cases, the following error message is logged in the Application event log. To resolve this issue, you must click to select the This database can be overwritten by a restore check box in Exchange System Manager, in the Database properties of the database object.
Check the Application event log in the Microsoft Windows NT Event Viewer for any errors or anomalies that might occur when the database starts. An event 301 is displayed for each log file that is replayed. Watch carefully for errors and warnings during the recovery process.
Dealing with Database Signature and Path Mismatches
Databases, like log files, have their own signatures. But although log signatures do not change after the time that the E0n000001.log file is created, database signatures change whenever the physical topology of the database is altered, without the changes being tracked through the log files. Offline defragmentation or repair of a database with Eseutil changes the DB signature. After such an event, the database can be attached to the same log stream as before, but the database does not accept replay of any transactions that were performed while the database had its earlier signature. An earlier copy of the database does not accept replay of any transaction that was performed after the database's signature changed.
Because database signatures are reset in this manner, you are strongly advised to make immediate full database backups after offline defragmentation or repair of a database. If you restore a copy of the database with the old signature later, replay succeeds up to the point of the signature change, but you lose all changes past that point.
If database paths are changed in the middle of a log stream, the effect is similar to that of changing signatures: replay is interrupted at the point of the change. (The online backup API provides a facility to remap paths during recovery; therefore, the online backup API can replay logs completely, even if a path has changed since the backup was taken.)
As DB signature or DB path issues are encountered during replay, those DB signature or DB path issues are reported in the Application event log in line with the 301 replay events for each log file. Log files that are past the point of the issue may appear to play successfully, but this is only because the same mismatch warning is not repeatedly logged. As a general rule, replay into a particular database is truncated from the point at which the first DB signature or path error referencing that database is encountered.
Additional query words: reviewdocid 0x3f3 3f3 exch2kp2w XADM
Keywords: kberrmsg kbhowto kbproductlink KB296788
