Lesson 1: Backup Planning for Exchange 2000 Server | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

Exchange 2000 Server is designed to support any number of users on a single machine. If you are using the Enterprise Edition, for instance, mailbox stores are not restricted in size and can grow up to several hundreds of gigabytes—theoretically even terabytes. Are your backup devices prepared for this amount of data? Partitioning the Information Store, as explained in Chapter 10, "Designing Fault Tolerance and System Resilience for Microsoft Exchange 2000 Server," can help keep the individual size of databases small. Small databases are easier and quicker to restore than large files, but you still have to back up the entire system in the first place. High-performance backup solutions save an enormous amount of data per hour. At the upper end, rates of more than 100 GB per hour are achievable with data compression. That’s the type of system you need if you want to support 5000 users per server! If your backup solutions cannot reach the performance level you want, consider multiple concurrent backup sessions for multiple backup devices. Multiple sessions, however, require multiple storage groups. Remember to always back up entire storage groups in a single session.

This lesson tackles the task of planning backup routines for Exchange 2000 Server. You can read about the various backup types, including their advantages and disadvantages. You will also learn how to back up individual mailboxes in addition to complete databases. The validation and maintenance of backup media is also covered briefly.

After this lesson, you will be able to

List the various backup types you can use to save an Exchange 2000 server and describe their advantages and disadvantages
Explain how to back up individual mailboxes using the Microsoft Exchange Mailbox Merge Wizard
Develop a backup plan to save your users’ messaging data as well as the server configuration in a timely fashion

Estimated time to complete this lesson: 75 minutes

Backup Operations in Exchange 2000 Server

You have two general options for backing up mailbox and public folder stores: You can perform a file-based backup, commonly known as an offline backup, or you can save the databases of the Information Store online without stopping any services using a dedicated application programming interface (API) for backing up and restoring Exchange 2000 Server. There is a third possible option: You can back up mailboxes individually using third-party backup software or special utilities, such as the Microsoft Exchange Mailbox Merge Wizard (EXMERGE.EXE), commonly known as Exmerge.

Performing Offline Backups

The advantage of offline backups is that they can include all of the server’s data, including the binary files, message queues, full-text indexes, and so forth. You can use the standard Windows 2000 Backup program; no special Exchange 2000–aware backup utility is necessary. However, offline backups also have a significant disadvantage: You need to stop the Information Store and other services that access databases to successfully copy the files from the \Program Files\Exchsrvr directory to the backup media. Offline means that the server is unavailable during the backup operation (see Figure 11.1).

Figure 11.1 - The disadvantage of offline backups

The following are the advantages of offline backups:

They can include all server files. It is a good idea to perform an offline backup immediately after the installation of Exchange 2000 Server and periodically when new components, such as service packs, are added to the server.
They simplify disaster recovery. A recent file-based backup can significantly simplify disaster recovery procedures. As long as original and replacement hardware are identical, you can restore an entire system without the need for online backups or special setup modes (such as, Setup/DisasterRecovery, which is explained in Lesson 2).

The following are the disadvantages of offline backups:

Exchange 2000 Server is unavailable during backup operations. You need to stop all server services that access data on the local server, and you must always perform a complete backup of the entire server, which consumes time and storage space. Do not forget to include all disk drives in the offline backup, which is especially important if you have placed transaction log files and databases on separate physical disks.
Transaction logs are not purged. The offline backup is not aware of databases or transaction log files. It does not detect committed transactions or purge transaction log files. This can lead to a situation in which the hard disk fills up with transaction logs. To purge the logs, perform a normal online backup or enable circular logging for the storage group if reduced fault tolerance is acceptable, as explained in Chapter 10, "Designing Fault Tolerance and System Resilience for Microsoft Exchange 2000 Server."

Note

Most backup solutions have an option to back up open files, but you should not use this option to perform "online" file-based backups of Exchange 2000 Server databases. It is likely that the backup program then copies databases in an inconsistent state to tape, which effectively renders your backup useless. To perform file-based backups while Exchange 2000 Server is running, exclude the database directories from the backup and perform an online backup for this data separately. You can include file-based and online backups in one session.

Performing Online Backups

Online backups, as the name implies, are performed while the server services are running. Users can thus continue to communicate, but the system might react a little slower than usual. In fact, you must ensure that the Exchange 2000 services are started and all databases mounted to perform online backups. Your backup program needs to communicate with the services through the Exchange 2000 backup API to request the data.

