The following 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 (http://support.microsoft.com/kb/296787/EN-US/) XADM: Offline Backup and Restoration Procedures for Exchange Server 4.0, 5.0, and 5.5

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_group object 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 the storage_group object 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)

LDIFDE -F EXPATHS.TXT -D

D:\exchsrvr\mdbdata>ldifde -f con -d "cn=configuration,dc=test,dc=com" -l msexch

msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

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.

To back up an Exchange database offline:

1. 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.
2. 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:00

   In 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 /mk E0n.chk
   eseutil /ml [log file] | find /i "lGeneration"

   The following is an example of the output from the preceding command:

   E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration"

   Generation: 11463 (0x2CC7)

   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.

   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.

   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.
   In this example, you can remove all of the logs up to E0002cc6.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_name

   The following is an example of the output from the preceding command:

   E:\mdbdata>esefile /s priv.edb

   23042 pages seen
   0 bad checksums
   241 uninitialized pages
   0 wrong page numbers
   esefile completes successfully after 10 seconds

   Uninitialized 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 E00

   You 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.

The information in this article applies to:

• Microsoft Exchange Server 2003 Enterprise Edition
• Microsoft Exchange Server 2003 Standard Edition
• Microsoft Windows Small Business Server 2003, Premium Edition
• Microsoft Windows Small Business Server 2003, Standard Edition
• Microsoft Exchange 2000 Server