|< Day Day Up >|| |
Systems do not always run as smoothly as you would like. Hardware failures, software failures, human error, hacker attacks, and sometimes even natural disasters can disrupt your electronic mail (e-mail) environment. Routine hardware maintenance, disciplined system management, and educated users can reduce risk, but the potential for failures can never be eliminated completely. Disasters will happen, and you must be prepared to respond quickly. Regular backups are a key part of disciplined system management, and they protect data from accidental loss, hardware failures, and other disasters. You should regularly back up your Exchange databases and other critical files so that you can quickly restore them if data are accidentally deleted. If you accidentally delete data, you can recover a single database from the backup media. If a server fails, you can rebuild key components or the entire server.
The Exchange 2003 Information Store can be partitioned, allowing Exchange to overcome one of the more serious limitations of Exchange 5.5. Each Exchange 5.5 server was limited to a single large private database- stored as a single Windows NT file-containing the mailboxes for all users. The size of the Information Store grew in direct relation with the number of messages retained by the users, resulting in databases that exceeded many gigabytes in size. The large database size increased the time required to restore the database from backup tapes, which constrained the number of users you could safely put on a single server. Exchange 2003 solves this problem by allowing you to partition the Information Store (Figure 9.1).
Figure 9.1: Exchange Information Store partitioning
In Exchange 2003, the Information Store for each Exchange server or cluster can be partitioned into up to four Storage Groups. Each of the Storage Groups can have up to five private or public database sets. This provides a theoretical limit of 20 databases per server-four Storage Groups, each with five databases.
The databases are transaction based and fault tolerant. Each database change is recorded in a transaction log before the change is applied to the database itself. If a system failure occurs, the database recovery process uses the transaction logs to restore the changes that have occurred since the last successful backup. To reduce the overhead of multiple sets of log files, all database sets in the Storage Group share a common set of transaction log files. Partitioning results in smaller databases, reducing recovery time, and thus user impact.
From a backup and recovery perspective, each of the individual databases is independent. A database can be mounted or dismounted at any time, allowing a failed database to be restored while other databases remain operational. In other words, users with mailboxes in other databases can continue to send and receive e-mail during the recovery.
The changes to the Information Store since Exchange 5.5 was released affect the backup and recovery strategy for Exchange. When you install Exchange, the installation process extends the standard Windows backup utility to support the Exchange Information Store. This Windows ' Exchange aware' backup utility understands the relations among the Information Store, storage groups, databases, and transaction logs. The backup utility knows to delete the transaction logs after a successful normal (full) backup. A normal backup is the proper way to recover the disk space used by log files.
If you elect to use third-party backup software, make sure that it will work with the Exchange Information Store, storage groups, databases, and transaction logs. Not all third-party products are Exchange aware. Some third-party providers sell their Exchange-aware versions as add-on agents at additional cost.
Exchange backups are designed to be done while Exchange is running. You do not-and should not-stop any Exchange services or dismount any Exchange databases when you do a backup. Because Exchange is still running, your users can continue to send and receive e-mail while the backup is in progress. Although you cannot have multiple instances of Windows Backup running simultaneously, Backup will allow you to select multiple databases to back up.
The Windows Backup utility supports several types of backup. Each type has advantages and disadvantages in terms of the time required to perform the backup, the amount of storage space needed on the backup media, and the time required to restore a database. Types of backups include the following:
Normal. A normal backup is a full backup that copies all selected Storage Groups and databases, along with the associated transaction log files. After backing up the log files, the backup procedure merges pending transactions (messages) from the transaction logs into the Information Store and then deletes the log files from the disk. A normal backup is the proper way to recover the disk space used by log files. Because normal backups copy more data than other backup types, they take longer to complete. However, normal backups are strongly recommended because they minimize the number of tapes required to recover data. If you create daily normal (full) backups, you need only one tape to restore an Exchange database. Both incremental and differential backups require multiple tapes to recover the same amount of data. Because users cannot send or receive e-mail while a recovery is in progress, reducing the length of the recovery process is highly desirable.
Differential. Differential backups are used in conjunction with normal backups. To use differential backups, you also must periodically make a normal backup. The differential backup is then used to copy the transaction log files that have changed since your normal backup. The database itself is not copied, and transaction logs are not deleted from the disk after being copied to tape. If you use differential backups, the recovery process requires your most recent normal backup tape and your most recent differential backup tape. Because this recovery process only requires two tapes, it is the second fastest recovery process.
Incremental. Incremental backups also are used in conjunction with normal backups. The incremental backup copies the log files that have changed since your most recent normal backup or incremental backup. The database itself is not copied. If you use incremental backups, the recovery process requires your most recent normal backup tape and each subsequent incremental backup tape. Because of the number of tapes involved, this is the slowest and most error-prone recovery method.
Copy. A copy backup is the same as a normal backup, except that the transaction logs are not deleted from the disk at the end of the backup process. Copy backups are not the best method for restoring a database. They are most useful for taking a snapshot of the database.
Daily. A daily backup backs up only files that have been changed that day, but it does not mark them as being backed up.
Using the Windows Backup utility, you can back up files and databases to a tape drive, a file on another hard drive, a removable disk, a CD-RW, or any other Windows storage device. The backup device must be directly connected to the system where you are running the Backup utility. If you are backing up Active Directory configuration data and the Windows registry, the backup device must be directly connected to the server you are backing up.
If you are backing up Exchange databases, the Exchange server can be anywhere on the network. This allows you to use a single backup server to back up the databases from several different Exchange servers. If you elect to do backups over the network, you may want to install a second network card in each of your Exchange servers and implement an isolated, high-bandwidth network just for backup traffic. This keeps the normal network traffic from slowing the backup and keeps the backup from affecting other network activity.
|< Day Day Up >|| |