Exchange Server Setup Recommendations

This Article apply's to Exchange Server versions 2000 - 2003:

To provide fault tolerance in the event of a hard disk failure, keep your Exchange 2000 transaction log files
and database files on separate physical hard disks. Furthermore, if you keep these log files and database
files on separate disks, you significantly increase hard disk I/O performance.

Note: To track the operations made on every database within a storage group, each storage group has its
own set of transaction log files. Transaction logs maintain a sequential record of every operation that is
performed on a database. Transaction logs are not deleted until a Normal or Incremental backup is
performed for all the databases in a storage group.

If you lose the hard disk containing the Exchange 2000 databases, you can replace the damaged disk, and
then restore the most recent databases backups. After you restore the databases, an automatic log file replay
of all transactions that occurred after the backup transfers the recorded transactions from the log files to the
databases on disk. This process is known as hard recovery.

If you lose the hard disk containing the transaction logs, but not the disk containing your databases, you do
not have to restore any Exchange 2000 data from backup. However, losing the hard disk containing the
transaction logs is more dangerous than losing the hard disk containing the databases because you cannot
replay transactions that are recorded to log files but not recorded to the physical database files on disk. This
increases the chance of losing data that is not preserved in either the log files or in the last backup. When
the databases are unmounted, the transactions in memory are written to the databases on disk to make them
current. After you replace the damaged disk and restart the server, the Exchange Information Store service
(Store.exe) starts, and the databases that are stored on the undamaged disk are updated when the committed
transactions in memory are written to the databases. Then, a new series of log files is created for recording
future transactions. After this event, you should immediately create a new normal backup of any storage
group that lost its log files. This new normal backup backs up the databases that no longer have log files,
thereby preserving the transactions that were made since the last Normal backup. Important If you keep
your Exchange 2000 databases and transaction log files on the same physical hard disk and that disk fails,
you can recover only the existing data up to your last backup. Furthermore, you can minimize the time it
takes to recover from a hard disk failure if you keep each of your Exchange 2000 storage groups on a
separate hard disk. If only one disk fails, and you have each storage group located on a separate physical
hard disk, you need only to restore the storage group that is kept on the failed disk.

By using a redundant array of independent drives (RAID), you can increase the fault
tolerance of your Exchange 2000 organization. RAID stores identical data on multiple disks for
redundancy, improved performance, and increased mean time between failures (MTBF). In a RAID
configuration, part of the physical storage capacity contains redundant information about data stored on the
hard disks. The redundant information is either parity information (in the case of a RAID-5 volume), or a
complete, separate copy of the data (in the case of a mirrored volume). The redundant information enables
data regeneration if one of the disks or the access path fails, or if a sector on the disk cannot be read.

To ensure that your servers running Exchange 2000 continue to function properly in the event of a single
disk failure, you can use disk mirroring or disk striping with parity on the hard disks within your Exchange
2000 organization. Disk mirroring and disk striping with parity allow you to create redundant data for the
data on your hard disks. Although disk mirroring creates duplicate volumes that can continue functioning if
the disk being mirrored fails, disk mirroring does not prevent damaged files (or other file errors) from being
copied to mirrored volumes. For this reason, do not use disk mirroring as a substitute for keeping current
backups of important data on your servers. Note When using redundancy techniques such as parity, you
sacrifice some hard disk I/O performance for reliability.

Because transaction log files and database files are critical to the operation of a server
running Exchange 2000, you can keep the transaction log files and database files of your Exchange 2000
storage group on separate physical drives. You can also use disk mirroring or disk striping with parity to
prevent the loss of a single physical hard disk from causing a portion of your messaging system to fail.

This exert is taken from Microsoft's Exchange Server Disaster Planning Online Book