XADM: Making and Restoring Offline Backups

• Microsoft Exchange Server, version 5.5

SUMMARY

This article explains how to perform and restore offline backups.

IMPORTANT: Microsoft recommends that you back up Microsoft Exchange Server databases while the databases are running. These online backups provide two important benefits:

• You do not need to interrupt service. To perform an offline backup, you must shut down the database and interrupt service. Because the average size of information store databases is in the gigabyte range, service may be down for hours.



• If you use an online backup, Exchange Server automatically backs up all of the appropriate database files, and restores them correctly. To successfully restore an offline backup, you must know exactly what you are doing. You must rely entirely on your own understanding of the files that are important to back up, the files that must be restored, and the files that must NOT be restored. If you are wrong, you may replay inappropriate log files into your database, and irreparably damage it.

• An online backup checks the page-level integrity of the database files as they are streamed onto tape. You can perform the same check manually with the Esefile utility. (The use of the Esefile utility is described later in this article.)



• An online backup replays transaction logs into the database for "roll forward" restoration. Exchange Server can recover data created after the time that a backup was taken by applying subsequently created transaction log files to a restored database. If you restore an online backup, this replay is handled automatically. If you restore an offline backup, you must take great care to provide the correct files for replay, and to remove all of the other files that may interfere with replay.

Q147523 XADM: Enabling or Disabling Circular Logging

MORE INFORMATION

Before you perform an offline backup, you should first know the following:

• Whether or not circular logging is enabled.



• The path locations for your Exchange Server database files.

• The database files (the Priv.edb, Pub.edb, and Dir.edb databases).



• The transaction log files (the Edb*.log files).



• The working path files (the Edb.chk file is the only important one).

Backing Up an Exchange Server Database Offline

1. Stop the service for the database that you want to back up (either information store or directory service).



2. Verify that the main database files are consistent. The main database file for the directory service is the Dir.edb database. The main database files for the information store are the Priv.edb and Pub.edb databases. (Not all Exchange Server computers have both databases.) At a command prompt, run:

   eseutil /mh database name | find /i "State"

   Sample result:

   
   E:\exchsrvr\mdbdata> eseutil /mh priv.edb | find /i "State"
               State: Consistent 

   The database must be consistent before you back it up offline. If the database is inconsistent, it was not shut down cleanly. Restart the database, and then shut it down again. If the state is still inconsistent, contact Microsoft Product Support Services (PSS) for further assistance.



3. Note the number of the highest numbered transaction log file contained in the Transaction Logs folder. Exchange Server transaction log files are numbered hexadecimally, starting with the Edb00001.log file.



4. If you are backing up the information store, copy the Priv.edb database and the Pub.edb database to a backup location. If you are backing up the directory service, copy the Dir.edb database to a backup location.



5. Start the database services.



6. (Optional) If circular logging is enabled, skip this step. If circular logging is disabled, and you want to "roll forward" later, then you must back up all of the numbered transaction log files (the Edbxxxxx.log files) up to and including the numbered log file you noted in step 3 above. Do not back up the Edb.log, Res1.log, and Res2.log files.
   
   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 log files is required.
   
   After you back up the log files, you can delete them to reclaim disk space. Because you have already restarted the database, new numbered log files may have already been created.
   
   IMPORTANT: Do not delete any log files later than the one that you noted in step 3 above; this is critical.



7. (Optional) Verify the page-level integrity of the copied databases using the Esefile utility.
   
   The Esefile.exe file is available on the Exchange Server 5.5 Service Pack 3 compact disc (in the Support folder), or you can obtain it from PSS. The Esefile utility works for Exchange Server 5.0 or 5.5 databases.
   
   The Esefile utility command line for an Exchange Server 5.0 database is:

   esefile /x database name

   The Esefile utility command line for an Exchange Server 5.5 database is:

   esefile /s database name

   Sample result:

   
   E:\exchsrvr\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 seconds 

   Uninitialized pages are acceptable, but in a healthy database, there are 0 bad checksums and 0 wrong pages numbers.
   
   If a database does not pass the Esefile utility integrity check, your best option is to restore a previous backup that you know to be good. If such a backup is not available, consult PSS for advice on repairing or salvaging the database.