Note

Microsoft recommends that you perform online backups for entire storage groups. You can include all storage groups in one backup session.

The following are the advantages of online backups:

Exchange 2000 Server is online. Active server services ensure that users can communicate during the backup operation.
Current transactions are included in the backup. The Extensible Storage Engine (ESE) can catch transactions that occur during online backups in patch files (.pat). These patch files are included in the backup at the end of the operation, as explained in Chapter 10, "Designing Fault Tolerance and System Resilience for Exchange 2000 Server."
Transaction log files are purged. Online backups are aware of the Exchange Server databases and their transaction log files. Normal and incremental backups purge the transaction logs, which recovers disk space for new transactions. You can read more about transaction log files in Chapter 10, "Designing Fault Tolerance and System Resilience for Exchange 2000 Server."
Backup time and storage space saved. Incremental and differential backups write only transaction log files to tape, which helps to save time and space on the backup media. The actual database files are not included in incremental or differential backups. They are not required, because as long as an uninterrupted sequence of transaction logs is available since the last normal backup of the databases, Exchange 2000 can reconstruct the entire mailbox store from the transaction logs. Table 11.1 lists the various online backup types and their features.

The following are the disadvantages of online backups:

Binary files or configuration data are not included in the backup. It is advisable to perform a file-based backup of this data in addition to online backups. To save the configuration of your server, explicitly activate the option to back up the system state.
Standard backup utilities are unable to perform online backups. To perform online backups you need to use backup software that is able to utilize the Exchange 2000 backup API. The Windows 2000 Backup utility, for example, is made Exchange 2000 Server-aware when you install Exchange 2000 Server.

Table 11.1 Online Backup Types and Their Features

Backup Type	Features
Normal backup, also known as full backup	Normal backups include the databases as well as transaction log entries that have not yet been committed to the databases. In addition, transaction log files that contain content that is already committed to the actual database files are purged from the system after the database is successfully written to the backup media. Normal backups enable you to restore the databases from a single backup set, but they require more storage space than any other online backup type. Because the transaction logs are purged, the full backup sets the context for all other backup types.
Incremental backup	Includes only new transaction log files, but does not save any database files. Incremental operations purge the transaction logs once they have been backed up, setting the context for the next incremental or differential backup. Incremental backups are not supported on storage groups where circular logging is enabled. It is important to note that incremental backups are useless without a previous normal backup because only the latter contains the database files. Therefore, a successful restore requires the last normal backup plus all incremental backups since that time.
Differential backup	Same as incremental backup, only the transaction log files are not purged. The differential backup does not change the context for the next backup, which might be an advantage over incremental backups. Differential backups depend on a previous normal backup, just as incremental backups do, but a successful restore requires only the last normal backup plus the last differential backup—provided that incremental backups have not been performed in the meantime. Differential backups are not supported on servers or storage groups where circular logging is enabled.
Copy backup	A special form of normal backup that saves databases and transaction logs, but does not purge any files from the system. The copy backup is useful for archiving purposes because it does not change the context for any other backup types. Therefore, a backup created with a copy backup procedure can be shipped offsite, without changing standard backup and restore procedures. It is a good idea to perform a copy backup whenever you change the configuration or work with offline database utilities.

Identifying Exchange 2000-Related Data

Exchange 2000 Server stores data in a variety of databases. The most important are the databases of the Information Store service, but depending on the server’s configuration, further repositories might exist (Table 11.2). It is a good idea to include all databases in your backups, even if they hold data that the system can reconstruct automatically, such as full-text indexes.

Table 11.2 Core and Additional Databases of Exchange 2000 Server

