When you understand Microsoft Exchange 2000 Server's database technology and storage procedures, you can determine the best ways to recover your system after a disaster and increase your system's reliability. Study the recovery scenarios for your Exchange 2000 system and learn how the Exchange 2000 database engine backs up and restores data. Then, you can plan best practices and choose technologies to improve your Exchange 2000 deployments.
Exchange 2000 Recovery Scenarios
Disaster-recovery planning, testing, and operations using Exchange 2000 cover two scenarios: server catastrophe and Information Store (IS) recovery. If a disaster destroys your Exchange server, you need to recover server capabilities from scratch. You must pay attention to the OS (Windows 2000 or Windows NT), Microsoft IIS, Exchange 2000, and the IS. Exchange 2000 closely integrates with two Win2K components—Active Directory (AD) and the IIS metabase. Responsibility for most AD disaster-recovery planning probably won't lie with Exchange 2000 administrators. However, because Win2K's AD is similar to Exchange 2000's Extensible Storage Engine (ESE), some organizations might call on Exchange 2000 administrators to help infrastructure staff members (who typically have AD responsibility) plan for AD backup, recovery, and maintenance. You need to understand how to perform AD recovery operations on an Exchange 2000 server. Regardless of whether you rely on the infrastructure staff to handle recovery, you must factor AD into your Exchange 2000 disaster-recovery plans. In most cases, however, AD recovery will affect Exchange 2000 server recovery only if the Exchange 2000 server acts as a Win2K domain controller or Global Catalog (GC) server. (I don't recommend placing the Exchange 2000 server in those roles.)
The IIS metabase, which stores static configuration information for protocols and virtual servers, is an important factor in Exchange 2000 disaster-recovery planning. Exchange 2000 stores information about the protocols it uses, as well as about SMTP or other Exchange 2000 virtual servers, within IIS. Exchange Server administrators didn't need to plan for IIS metabase disaster recovery in earlier versions of Exchange Server; however, IIS is an integral part of Exchange 2000.
IS recovery is also a vital part of Exchange 2000 server restoration. Earlier versions of Exchange Server included the public (pub.edb) and private (priv.edb) stores. But because Exchange 2000 provides for multiple storage groups (SGs) and lets you configure multiple databases per SG, the program complicates disaster-recovery planning. For information about Exchange 2000's storage procedures, see "Exchange 2000 Storage Exposed, Part 1," July 2000. You need to be able to recover all SGs and databases, one particular SG, a message database (MDB), a mailbox, or even a message or document. Table 1 highlights the considerations for each Exchange 2000 recovery scenario.
In Exchange 2000, the disaster-recovery API that Microsoft provides as part of Exchange Server gets a face-lift. The ESE in Exchange 2000 makes an online backup API available through the eseclib2.dll DLL. This API lets Exchange Server service users while backup and restore operations occur. Earlier versions of Exchange Server have only one ESE instance; therefore, the IS services go offline during restore operations, and the server goes down until the recovery completes. Because Exchange 2000 has multiple ESE instances (i.e., SGs), one SG can recover while other SGs are online servicing users. Microsoft adapted the API to allow concurrent operations and to manage multiple SGs, MDBs, and log-file sets. Exchange 2000 also backs up the Key Management Server (KMS) and the Site Replication Service.
The ESE recovery API in Exchange 2000 allows more granularity than the API in earlier versions of Exchange Server allowed. You can back up or restore an entire SG or one MDB. In addition, a database in earlier versions of Exchange Server consisted of one file (i.e., the .edb file), but a database in Exchange 2000 is a set that includes an .edb file and a streaming (.stm) file.
Backup-and-Restore Fundamentals
Exchange 2000's backup-and-restore technology is similar to the technology in earlier Exchange Server versions, with a notable exception: SGs and multiple MDBs substantially affect the way the API works. In a forthcoming service pack, Exchange 2000 will support snapshot backups. Table 2 compares Exchange 2000's backup options.
The backup or combination of backups you select affects operational procedures, training, tape management, and restore times. Table 3 shows basic backup strategies for Exchange 2000. The table doesn't include a snapshot strategy because Microsoft is still deciding how to support the snapshot option in Exchange 2000. The Copy backup, which Table 3 also omits, is an archival or point-in-time copy option, not a disaster-recovery operation.
Backup strategies present trade-offs in restore operations. If you select a daily normal backup (Strategy 1), you deal with one tape and typically a fixed time and volume of data. You can easily plan your recovery windows. If you combine a normal backup on the first day of your backup cycle with daily incremental backups thereafter (Strategy 2), advantages on the first day are similar to those in Strategy 1. Incremental backups on subsequent days happen much faster because Exchange 2000 backs up only each day's log files. However, recovery is more difficult to manage because it requires multiple tapes and takes more time. Strategy 2 also increases the possibility of operator error or media failure. Strategy 3 is the middle ground between Strategies 1 and 2. With Strategy 3, you perform a normal backup on the first day and differential backups on subsequent days. This procedure requires two tapes for recovery: Tape 1 contains the normal backup from the first day (i.e., database, logs, and patch files), and Tape 2 contains all the log files that the program created since the first day. Because Strategy 3 requires only two tapes, it reduces backup time, data volume, errors, and the possibility of media failure.
The backup strategy you select will largely determine the amount of time you need to recover data. Many organizations select Strategy 1 as a best practice. As Exchange 2000's mission-critical nature grows, your ability to limit the number of tapes, reduce errors and media failures, and simplify procedures becomes increasingly important.
Prev. page
[1]
2
next page 
