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.