Database Repository	Purpose
Core databases	These are the mailbox and public folder store databases of the Information Store. You can read more about the various database files and their purpose in Chapter 10, "Designing Fault Tolerance and System Resilience for Exchange 2000 Server."
Site Replication Service database (SRS.EDB)	Active Directory Connector (ADC) and Site Replication Service (SRS) coordinate the replication between Active Directory and the legacy Exchange directory if you install Exchange 2000 Server in an existing Exchange Server organization, as explained in Chapter 6, "Designing an Upgrade Plan to Microsoft Exchange 2000 Server." The SRS emulates a Microsoft Exchange Server 5.5 directory service to replicate configuration information with the legacy Exchange directory service. The SRS maintains its direc- tory database in the \Program Files\Exchsrvr\Srsdata directory. It is possible to back up the SRS database online using the Exchange 2000 Server–enabled version of the Windows 2000 Backup utility.
Key Management Service database (KMSMDB.EDB)	The Key Management Service (KMS) uses this database to store the history of encryption keys for all users who have been enabled with advanced security. The KMS database resides in the \Program Files\Exchsrvr\Kmsdata directory and can be backed up using an Exchange 2000 Server–enabled backup program. Do not forget to secure the Key Management Server (KM Server) password in addition to the KMS database. Furthermore, make sure a correct backup of Windows 2000 Certificate Services is performed. At a minimum, back up your certificate authority’s (CA) certificate in a .p12 file and save the password. You can read more about the KMS and advanced security in Chapter 9, "Implementing Security for Hosted Services."
Microsoft Search database (EXCHANGE SERVER_<SERVER NAME>.EDB)	The Microsoft Search service maintains full-text indexes in its own database, which, by default, resides in the \Program Files\ Exchsrvr\ExchangeServer_<Server Name> directory. You can use a file-based backup to save the full-text search database offline.
Databases of messaging connectors, Instant Messaging, and third-party components	Messaging connectors, such as the Connector to MS Mail and other components, also have databases. For example, the Connector to MS Mail stores directory synchronization informa- tion in a database called XDIR.EDB located in the \Program Files\ Exchsrvr\Dxadata directory. Instant Messaging servers, to give a second example, store contact subscriptions in a database called MSIMNODE.EDB, which is in the \Program Files\Exchsrvr\ IMdata directory. Losing any of these databases is not a disater, but you may want to save them offline using a file-based backup.

Backing Up Individual Mailboxes

Using online backups, you can save databases and storage groups separately, but it is impossible to back up individual mailboxes or public folders. To perform such operations, you need to use a utility that works similar to a messaging client, such as Exmerge. Essentially, Exmerge is a Messaging Application Programming Interface (MAPI)-based client that copies messages from mailboxes into personal folder stores (.pst files). Exmerge can also import the data into target mailboxes, but this is not required for backup purposes. Let Exmerge copy the messages into .pst files and include these files in a file-based backup, and you have accomplished a backup at the mailbox level (see Figure 11.2).

Exmerge supports scheduled batch-mode operations, enabling you to use this utility as an automated mailbox-level backup agent. However, keep in mind that this form of backup may require significant storage space and a significant amount of time. Among other things, the single instance storage feature, described in Chapter 10, "Designing Fault Tolerance and System Resilience for Microsoft Exchange 2000 Server," is not available in personal folder stores. Furthermore, the copy process relies on MAPI instead of a specifically designed backup API, which means that the process is very slow. Accordingly, you might want to include only the most recent messages in this form of backup. Exmerge allows you to specify, in detail, which data to copy. For detailed information, read the documentation that is available in the \Support\Utils\i386\Exmerge directory.

Remember that Exmerge must access the mailboxes directly to extract the user data. The account that you plan to use to "exmerge" messaging data requires permissions to open all mailboxes on the server, as indicated in Figure 11.2. To grant the required permissions, display the mailbox store’s properties in the Exchange System Manager snap-in, click the Security tab, and grant the account full mailbox permissions including Receive As and Send As. Members of the Domain Admins or Enterprise Admins group have inherited implicit denials for Receive As and Send As to prevent automatic access to user mailboxes, as indicated by grayed check boxes, but you can override those denials by granting explicit permissions. Accounts that are not Domain Admins or Enterprise Admins can access all mailboxes when you add them to the Exchange Domain Servers group.

Figure 11.2 - The principle of backing up data at the mailbox level

Tip

You can find Exmerge on the Exchange 2000 Server CD in the \Support\Utils\i386\Exmerge directory. This tool requires several dynamic- link libraries (DLLs) that come with the Exchange System Manager snap-in. Copy the files to the \Program Files\Exchsrvr\Bin directory to run Exmerge successfully.

Backing Up the System Configuration

In addition to backing up databases, you need to keep a record of the system configuration. It is important to document the installed components, their installation directories and drive letters, service accounts and passwords, and the names of servers, stores, storage groups, administrative groups, and the organization. This information may be required to successfully recover a server.