Restoring an Offline Backup of an Exchange Server Database

• "Point in time" restoration. No log files are replayed into the database. All of the data created after the backup was made is lost.



• "Roll forward" restoration. The log files created after the backup was made are played into the database. All or almost all of the data created after the backup was made can be preserved.

"Point in Time" Restoration of an Offline Backup

1. Stop all Exchange Server services, including the system attendant.



2. Move all of the files from all the data folders for the database you want to restore. For the information store, you usually need to empty all of the Mdbdata folders (there may be up to four of them) on all the volumes, and for the directory service, you must empty all of the Dsadata folders (there may be up to three of them). Move the existing data, rather than deleting it. The presence of the Edb.chk file, or any transaction log files, may prevent the restored database from starting, or may even damage it.



3. Restore the backed up database files (either the Priv.edb and Pub.edb databases, or the Dir.edb database) to the appropriate database folder. Do not restore any Edb*.log files. At this point, the only files present in the database folders are the main database files themselves.



4. Start the database service. If you are restoring an information store database, the database usually stops with an event 1087 or an error 1011. This is acceptable, and does not indicate a problem in the database. If this happens, at a command prompt, run:

   \exchsrvr\bin\isinteg.exe -patch

   This command resynchronizes the information store and the directory service. The patch process usually takes only a minute or two, even against a very large database.
   
   Start the database again.
   
   NOTE: Do not run the isinteg -patch command in anticipation of a startup problem, only run it after a problem actually occurs. In rare circumstances, if you run the isinteg -patch command before you start the database, you may damage the database.

"Roll Forward" Restoration of an Offline Backup

1. Identify the "anchor" log file, which is the first log file required to begin the replay of log data into the database. To do this, at a command prompt, run:

   eseutil /mh database filename | find /i "Consistent"

   For example:

   
   E:\exchsrvr\mdbdata>eseutil /mh priv.edb | find /i "Consistent"
               State: Consistent
     Last Consistent: (4815,7337,362)  8/6/1999 20:46:33
   
   E:\exchsrvr\mdbdata>eseutil /mh pub.edb | find /i "Consistent"
               State: Consistent
     Last Consistent: (4815,7337,400)  8/6/1999 20:46:34 

   You can calculate the anchor log file from the first value in parentheses on the "Last Consistent" line (4815, in this example). Convert this number from decimal to hexadecimal. Decimal 4815 is equivalent to hexadecimal 12CF. Because Exchange Server transaction log files are named Edbxxxxx.log, where xxxxx is five hexadecimal digits padded with leading zeroes, the first log file you need is the Edb012cf.log file.
   
   HINT: Start the Calc.exe utility to convert from decimal to hexadecimal. In the Calc utility, click View, and then click Scientific. Type a decimal number, and then click Hex to convert it.
   
   IMPORTANT: If you cannot locate the anchor log file, do not replay ANY log files into the database. If you skip the anchor log file and force replay to begin using a subsequent log file, you almost always irreparably damage the database. If the anchor log file is unavailable, follow the "Point in Time" restoration instructions above.



2. Verify that the current database path location is the same as it was at the time that you made the backup.
   
   Although you can change the transaction log path or working path after you make the backup, you can only perform log file replay if the database file itself is in the same path that it was in at the time that you made the backup. If you are unsure of the original location, at a command prompt, run:

   eseutil /ml anchor log | find /i "database name"

   For example:

   
   E:\exchsrvr\mdbdata>eseutil /ml edb.log | find /i "Priv.edb"
         1 e:\exchsrvr\mdbdata\priv.edb
   
   E:\exchsrvr\mdbdata>eseutil /ml edb.log | find /i "Pub.edb"
         2 f:\exchsrvr\mdbdata\pub.edb 

   In the example above, the original path location for the Priv.edb database is the E:\Exchsrvr\Mdbdata folder, and the original path location for the Pub.edb database is the F:\Exchsrvr\Mdbdata folder.
   
   NOTE: The Edb00001.log file creates its own header before it attaches a database for the first time, and thus it lacks database path information. The database path location for the database that was attached at the end of the previous log file is written to the Edb00002.log file, and to all subsequent log files.



