Using Backup to Solve Department Challenges

Before a backup plan can be created, administrators must understand what types of failures or disasters they need to plan for and the recovery requirements for each of these failures. Because there are several different types of recovery situations, you must ensure that the organization has a process in place to address specific recovery events.

As an example, although a full tape backup of the entire Exchange database can enable an organization to restore the databases from a catastrophic failure, a full image of the database does not help the organization easily restore a single mailbox or a single message. To restore a single mailbox or message from a full image of the entire Exchange databases requires a full restoral of the entire database, and then a manual extraction of the mailbox or message from the restored backup. So if an organization has a need to restore a single message or a single mailbox, there are best practice procedures to supplement a full image backup for the sole purpose of restoring just a single message or a single mailbox. These other methods or procedures include using a third-party tape backup utility to do a mailbox-by-mailbox backup, or to leverage the Mailbox Recovery Center utility built in to Exchange 2003 that is covered in detail in Chapter 32, "Recovering from a Disaster."

Understanding What Should Be Ready for Restoral

Learning what is necessary for a recovery gives administrators a list of all the elements they might need to back up for recovery when a particular failure is encountered . When they know what needs to be backed up, they can then create the backup plan. So it is recommended that administrators research each server service and application to understand what is necessary for recovery so that their backup plan will target the correct information.

There are several reasons an organization should have a backup of its Exchange information. The reasons an Exchange administrator might need to restore Exchange include the following:

• In case of a system crash

• In the event that the databases get corrupt and need to be recovered

• In a situation where an individual message, folder, or mailbox needs to be restored

• For the purpose of restoring Exchange in a lab for test purposes

Protecting Data in the Event of a System Failure

Server failures are the type of problem most organizations plan for, because a complete system failure creates the ultimate scenario where data needs to be restored from backup tape. Server hardware failures include failed motherboards, processors, memory, network interface cards, disk controllers, power supplies , and, of course, hard disks. Each of these failures can be minimized through the implementation of RAID hard drives , error correcting memory, redundant power supplies, or redundant controller adapters. In a catastrophic system failure, however, it is likely that the entire data backup would have to be restored to a new system.

Because data is read and written to hard drives on a constant basis, hard drives are frequently singled out as the most possible cause of a server hardware failure. Windows Server 2003 supports hot-swappable hard drives, but only if the server chassis and disk controllers support such a change. Windows Server 2003 supports two types of disks: basic disks, which provide backward compatibility; and dynamic disks, which enable software-level disk arrays to be configured without a separate disk controller. Both basic and dynamic disks, when used as data disks, can be moved to other servers easily. This provides data or disk capacity elsewhere if a system hardware failure occurs and the data on these disks needs to be made available as soon as possible.

NOTE

If hardware-level RAID is configured, the controller card configuration should be backed up using a special vendor utility; or it may need to be re-created from scratch if the disks are moved to a new machine.

To protect against a system failure, an organization needs to have a full image backup that can then be restored in entirety to a new or repaired server system.

Protecting Data in the Event of a Database Corruption

Data recovery also is needed in the event of a database corruption in Exchange. Unlike a catastrophic system failure, which can be restored from the last tape backup, data corruption creates a more challenging situation for information recovery. If data is corrupt on the system server, a restoral from the last backup might still have the corrupt database, so a data restoral needs to predate the point of corruption. This typically requires the ability to restore the database from an old tape and then recover incremental data since the clean database restoral.

Providing the Ability to Restore a Message, Folder, or Mailbox

In other situations, an organization might need to recover a single message, folder, or mailbox rather than a full database. With most full backups of an Exchange server, the restoral process requires a full restoral of all messages, folders, and mailboxes. If an administrator has to work with only a full image backup, typically a full restoral must be performed on a spare server and information extracted from the full restoral as necessary.

If message, folder, or mailbox recovery is required on a regular basis, the organization may elect to back up information in a format or process that provides an easier method of information recovery. This may involve the purchase and use of a third-party tape backup system, or a combination of various utilities available in Exchange 2003 to restore individual sets of information.

Preparing a Backup for a Test Lab Restoral

The last scenario where a restoral is performed is the situation wherein an organization wants to re-create an Exchange server for the purpose of testing the server in a lab. In this situation, a full restoral is conducted in an isolated environment. Because Exchange 2003 requires Active Directory for the user address list and distribution list, a recovery of an Exchange server for this purpose requires the restoral of a Global Catalog server and potentially other support servers, such as front-end servers or bridgehead servers.

Instead of just restoring a single server into a production environment, the lab restoral for testing purposes requires the restoral of several dependency server systems. The process of restoral also requires certain servers to be restored in a logical sequence so that the right persons are in place, like domain controllers, before member servers are restored. This sequence provides a more structured restoral that spans more than just the recovery of a system, but rather an entire system environment.