Exchange 2000 Server stores configuration information in the following locations:

Active Directory Stores the configuration of the entire Exchange 2000 organization, as explained in detail in Chapter 3, "Assessing the Current Network Environment."
Files on the file system Store specific information, such as attribute mappings for directory synchronization with foreign messaging systems. Some components, such as gateway connectors, require information from American Standard Code for Information Interchange (ASCII) text files to initialize correctly.
Internet Information Services (IIS) metabase Stores the configuration of virtual servers and virtual directories to initialize IIS-related services, such as the Simple Mail Transfer Protocol (SMTP) service, correctly.
Registry database Stores startup parameters that the various Exchange 2000 services need to initialize.

With the exception of ASCII files on the file system, configuration information is not included in normal offline or online backups. To include the remaining repositories, back up the system state. The Windows 2000 Backup utility provides a System State check box for this purpose. System state information must be backed up locally and can only be restored on a computer that has the same name as the original server.

Note

Active Directory information is only available on domain controllers. If you select the System State check box on an Exchange 2000 server installed on a member server, the configuration of your Exchange 2000 organization is not included in your backup set. In this case, you must ensure the Windows 2000 administration team is properly backing up the domain controllers.

Verifying and Validating Database Backups

Professional backup solutions that utilize Exchange 2000 Server’s backup API are able to verify successful completion of backup jobs and report possible data damage and corruption in backup logs or in the application event log. Errors are a critical issue because corrupted backup sets do not allow you to recover the data. You must make sure backups complete successfully.

It is important to understand, however, that successful completion of a backup job does not necessarily imply that the data is indeed recoverable. Today’s backup might be in perfectly good shape, but if it was an incremental or differential backup and the incremental backup from the previous day is lost, your current backup is doomed as well. It is vital to validate backup sets routinely by restoring the data to a reference computer. If it is not feasible to verify all backups from all servers, rotate the restore process and test backups from various machines. Careful organizations plan a monthly test recovery to check the system, identify potential problems, and practice for worst-case scenarios.

To ensure you can restore an Exchange 2000 server from backup, perform the following steps:

Always verify that the backup operation completed successfully.
Verify the integrity of system state information (configuration data), which may require you to examine the backup logs of multiple machines (domain controllers in addition to Exchange 2000 servers).
Validate backup sets periodically by restoring a production system on a test server that is not part of the production Active Directory environment. Implement a dedicated nonproduction recovery environment for software and disaster recovery tests. The test systems should be equipped with hardware and compatible tape drives similar to the production systems. Among other things, you need enough disk space to restore entire information stores.

Planning Backup Operations for Exchange 2000 Server

As mentioned in the beginning of this chapter, your project team should review existing backup documentation and interview system administrators to get a full picture of the requirements in the organization. For example, SLAs might force you to design a backup plan that permits the restoration of individual mailbox stores within a short period of time. This might call for an optimization of the information store architecture. You also need to identify persons with disaster recovery responsibilities. As outlined, backups should be verified and validated at some point. Of course, you also need to identify appropriate backup techniques and schedules. If possible, perform normal (full) online backups daily because these do not depend on other backup types and offer the most reliability. Table 11.3 lists important issues that your project team should address when designing a backup plan.

Table 11.3 Important Issues for Backup Planning