3. Compile a list of log files that are candidates for replay. These log files may come from multiple backup sets and may include log files that are already on the Exchange Server computer. The list must start with your anchor log file and may continue as long as you can locate log files in unbroken numeric sequence.
   
   IMPORTANT: If the Edb.log file already exists in the transaction logs folder that you are restoring to, go to step 4. If the Edb.log file does not exist in this folder, go to step 5.



4. If the Edb.log file exists, copy it to the same folder that all the other replay candidate log files reside in. Then you must verify that the Edb.log file is actually the next log file in your sequence of log files.
   
   Each log file carries an internal number called the lGeneration that identifies its real position in the sequence of log files, regardless of the log file name. Be sure that the lGeneration number of the Edb.log file is one higher than that of the highest numbered log file that is a replay candidate. To verify this, if your computer is running Exchange Server 5.5 Service Pack 1 (SP1) or later, at a command prompt, run:

   eseutil /ml highest numbered log | find /i "lGeneration"

   and then run:

   eseutil /ml edb.log | find /i "lGeneration"

   For example:

   
   E:\exchsrvr\mdbdata>eseutil /ml edb00013.log | find /i "lGeneration"
         lGeneration (4828)
   
   E:\exchsrvr\mdbdata>eseutil /ml edb.log | find /i "lGeneration"
         lGeneration (4829) 

   NOTE: To view the header of a log file with the Eseutil utility, use the /ml switch, and to view a database file header, use the /mh switch. Confusing the switches gives you incorrect output from the commands. The /ml switch is not available for Exchange Server 5.0 or for Exchange Server 5.5 earlier than SP1.
   
   If the Edb.log file does not carry the correct lGeneration number, you must remove the Edb.log file.
   
   IMPORTANT: If you removed the Edb.log file, go on to step 5. Otherwise, go to step 6.



5. To replay transaction log files into an offline backup, there must be a log file named Edb.log. (This is not a requirement with online backups.) If the Edb.log file is unavailable, you must rename the highest available numbered log file Edb.log.
   
   CRITICAL NOTE: If you rename a log file Edb.log, all of the log files that have higher lGeneration numbers than the log file that you just renamed must be removed before you start the database. If you don't do this, the higher numbered logs become a "ceiling" that eventually blocks the creation of new log files, and causes the database to stop.



