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