Issues	Comments
Where do your users store their messaging data?	It is important to understand that the backup API of Exchange 2000 Server cannot save the data of your users if they download all messages to their local client computers. If company policies require you to save this data, ask your users to move the messages back into the server-based mailboxes. Another solution is to ask the users to archive their data routinely into .pst files. If these .pst files are stored locally on the users’ computers or in a shared directory on a server, they can be backed up like any other document. You can then include these personal folder stores in a file-based backup.
Does the Information Store architecture permit the backup and restore operations you want according to organizational requirements and SLAs?	The need for fast restores might require you to partition the information store using multiple storage groups and mailbox stores. If it is not possible to meet the SLA requirements, consider installing multiple Exchange servers. You should also ensure that circular logging is not enabled for any storage groups that hold user data. Circular logging prevents incremental and differential backups and decreases the system’s fault tolerance.
Are the backup hardware and software powerful enough to back up your Exchange 2000 server?	Your backup solution must operate fast enough and have a sufficient capacity to save the data from all Information Store service databases plus the server’s system files in a reasonable time frame. Another consideration is the reliability of the backup media. In general, you should only use media brands tested and certified by the manufacturer of your storage device.
Which backup routine and schedule allows you to best back up your server without interfering with production processes?	You should back up your servers at least once daily and perform full backups if the size of your databases and the capacity of your backup media allow. Incremental and differential backups have disadvantages because of their dependencies. Differential backups are more dependable and easier to restore than incremental backups, but they require more server disk and tape space because they do not purge the transaction log files.
Who is responsible for backup verification?	All backups must be verified systematically to ensure the jobs complete successfully. Your backup plan should also define escalation procedures to report possible problems to system administrators and management. Ideally, the person responsible for verifying backups should be different from the person responsible for configuring backups.
What are the backup validation policies?	Your project team should outline an appropriate test environment, define responsible administrators who should perform restores, and define a monthly or quarterly validation schedule.
Where are the installation CDs and backup sets archived?	Your backup plan is an important document for any system administrator who must restore a production server. The disaster recovery documentation must clearly outline where the installation CDs, floppies with additional drivers, and backup media are stored and how they are labeled. The documents should also contain detailed restore instructions. Many organizations prefer to archive full backup sets offsite, in which case the documentation must include addresses, phone numbers, and contact persons.

Rotating the Backup Types

An important piece of information in any backup plan is the schedule that outlines the time frames and backup types to save the messaging data, system states, and binary files. As mentioned earlier, it is best to perform daily full online backups, but depending on the performance of your backup hardware, this might not be feasible. Among other things, you must make sure that backups complete before the next backup cycle begins. This might require you to switch from full backups to differential or even incremental backups during the week. It is good practice to perform backups during off-peak hours to avoid interfering with the work of your users. Make sure your backup schedule does not conflict with maintenance intervals configured for your databases.

At a minimum, perform a full online backup and a file-based backup weekly. It is common to plan these backup types for the weekend (see Figure 11.3). If full backups interfere with normal business hours or exceed the storage limit of your backup system, plan differential backups for weekdays. You can minimize backup times and space requirements by switching to incremental backups, but remember that these depend heavily on previous tapes. It is not a good idea to mix incremental with differential backups because this unnecessarily complicates the restore process. For example, let’s assume you planned a full backup on Sunday, an incremental backup on Wednesday, and differential backups on all other days. On Tuesday, you only needed the last full backup and last differential backup set; on Friday, however, you need the last full backup, the incremental backup, and the last differential backup to successfully restore the system, which is a complicated restore policy.

Figure 11.3 - Typical online backups for Exchange 2000 Server

Rotating the Backup Sets

The quality of your backups depends largely on the quality of your backup tapes. Ask your storage device manufacturer which media to use, and use multiple backup sets. This helps to protect you from total loss of data if a particular tape malfunctions. For example, assume that you must restore a server on Wednesday, but are unable to restore the current backup due to a tape failure. If you used the same tape the entire month, no other tape would be available and an enormous amount of data is lost. If you rotated the backup sets and used different tapes every day, on the other hand, the differential backup from the previous day might still be restorable.

Microsoft recommends using a media rotation schedule with daily, weekly, and monthly backup sets. On the last day of each month, perform a full backup of the server. Label this backup set according to the month of the backup, such as December 01, January 02, and so forth. This requires 12 backup sets if you keep a history of the server for one year. Many organizations keep monthly backups offsite in a safe place to prepare for disasters, such as a fire in a data center. During the month, use different sets of tapes to perform full backups over the weekends. Label the tapes Week1, Week2, and so forth, and reuse them every month. This requires five more tape sets, but these are reused on a monthly basis. During the weekdays, again, use different tape sets to perform the backups. Label them Monday, Tuesday, and so forth, and rotate them on a weekly basis; that is, always use the Monday tape set on Monday, Tuesday’s tapes on Tuesday, and so forth. This scheme enables you to fall back to any previous day in the current week, to any previous week in the current month, and to any previous month in the current year.

The following precautions can help ensure reliable backup and restore operations:

Maintain and clean your tape drives on a regular basis.
Store backup tapes in a safe location and archive monthly backup sets according to SLAs and organizational policies.
Use daily, weekly, and monthly backup sets to back up your servers. Discard old tapes when they reach their maximum number of backup cycles.

