DOCUMENT:Q237767 09-JUL-2002 [exchange] TITLE :XADM: Understanding Offline and Snapshot Backups PRODUCT :Microsoft Exchange PROD/VER::5.5 OPER/SYS: KEYWORDS:exc55 ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Exchange 2000 Server - Microsoft Exchange Server, version 5.5 ------------------------------------------------------------------------------- SUMMARY ======= This article provides information about snapshot backup solutions for Exchange, although this article does not address any vendor's specific implementation. This article also provides information about making emergency offline backups of Exchange data if your usual online backup solution is not functioning. This article contains the following sections: - General Snapshot and Offline Backup Information - Exchange Server 4.0, 5.0, and 5.5 Offline Backup and Restoration Summary - Backing Up a Database - Restoring a Database Without Playing Logs Forward - Restoring a Database and Playing Logs Forward - Exchange 2000 Server Offline Backup and Restoration Summary - Backing Up a Database - Restoring a Database Without Playing Logs Forward - Restoring a Database and Playing Logs Forward MORE INFORMATION ================ General Snapshot and Offline Backup Information ----------------------------------------------- Microsoft has provided a backup application programming interface (API) for Exchange that enables you to backup databases while the databases are running, which avoids interruptions of service. Many third party backup software vendors have implemented this API through add-on software agents or modules. NOTE:If you install the Exchange Server Administrator program or Exchange System Manager on a server, the Windows NT Backup utility that is included with Microsoft Windows NT and Microsoft Windows 2000 is automatically extended to support Exchange online backups. The online backup API automatically backs up all of the required database and log files. The administrator that performs the backup does not need to know the names or path locations of the Exchange files that the administrator needs to back up. During restoration, the administrator must specify the server, and then the restoration API performs the necessary steps to return all of the files to their proper paths, even if file locations have been changed in the interim. After the backup, if all of the transaction logs that were generated by the database that were taken are still available, the restoration API "replays" newer transaction logs into the restored database, which brings the restored database completely up to date. This procedure is known as a "roll forward" restoration. To preserve all of the transaction logs, you must disable circular logging. By default, circular logging is enabled for all versions of Exchange Server that are earlier than Exchange 2000 Server. For additional information about circular logging, click the article numbers below to view the articles in the Microsoft Knowledge Base: Q147523 XADM: Enabling or Disabling Circular Logging Q258470 XADM: How to Modify the Circular Logging Setting By manually backing up the appropriate files, an Exchange administrator can achieve the same overall effect as the online backup API, except that the administrator cannot perform backups while the database is running. It is even possible to replay log data after you restore these backups. Some commercial Exchange backup solutions deliberately bypass the Exchange backup API and take a "snapshot" of the database by stopping it and by copying database and transaction files to a backup location. These backups are commonly known as "offline" or "snapshot" backups. The primary advantage of a commercial snapshot backup solution compared to an online backup solution is the speed of restoration. Typically, snapshot backup solutions are integrated with specialized hardware that can both back up and restore very large files almost instantaneously. Snapshot solutions do require that you stop the database to perform the backup, however, the length of the outage is usually only seconds or minutes. Regardless of particular vendor implementations, the fundamental principles involved in making offline backups of Exchange data are the same. If you are considering a commercial snapshot backup solution for Exchange, this article provides insight into how the process works. The procedures in this article are also valuable if you need to make emergency offline backups of Exchange data because an online solution is unavailable. Supportability of Offline and Snapshot Backup Solutions: Microsoft recommends backing up and restoring Exchange data through an application that implements the online backup API for the following reasons: - The API ensures that all of the relevant files are backed up. - The API implements several checks and safeguards during backup and restoration. - The API has been thoroughly tested. This does not mean that you cannot perform offline and snapshot backups safely and successfully. However, it is up to the backup solution vendor or Exchange administrator to ensure that all of the needed files are backed up and restored correctly, and that the integrity of all files is preserved at each stage of the process. If you implement a snapshot or offline backup solution for Exchange, your vendor is the primary provider of support for backup and recovery problems. Microsoft Product Support Services (PSS) can assist you with diagnosing or analyzing problems with the available database and transaction log file set, but Microsoft does not test, certify or debug scripts and procedures for offline or snapshot backups of Exchange data files. Microsoft PSS assistance is limited to advice about how to best proceed with the available file set. Microsoft strongly recommends use of Exchange Server 5.5 Service Pack 2 or later if you intend to regularly implement offline backups. Cautions and Considerations for Offline and Snapshot Backups: Making and restoring offline backups can be simple if you do not intend to replay newer transaction logs into a restored database. However, if you skip log replay, all of the data that was generated after the backup is lost. The online backup paradigm assumes that Exchange administrators will not manually add, delete, rename, or replace files in the Exchange data set (in other words, that the administrator will let the backup and restoration process take care of all file manipulation and log file purging). The administrator's responsibility is simply to decide whether circular logging should be enabled or disabled, and then to make regular backups of Exchange data. If data must be restored, transaction log replay occurs automatically and safely based on the available file set. The online backup API verifies that the necessary files are available, safely merges data from tape with the existing data set, and automatically performs recovery. When an administrator works with an offline backup, all of this management and verification of files becomes entirely the responsibility of the administrator. Verifying that the file set that you restored is ready for log file replay is the most complicated part of managing offline backups. Although the fundamental principles of backup and restoration are the same across all versions of Exchange, Exchange 2000 adds some complicating factors because Exchange 2000 supports multiple independent databases. An Exchange 2000 server can support up to 20 databases, organized in up to four separate storage groups, with each storage group supporting a separate set of transaction logs. Each of these 20 databases can be stopped or started independently. In Exchange 2000, when you restore files into a storage group you must take extra care not to disturb the files that are in use by other databases in the storage group. You might be restoring a single Exchange 2000 database into a storage group that has several other running databases that are no longer synchronized with the restored database. In earlier versions of Exchange Server, there is a single storage group on each server, which supports a maximum of two databases (a private information store and a public information store). You must ensure that you stop and start both of these databases together. For the purposes of an offline backup, you can treat these databases as if they are a single database: they are stopped and started together, and backed up and restored together. For additional information about managing offline backups, click the article numbers below to view the articles in the Microsoft Knowledge Base: Q296788 XADM: Offline Backup and Restoration Procedures for Exchange 2000 Server Q296787 XADM: Offline Backup and Restore Procedures for Exchange Server 4.0, 5.0, and 5.5 There is significant overlap and duplication in these two articles. This is deliberate, to make it easy to contrast and understand the differences between procedures for the different versions of Exchange. The rest of this article provides an overview of offline backup and restoration procedures. The articles listed earlier provide detailed explanatory information about each of the steps. Exchange Server 4.0, 5.0, and 5.5 Offline Backup and Restoration Summary ------------------------------------------------------------------------ Backing Up a Database: To back up a database: 1. Stop the database service. 2. Verify that the database files are consistent. 3. Copy the .edb files to the backup media. 4. Restart the database service. 5. If circular logging is enabled, back up all of the numbered transaction log files, but not the Edb.log file. 6. If circular logging is disabled, purge backed up log files that are older than the checkpoint. 7. Use the Esefile /x command (for Exchange Server 5.0) or the Esefile /s command (for Exchange Server 5.5) to verify the page-level integrity of the backed up .edb files. Restoring a Database Without Playing Logs Forward: To restore a database without playing logs forward (a "point in time" restoration): 1. Stop the database service and then move--do not delete--the checkpoint file and all of the transaction log files. 2. Restore the consistent .edb files. 3. Start the database service, and if you receive an error message that instructs you to run the ISINTEG -patch command, do so. Restoring a Database and Playing Logs Forward: To restore a database and play logs forward: 1. Stop the database service, and then copy the backed up database files that you intend to restore to the current database paths. 2. Verify database file consistency, and then identify the anchor log file (the lowest "last consistent" log) by running the ESEUTIL /MH command against each database. If the anchor log is not available, you cannot play logs forward. WARNING: If you try to play logs forward without the anchor log, you irreparably damage the database. 3. Verify that the log signature that is recorded in each database header is the signature of the anchor log. Use the ESEUTIL /ML command and the ESEUTIL /MH command to compare header information. 4. Verify that the current database path locations are the same as they were at the time you made the backup by examining the log file headers with the ESEUTIL /ML command. 5. Gather logs, starting with the anchor log and going as far forward as possible with an unbroken numeric sequence, and then copy these logs to the current transaction logs path. Do not overwrite existing logs on the server. 6. If an Edb.log file already exists on the server, use the ESEUTIL /ML command to examine the lGeneration value to determine whether that Edb.log file is the next log in sequence. If that Edb.log file is not the next highest log, you must remove that Edb.log file. 7. If no Edb.log file is available, rename the highest numbered log file to Edb.log. 8. Verify that all of the logs present in the transaction logs path share the same signature. 9. Remove the Edb.chk file from the Working Path folder. 10. Make a final check: Are all of the database files present and in the correct locations? Are the only log files present an unbroken series of log files that share the same signature from the anchor log to the highest log, which has been renamed Edb.log? Has the checkpoint file been removed? WARNING: If you do not remove the checkpoint, you may irreparably damage the database. 11. Start the database service, and if you receive an error message that instructs you to run the ISINTEG -patch command, do so. Exchange 2000 Server Offline Backup and Restoration Summary ----------------------------------------------------------- NOTE: The current log file for a storage group is generically referred to in these instructions as E0n.log, where 0n can be 00, 01, 02 or 03. Backing Up a Database: To back up a database: 1. Dismount the database that you want to back up. 2. Run the ESEUTIL /MH command to verify that the database files (.edb and .stm) are both consistent and matched to each other. 3. Copy each .edb database file and its corresponding .stm streaming database file to the backup media. 4. Mount the backed up databases. 5. If circular logging is disabled, back up numbered transaction log files, but not E0n.log. 6. If circular logging is disabled, purge any backed up log files that are older than the checkpoint. 7. Use the Esefile /s command to verify the page-level integrity of the backed up .edb files. 8. Use the Eseutil /ml E0n command to verify the integrity of the backed up log files. Restoring a Database Without Playing Logs Forward: To restore a database without playing logs forward: 1. Dismount the database that you want to restore. If any other databases in the same storage group are also dismounted, the database files must be consistent and matched. If all of the databases are dismounted, there must be a valid checkpoint file (E0n.chk) that points to E0n.log. 2. Copy the matched and consistent .edb and .stm files for the backup databases into the appropriate locations. 3. Mount the restored databases. Restoring a Database and Playing Logs Forward: To restore a database and play logs forward: 1. Dismount the databases that you want to restore, and then copy the backed up database files into place on the server. 2. Dismount all of the databases in the storage group, and then run the ESEUTIL /MH command to verify that all of the files are consistent and matched, and to determine the low and high anchor logs that are required (the lowest and highest Last Consistent values from the database headers). 3. Verify that the log signature that is recorded in each database header is the signature of the low anchor log. Use the ESEUTIL /ML command and the ESEUTIL /MH command to compare header information. 4. Examine the header information in the last consistent log for each database to verify that the current database path locations are the same as they were at the time that you made the backup. 5. Gather all of the logs from the low anchor to the high anchor, and then copy the logs to the current Transaction Logs folder. Remember that the high anchor log is often named E0n.log, and you must examine the lGeneration value in the log's header to discover its place in the sequence. You can also use log files past the high anchor log, as long as they continue in unbroken sequence. 6. Run the ESEUTIL /ML E0n command to verify that all of the logs share the same log signature and are in an unbroken sequence. 7. If the high anchor log is not already named E0n.log, rename it E0n.log. 8. Remove the E0n.chk file from the System Path folder. 9. Make a final check before you mount the storage group: Are all of the database files present in the appropriate paths? Are the only log files present log files that share the same signature, in an unbroken sequence starting with the low anchor log, with the highest log named E0n.log? Has the E0n.chk file been removed from the System Path folder? 10. Mount the databases in the storage group, in no particular order. You may receive a -1216 error message during the restoration of an offline backup. This means that some data that was present at the time that the storage group was last stopped is missing. For additional information about handling -1216 error messages during a soft recovery of an Exchange storage group, click the article number below to view the article in the Microsoft Knowledge Base: Q296843 XADM: Error -1216 Recovering an Exchange 2000 Database Additional query words: 0x3f3 3f3 ====================================================================== Keywords : exc55 Technology : kbExchangeSearch kbExchange550 kbZNotKeyword2 kbExchange2000Search kbExchange2000Serv Version : :5.5 Issue type : kbhowto ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2002.