6. Verify that signatures match between the databases and log files.
   
   Each log file carries an identifying internal log signature, and each database carries its own DB signature. Logs and databases that belong together write their signatures to each other. For replay to be successful, signatures from the databases must match those found in the anchor log, and those in the anchor log must match all the subsequent logs.
   
   To match signatures between the databases and the anchor log, at a command prompt, run:

   eseutil /ml anchor log file | find /i "Signature"

   and then run:

   eseutil /mh database names | find /i "Signature"

   For example:

   
   E:\exchsrvr\mdbdata>eseutil /ml edb012cf.log | find /i "Signature"
         Signature: Create time:8/3/1999 17:37:42 Rand:710915685 Computer:
         Signature: Create time:8/3/1999 17:37:44 Rand:710961251 Computer:
         Signature: Create time:8/3/1999 17:37:47 Rand:710954626 Computer:
   
   E:\exchsrvr\mdbdata>eseutil /mh priv.edb | find /i "Signature"
        DB Signature: Create time:8/3/1999 17:37:44 Rand:710961251 Computer:
       Log Signature: Create time:8/3/1999 17:37:42 Rand:710915685 Computer:
   
   E:\exchsrvr\mdbdata>eseutil /mh pub.edb | find /i "Signature"
        DB Signature: Create time:8/3/1999 17:37:47 Rand:710954626 Computer:
       Log Signature: Create time:8/3/1999 17:37:42 Rand:710915685 Computer: 

   In the above example, the Edb012cf.log file carries three signatures: the first is its own log signature, the second is the DB signature of the Priv.edb database, and the third is the DB signature of the Pub.edb database. (The signature is the entire line, starting with "Create time," not just a part of each line.)
   
   The first signature from the Edb012cf.log file matches the log signature entry in both the Priv.edb and Pub.edb databases, the second signature from the Edb012cf.log file matches the DB signature for the Priv.edb database, and the third signature from the Edb012cf.log file matches the DB signature for the Pub.edb database. If you find any signature mismatch at this point, the anchor log belongs to an entirely different database, and no log file replay is possible. You must then perform a "point in time" restoration.
   
   After you verify that the anchor log matches the databases, you must verify that the rest of the log files match the anchor log. You can do this by comparing the signatures inside each log file. The following batch file can automate this verification. You must run it at a command prompt, from the Transaction Logs folder.
   
   The batch file is eight lines long, and has double spacing between each line.

   
   :sigchk.bat
   
   @echo off
   
   for %%A in (EDB*.LOG) do eseutil /ml %%A | find "Sig" >%%A.CHECK
   
   eseutil /ml %1 | find "Sig" >"Log Signature Check.txt"
   
   echo -------------------- >>"Log Signature Check.txt"
   
   echo -------------------- >>"Log Signature Check.txt"
   
   for %%A in (*.CHECK) do fc %1.check %%A >>"Log Signature Check.txt"
   
   start notepad "Log Signature Check.txt" 

   You must type the name of your "anchor" log file on the batch command line, for example:

   sigchk.bat edb012cf.log

   Output is similar to the following:

   
   Signature: Create time:8/3/1999 17:37:42 Rand:710915685 Computer:
         Signature: Create time:8/3/1999 17:37:44 Rand:710961251 Computer:
         Signature: Create time:8/3/1999 17:37:47 Rand:710954626 Computer:
   --------------------
   --------------------
   Comparing files edb012CF.log.CHECK and EDB012D0.LOG.CHECK
   FC: no differences encountered
   
   Comparing files edb012CF.log.CHECK and EDB012D1.LOG.CHECK
   FC: no differences encountered
   
   Comparing files edb012CF.log.CHECK and EDB.LOG.CHECK
   ***** edb012CF.log.CHECK
         Signature: Create time:8/3/1999 17:37:42 Rand:710915685 Computer:
         Signature: Create time:8/3/1999 17:37:44 Rand:710961251 Computer:
         Signature: Create time:8/3/1999 17:37:47 Rand:710954626 Computer:
   ***** EDB.LOG.CHECK
         Signature: Create time:8/2/1999 16:22:38 Rand:3070420 Computer:
   ***** 

   In the example above, the Edb012cf.log file is the anchor log. The signatures that it contains are listed above the short dashed lines. If the output file doesn't contain any signatures above these lines, then the comparisons are all invalid, usually because you mistyped the name of the anchor log.
   
   If the log files match the anchor log, there are no signatures listed below the double dashed lines, instead, there is just a steady string of "FC: no differences encountered" for each comparison. In the example above, the Edb.log file is mismatched in comparison with the Edb012cf.log file.
   
   At minimum, a signature mismatch prevents complete replay of all the log data into the database. Depending on the nature of the mismatch, it may also prevent the database from starting.
   
   The result of a signature mismatch depends on whether or not the mismatch is between log signatures or between DB signatures. If there is a log signature mismatch, the logs that don't match the signature of the anchor file must be removed, or they are likely to prevent the database from starting. There is no chance of replaying any data after a log signature mismatch.
   
   If the mismatch is between DB signatures, the database usually starts, but no data after the point of the mismatch is applied. If you restore both the Priv.edb and Pub.edb databases and both of the DB signatures are mismatched at the same point, remove the log where the mismatch was detected, along with all of the subsequent logs. If only one signature changes, you may still be able to replay data into the other database.
   
   A change in DB signature doesn't necessarily mean that a different database is attached to the log files. DB signatures change during the life of a database whenever the database is altered enough in its physical arrangement that the replay of log files would be dangerous. Offline defragmentation (the eseutil /d command) and hard repair (the eseutil /p command) are the two most common events that trigger a DB signature change.
   
   Be aware that even if you remove all of the log files from the point of the mismatch onward, you are still likely to see some errors in the application event log during replay. This is because the DB signature change actually happened in the middle of the log file that precedes the log file that the change was detected in. You don't want to remove this preceding log file, because some of the data in it (the data created before the signature change) is still playable, but an error may be displayed when the signature change is encountered.
   
   NOTE: If you remove log files because of signature problems, don't forget to rename your new highest numbered log file as Edb.log, as described in step 5 above.