Planning Backup Operations for Proseware, Inc.

Proseware, Inc. is a modern application service provider (ASP) introduced in Chapter 8, "Designing Hosted Services with Microsoft Exchange 2000 Server." The company has deployed a large number of Exchange 2000 servers in a front-end/back-end (FE/BE) configuration to support 350,000 Microsoft Outlook Web Access (OWA) users over the Internet. "We are very satisfied with the performance of Exchange 2000 Server," says Guy Gilbert, Head of IT Operations. "We have installed 25 four-node clusters as back-end servers, which store their transaction log files and databases in our high-end storage area network. Every mailbox server is configured with five mailbox stores in a single storage group. Every server is hosting 3500 users, so every mailbox store contains 700 mailboxes. To keep the size of our stores within reasonable limits, we generally restrict the mailbox size to 50 MB. That’s a maximum of 35 GB per store or 175 GB per server. It goes without saying that we need a very high-performance backup solution to save our servers in a timely fashion."

Gilbert developed the following backup plan for Proseware, Inc.:

The Information Store architecture of our back-end (BE) servers is optimized for a large number of users. Every virtual server has one storage group with five mailbox stores, which we will always back up together as a unit. This requires us to copy a maximum of 175 GB per server to tape using a single backup session.
We will integrate our BE servers into our existing backup infrastructure. Our current solution consists of several scalable linear recording (SLR)-based library systems, each with 4 TB of capacity and up to 144 GB per hour transfer rates, 2:1 compressed data, so I don’t expect any serious bottlenecks related to our backup power. According to our vendor, an Exchange 2000– aware module is also available for our enterprise backup software. We need to purchase this module to perform online backups. In the meantime, we will use the Windows 2000 Backup utility. Lane Sacksteder, Chief Backup Operator, is responsible for developing detailed backup and disaster recover procedures.
The capacity and transfer rates of our backup infrastructure allow us to perform full online backups daily. Backing up a single server takes approximately 90 minutes. We can distribute the backup sessions across our backup systems and perform concurrent operations for multiple servers. However, SLR100 tapes are expensive. To use our resources economically, we will perform a full backup every Sunday night and daily differential backups on weekdays. The last day of every month, we will perform a full backup and transfer the tapes to our offsite backup service for archiving.
We will not perform backups at the mailbox level. This technology is slow and requires an enormous amount of disk space. It is more efficient to recover an entire system using a recovery machine in a separate network to log on to the affected mailbox and extract the items manually—if we ever need to recover individual items from a mailbox.
Lane Sacksteder and her team of backup operators are responsible for backup verification and validation. Any critical problems that cannot be solved right away must be reported to the Head of IT Operations within 24 hours.
The availability of our BE servers is crucial to our business. Backup operators are therefore required to perform a practice drill every first day of the month using the full backup performed the previous night. In this way, we can guarantee that our monthly backups are indeed restorable. We will purchase an extra four-node cluster for disaster recovery purposes and software tests.
Lane Sacksteder’s disaster recovery documentation and all backup sets must be stored in a fire-safe location in our data center. Monthly backups will be archived at our offsite backup service.

Activity: Developing Backup Strategies

In this activity, you will design backup strategies for two companies that operate powerful mailbox servers in their environments, Woodgrove Bank and Humongous Insurance. Their BE server configurations were discussed in Chapter 10, "Designing Fault Tolerance and System Resilience for Microsoft Exchange 2000 Server."

Tip

You can use Figure B.29 in Appendix B as a guideline to accomplish this activity.

Scenario: Woodgrove Bank

Woodgrove Bank has configured a clustered Exchange 2000 server in Zurich that stores the mailboxes of all users in Switzerland. The server name is ZUR-01-EX. "I’m very happy with our clustered mailbox server," says Luis Bonifaz, Chief Information Officer at Woodgrove Bank. "The cluster operates very reliably. We haven’t encountered a node problem yet, but it’s good to know that we are prepared for any kind of problem. Of course, we also need to implement a reliable backup strategy for our 600 Swiss mailboxes. Currently, each cluster node is connected to an individual digital linear tape (DLT) drive with a single 70-GB data cartridge. The backup hardware is able to reach a transfer rate of approximately 30 GB per hour or 8.5 MB per second with hardware compression. For restore operations, I expect the transfer rate to drop to 15 GB per hour. We use the Windows 2000 Backup utility. At Woodgrove Bank, we don’t want to restrict the size of our users’ mailboxes because office communication is critical to us, and our users must be able to send office documents to each other without trouble. I think we need to take an average mailbox size of approximately 100 MB into consideration."

