How to protect Exchange data from hard disk failure (328794)

MORE INFORMATION

To protect the data that resides on Exchange hard disks, you must consider the following:

• Available hard disk space
• Transaction log and Exchange database file locations

Available Hard Disk Space

Make sure that you have enough hard disk space on servers that are running Exchange so that you can recover all the data if you have to. You must have enough hard disk space to restore both the database files and the log files to their original locations. A full weekly backup and six days of incremental backups may require more free hard disk space than you have available to perform a database restoration. The number of log files that are generated in a week affects whether there is enough available hard disk space to complete the restore process. For example, if one of the servers generates 2,000 log files in one week, you must have 10 gigabytes (GB) of log file space, in addition to the space that you must have for the database, to complete a full backup.

You may also want to take the following steps:

• Perform a full backup daily to reduce the hard disk space that you must have to restore your Exchange databases. Full backups delete the previous transaction log files, and as a result, a daily full backup ensures that you never have to restore more than one day's log files.
• Do not let the hard disks that contain your Exchange database files (files that have .edb and .stm extensions) and log files become more than half full. Although you will have unused hard disk space, you reduce the chances that you will experience extended server downtime for the following reasons:
  • You can restore databases to hard disks that are half full faster than you can restore databases to hard disks that are full (especially if the file system is fragmented).
  • If a hard disk is half full, you can perform offline defragmentation and other maintenance duties on the same physical hard disk. It takes much longer to copy database files to and from a separate server for maintenance than it does to copy database files to a temporary directory on the same physical hard disk.
  • If a hard disk is half full, you can quickly make a copy of the damaged database files and log files to the same physical hard disk before you try to restore the files from a backup. It is helpful to have a copy of the damaged database files and log files if you experience problems during the restore process, for example, if the backup you try to restore contains errors. If the restore process is unsuccessful, you can sometimes use the copy of the damaged database and log files to repair the Exchange database. For this reason, move or copy the current database and log files (even if they are damaged) before you restore a database.

Note Because of the size of the average database, if you copy your current database to a different physical hard disk or to another server, it is likely to add several hours to your downtime. If you have enough hard disk space on the same physical hard disk to do so, move the current database files to another folder by using either the command prompt or Microsoft Windows Explorer before you perform the restoration. To save substantial time, use the Move command instead of the Copy command.

Transaction Log and Database File Locations

To provide fault tolerance in case a hard disk fails, keep your Exchange transaction log files and database files on separate physical hard disks. If you keep these log files and database files on separate hard disks you can significantly increase hard disk I/O performance.

Note To provide fault tolerance in case a database must be restored, each storage group has its own set of transaction log files. Transaction log files maintain a record of every change to every database in that storage group. Transaction log files are not deleted until a full backup is made of all the databases in a storage group.

The following examples describe how to recover data even in extreme circumstances (such as the loss of a hard disk that contains either your database files or your transaction log files) if you have a backup and your transaction log files are on a separate disk.

• If the hard disk that contains your database files fails, you can replace the failed hard disk, restore the most recent backup of the database files, and then use the current log files that were stored on a separate hard disk to restore the data on your Exchange server and bring it up to date to the time at which the hard disk failed.
• If the hard disk that contains your transaction logs fails, but the hard disk that contains your database files is functional and the database store file was gracefully closed, you may be able to repair the failed transaction log disk and remount the database store. If the database store file did not close gracefully, it will remain in an inconsistent state and may only mount after a hard repair by using the Eseutil.exe utility. This may cause some lost data. The other option is to restore the database store file from a backup. The restored database store file will not include new mailbox data that was created after the time of the backup.

Important If you keep your Exchange databases and transaction log files on the same physical hard disk, and that hard disk fails, you lose the data that was created after your last backup.

You can increase the fault tolerance of your Exchange organization if you keep each of your Exchange storage groups on a separate physical hard disk. When each storage group is located on a separate hard disk, if one hard disk fails, you only have to restore the failed Exchange storage group as shown in the following table. You can create even more fault tolerance if you keep each individual information store database file and each storage group's log files on a separate physical hard disk.

Table: Exchange 2000 Server
------------------------------------------------------|
Windows 2000                    Exchange 2000         | 
and other                       and pagefile          |
programs                                              |
------------------------------------------------------|
                                                      |
Storage Group 1                 Storage Group 2       |
Databases - Log files           Databases - Log files |
                                                      |
------------------------------------------------------|
Storage Group 3                 Storage Group 4       |
Databases - Log files           Databases - Log files |
                                                      |
------------------------------------------------------|