Article ID: 272234 - View products that this article applies to.
This article was previously published under Q272234
This article provides a general overview of best practices for maintenance, backup strategy, and disaster recovery for Exchange server.
Hardware Management and MaintenancePlanning for your Exchange Server system involves several issues. Among these issues are server selection, disk configuration, and disk management and maintenance.
Planning and Configuring ServersBecause Exchange databases must be capable of fast access to large amounts of information, server performance and reliability must be your primary concerns when you select hardware for your databases. High-quality components minimize the likelihood of data loss. Hardware that is too slow to support the load on your server slows down your entire system.
Note that you should be skeptical of manufacturers' performance benchmarks. Original equipment manufacturers typically use RAID 0 when they test. You should use RAID 5 or RAID 1 for database partitions to ensure the greatest reliability.
Use RAID controllers that have write caching with ECC memory protection and battery backup.
Optimizing Database AccessFor servers that support large information stores--stores that are 50 to 100 gigabytes (GB) in size--it is especially important to follow these guidelines.
Managing Disk CapacityWhen you are planning your Exchange Server system, one important issue is determining how much disk space you need to allow for the information stores. Unless you take a conscientious approach to capacity management, the size of your information store databases can quickly get out of control.
Set a maximum information store size, and then manage the information store within those limits. You can get a good idea of how big your databases will grow by setting mailbox quotas and then tracking the growth of the information store over time. Allow enough free space to support the messaging needs of the users on the server, but set mailbox storage limits so that users do not consume excessive amounts of disk resources.
Also, plan for how you would handle an oversize information store if that situation arises, including contingency plans for reclaiming disk space or adding extra disks to support your server's load. Allow enough space on the system to let you run the Eseutil and Isinteg utilities if you need to. As a general rule, plan to have approximately 25 to 30 percent extra disk space for these utilities.
Defragmenting the DatabaseOne of the most important functions that the information store performs during regular online maintenance is reclaiming unused database space by defragmenting the database.
This feature has been fine-tuned since Exchange 5.0. Exchange 5.5 Service Pack 1 includes a reporting tool that provides, in the event log, an estimate of how much free space is available in the information store after online defragmentation. This makes it much easier to estimate how much disk space is needed.
The event log shows when online defragmentation starts, stops, resumes, and finishes. When you back up the information store or perform an offline defragmentation, check the event log to make sure you are not overlapping with an online defragmentation. (However, note that if online defragmentation is interrupted, the information store resumes the process as soon as possible.)
Online defragmentation does everything that you need it to do except shrink the size of the database files on the disk. If you make major changes to the Exchange Server computer (for example, if you move or delete a large number of mailboxes or remove a large number of newsgroups), consider performing an offline defragmentation by running the Eseutil utility with the /d option.
Generally, however, avoid offline defragmentation because it is an expensive procedure. When offline defragmentation runs, it creates a new database file and then copies all the data in the old file to the new file, which can take a long time. On average, it takes about one hour to defragment 5 to 10 GB of disk space. Also, you need enough free space for the offline defragmentation process to hold the new file. As a general rule, you should have 100 percent more free space than the amount you are defragmenting.
Backup StrategyDesign a backup strategy that consists of simple procedures that have as few steps as possible so that you can easily perform those same steps whenever you need to restore data on a server.
The recommended backup strategy for Exchange Server is to perform full online backups every day. Performing a full backup only once a week and then performing only differential backups the rest of the time has definite drawbacks. For example, if your Exchange Server computer stops responding (crashes) sometime before your scheduled full backup, and you cannot restore your latest differential backup because of a problem with the backup tape, you must use the full backup from the previous week, and you will almost certainly lose data.
Optimizing Backup and Restore PerformanceThe real limiting factor when it comes to building large servers is, how fast can you back up data, and more important, how fast can you restore it? To get the best performance from the backup and restore process, use high-performance backup software along with the fastest backup hardware you can get.
The following list identifies a few of the many vendors who provide high-performance backup software that works with Exchange Server:
Maintenance RoutineImplement a maintenance routine that enhances the likelihood of successful data recovery in the event of an emergency.
As part of this routine, store your backup tapes in a safe place. Clean the tape drives regularly, as recommended by the tape drive manufacturer, and discard old backup tapes according to the manufacturer's recommended cycles. Regularly test your backup procedures and verify the quality of your backups to make sure that you are backing up the system accurately.
Practice your backup and restore procedures regularly:
Disaster RecoveryIf a system crash causes loss of data that is in memory or if software or hardware failure causes corruption in the contents of a database, you may need to recover data. Typically, you can repair damage from a system crash by performing a "soft recovery" when you restart the server. Software or hardware failure can require a restore from backup.
Soft RecoveryA soft recovery is a process that runs automatically when you try to start the information store after a system failure. Soft recovery uses the log files and database files on the disk instead of using tape backup.
If your server crashes and the contents of memory are lost, the database file on disk is flagged as inconsistent. Before you can restart the Exchange Server computer, the database must be consistent. Exchange Server simulates a clean shutdown by replaying pages from the log files on disk into the information store databases. This process involves the following steps:
Restoring from Online BackupIf soft recovery does not work or if there is a more serious problem within the system, you need to restore from backup.
The process for restoring from an online backup is similar to soft recovery. Exchange Server makes sure that all of the files are put in the right place and brings the database up to a consistent state. The following steps describe the process:
Typically, replaying a transaction log file takes between 30 seconds and four minutes. The replay speed varies according to the type of transactions that must be replayed. For example, it takes the information store longer to replay log files that have a lot of small delete operations or attachments. You can test your log files to get a more accurate estimate of how long it takes to roll forward the transaction log files on your system.
Restoring Individual Items in a MailboxSometimes users delete messages but later realize that they should not have deleted them. Because Exchange Server handles backup and restore procedures at the physical page layer, not at the mailbox level, you cannot easily restore individual messages in a mailbox from backup. Some third-party backup programs do allow you to do a "brick backup"; however, they do not use the Exchange Server backup and restore application programming interfaces (APIs) and typically do not perform as well as backups at the physical page layer do.
However, there is a way for users to recover messages that they have deleted from a mailbox without having to resort to backups. The Recover Deleted Items feature that comes with Exchange Server 5.5 lets a user retrieve messages from the Deleted Items folder in Outlook if you enable the feature on the server. Note that if you do enable the Recover Deleted Items feature, the server will require additional disk resources to store the deleted items.
In a future release, Exchange Server will be extended to allow applications to recover messages even after they have been permanently deleted from the system.
Managing and Maintaining Your DatabasesYou may already know that the information store in Exchange Server 5.5 is designed to run almost forever. For this reason, you rarely need to turn off your server to perform regular maintenance.
Except for performing backups, Exchange Server automatically takes care of all database maintenance while the server is online. Most of these activities occur as background processes during regular information store maintenance. The information store typically runs online maintenance at night and performs important tasks such as Deleted Item cache processing, general cleanup, and online defragmentation.
Key MessagesThese are the key messages that you should take away from this white paper:
Article ID: 272234 - Last Review: October 27, 2006 - Revision: 3.2
Retired KB Content Disclaimer
This article was written about products for which Microsoft no longer offers support. Therefore, this article is offered "as is" and will no longer be updated.