It is your task to outline an appropriate backup solution for Woodgrove Bank:

Bonifaz has separated the mailbox resources according to the geographical locations of Basel, Bern, and Zurich by means of three mailbox stores, which all belong to the default storage group of the Exchange 2000 server. Approximately 200 mailboxes reside in each store. According to organizational policies, you must be able to restore an individual database in less than 4 hours. Is it necessary to redesign the mailbox stores to support fast database restore operations?
Woodgrove Bank does not plan to restrict the mailbox sizes of its users. With an average mailbox size of 100 MB, the Exchange 2000 server must be able to maintain up to 60 GB of messaging data. Would you recommend using more powerful backup hardware or software?
Woodgrove Bank is a classic office-oriented environment. Swiss business hours are from 9:00 A.M. to 4 P.M. Some managers may work longer, but after 11:00 P.M., the offices are usually empty. Which backup types and schedule should Woodgrove Bank use to back up the Exchange 2000 server?

Scenario: Humongous Insurance

Humongous Insurance, a national financial institution with customer service centers in all major U.S. cities, has implemented Exchange 2000 Server in a multi-application cluster paired with Microsoft SQL 2000 Server. "With our Exchange/SQL 2000 cluster, system maintenance is easier than ever," says Stephanie Bourne, Director of IT. "We only need to pause the specific node before the users come to work, and then we’re free to work with the hardware all day long at our own pace. This was a great help the other day when we installed additional Small Computer System Interface (SCSI) controllers into our cluster nodes here in New York to connect DLT drives to the computers. It surprised me a little that our users didn’t notice a performance decrease. However, our DLT tape drives offer 40 GB of data storage capacity at transfer rates of up to 10.8 GB per hour. We intend to use the same backup solution in all of our locations."

It is your task to outline an appropriate backup solution for the Exchange 2000 server in New York:

The office workers of Humongous Insurance rely heavily on their messaging infrastructure. They often send Microsoft Office documents in e-mail messages and frequently use Web-based workgroup and workflow solutions implemented in public folders. The average mailbox size is 200 MB and the public folder store holds 2 GB of data. Which backup types and schedule would you use to save the data of the Exchange 2000 server?

Lesson Summary

It is possible to back up the messaging data of an Exchange 2000 server offline or online. An offline backup is a copy process at the file level. All Exchange 2000 services that access databases, such as the Information Store, must be stopped to support file-based backups. The disadvantage is that the Exchange services are unavailable during this operation. Online backups, on the other hand, allow your users to work with their mailboxes while their messages are written to the backup media. They also take care of transaction log files, which otherwise wouldn’t be purged, provided you don’t enable circular logging for the storage group. Microsoft does not recommend enabling circular logging for storage groups that hold user data because it reduces the system’s fault tolerance.

Exchange 2000 Server supports four types of online backups, three of which are useful for daily backup operations: normal backup, incremental backup, and differential backup. The normal backup includes database files and transaction logs and does not depend on any previous backup cycles. Because of the amount of data included, normal backups require a significant amount of time and storage capacity. Incremental and differential backups, on the other hand, include only the transaction log files, which helps decrease the backup time and storage requirements. However, these types of backups depend on the last normal backup and any incremental backups performed since the normal backup. If any one of these is corrupted, subsequent incremental or differential backups are useless. Incremental and differential backups therefore have a higher chance of failure. Normal backups are most reliable, followed by differential backups, and then incremental backups. The fourth type, the copy backup, is useful if you want to archive a server in its current state without influencing any other backup types.

Ideally, you can perform normal backups on a daily basis. If your backup system cannot easily store the amount of data involved, consider differential backups, or, if you can’t avoid it, incremental backups in spite of their disadvantages. It is vital to outline a clear, simple backup schedule and a rotation scheme for your backup media. Never overuse a backup tape. Discard it after the maximum number of backup cycles has been reached and maintain your system according to the manufacturer’s instructions.