7. Verify that the database paths in all the log files match.
   
   If the database paths are not all the same throughout the sequence of log files, the effect is much the same as if the DB signatures don't match; data in the log files after the point where the path changed are not replayed. (If you use an online backup, the database can be restored to an entirely different path than the one recorded in the anchor log, and log file replay still succeeds, as long as the paths don't change again in the middle of the log file sequence.)
   
   You can check for database path continuity using another batch file that is similar to the one you use to check signatures. This batch file is also eight lines long, and has double spacing between each line:
   

   
   :pathchk.bat
   
   @echo off
   
   for %%A in (EDB*.LOG) do eseutil /ml %%A | find "%2" >%%A.CHECK
   
   echo -------------------- >>"Log Signature Check.txt"
   
   echo -------------------- >>"Log Signature Check.txt"
   
   eseutil /ml %1 | find "exchsrvr">>"Database Path Check.txt"
   
   for %%A in (*.CHECK) do fc %1.check %%A >>"Database Path Check.txt"
   
   start notepad "Database Path Check.txt" 

   The output format from this batch file is similar to the previous one, but it displays paths, not signatures.
   
   If path verification reveals a mismatch, you must make the same judgments that you make if DB signature verification reveals a mismatch.
   
   At this point, you have a folder that contains only log files that:



• Are in unbroken lGeneration sequence, starting with the anchor log file.



• Have matching log signatures; this is an absolute requirement.



• Have matching DB signatures (or you have decided to take the risks associated with trying to replay mismatched logs).



• Have matching database paths (or you have decided to take the risks associated with replaying mismatched logs).



Even if you meet all four of these requirements exactly, there is still a small chance that the log set you have put together is not a valid one. Fortunately, such cases are rare.


8. Move all of the files from all of the data directories for the database that you want to restore. For the information store, empty all Mdbdata folders on all volumes, and for the directory service, empty all Dsadata folders. Move existing data, rather than deleting it. Make sure that you do not delete any log files that are replay candidates, and that you remove the Edb.chk file.



9. Copy all of your replay candidates, including the appropriate Edb.log file, into the Transaction Logs folder.



10. Copy the databases that you want to restore into the Database folders.



11. Be absolutely sure that the Edb.chk file has been removed from the Working Path folder.
    
    In the absence of a checkpoint file, Exchange Server begins to replay the logs from the lowest numbered log file available: the anchor log. If the Edb.chk file exists, Exchange Server begins replay at the checkpoint recorded in it. When you restore an offline backup, the checkpoint in the Edb.chk file is wrong. A bad checkpoint file prevents log file replay altogether, at best. At worst, it irreparably damages the database.
    
    At this point, the only files present in the Database folders are:



• The restored databases.



• The restored sequence of log file replay candidates, including an Edb.log file that you have made sure is the final log in the sequence.



12. Start the database service. If the information store does not start and returns a 1087 event or a 1011 error, at a command prompt, run:
    

    \exchsrvr\bin\isinteg.exe -patch

    This resynchronizes the information store with the directory service, and then starts the information store service again.
    
    Check the application event log in the Windows NT Event Viewer for any errors or anomalies that may occur when the database starts. There is an event 109 displayed for each log file that is successfully replayed. After a signature or path mismatch error is encountered during replay, succeeding log files are still logged as having been replayed, but the data they contain is not actually applied to the database.

Notes

• If the database is inconsistent, you can safely remove a log file only if it did not exist at the time that the database stopped.



• If you rename a log file to Edb.log, you must remove all of the log files with higher lGeneration numbers. If a log file with a higher lGeneration number was in existence at the time that the database stopped, and if you remove it, you are in violation of the previous rule. If a database won't start again after an abnormal stop, and you suspect the problem is in the Edb.log file, you cannot remove the Edb.log file and rename the next higher numbered log. You must either restore the database from a backup, or repair the database.



• If you rename a log file to anything but Edb.log, the name must be consistent with the naming standard for log files, and with the internal lGeneration value of the log.

Additional query words:

Keywords : exc55
Version : winnt:5.5
Platform : winnt
Issue type : kbhowto