Benefits of Using Storage Groups

These days, it is not uncommon to find Exchange 5.5 databases that are well over 20 GB in size. The time necessary to back up these databases can exceed several hours. The problem with this is not the time it takes to back up the database, but the time it takes to restore such a large database. During the restoration, of course, your users’ productivity goes down the drain. In Exchange database planning, the old clich is a good one: Always plan for failure so that you can succeed. You’ll find that prudent use of storage groups will help you succeed during disaster recovery.

In implementing storage groups and allowing multiple databases per Exchange server, Microsoft has made some tremendous changes to the Extensible Storage Engine (ESE) database architecture since Exchange Server 5.5. These changes significantly enhance recoverability and maximize productivity when an Exchange database becomes corrupted. In addition, storage groups offer several key benefits, which are listed here and discussed in the sections that follow:

• Each server can host more users than before.

• Each database can be backed up and restored individually.

• Each server can host multiple businesses.

• A separate store can be used for special mailboxes.

• Circular logging can apply to individual storage groups.

Increased User Support

Probably the largest benefit of storage groups is that they allow you to spread users across databases and storage groups on the same Exchange Server 2003. This provides three advantages:

• You can support more users on a single server than was possible in Exchange 5.5.

• You’ll have less downtime when a database becomes corrupted.

• You can host more users on an Exchange server because you can keep your databases to a manageable size.

As mentioned earlier, within a storage group, you can have up to five databases. Each server can house up to four storage groups. Thus, each server can have a maximum of 20 databases.

However, when you run the Information Store Integrity Checker (Isinteg.exe) on a database, you must dismount that database. In addition, Isinteg.exe needs a second database for temporary use. Therefore, if you have five databases operating in a given storage group, you will have to dismount a second database so that Isinteg.exe can run properly. If you limit the number of operating databases to four in a single storage group, you will always have room to run Isinteg.exe without having to dismount a second store.

Having your users spread out across multiple databases means that only a subset of your users is affected if one of your databases goes off line for some reason. The other users can continue to work because their databases are up and running. A database that is offline is considered to be dismounted. Its icon appears with a red down arrow in the Exchange System snap-in, as shown in Figure 11-1.

Figure 11-1: Online databases and an offline database (Executive MBX) in a storage group.

Individual Backup and Restore

Because each individual database can be mounted or dismounted, you can back up and restore databases individually while other databases in the same storage group are mounted and running. Consider a scenario in which you have created four mailbox stores in the same storage group, one for each of four departments. If one of those stores becomes corrupted, the other three can remain mounted while you restore the fourth store from backup and then mount it again. You are not required to dismount all the stores in a storage group in order to restore one of them. And if one store becomes corrupted and cannot be mounted, it does not stop other stores in the same storage group from being mounted and available to users.

Note

In addition to the five databases allowed in each storage group, a special sixth storage group named the recovery storage group is also allowed. The recovery storage group is intended as a temporary group that you can bring online for use in performing recovery operations. For example, you could bring the recovery storage group online, restore mailboxes to it, and allow users to access it while you resolve any problems with the original storage group. You could then merge the mailboxes of the storage recovery group back into the original storage group. The use of the recovery storage group is detailed in Chapter 27, “Disaster Recovery of an Exchange Server 2003 Database.”

Hosting of Multiple Businesses

If you manage e-mail for multiple businesses, you can host them on a single server. You can create an individual store for each business or even devote a storage group to a business, if needed. In either case, Exchange Server 2003 keeps the information for each business completely separate in its respective store, unlike Exchange Server 5.5.

Separate, distinct stores allow you to set up different administrative schedules for the businesses. For instance, some administrators might want to have full backups performed every day, while others might need only weekly full backups. Some might want to have each department hosted in a separate store, while others might be happy to house all their users in the same store. This flexibility makes it easier to meet your customer’s needs.

Support for Special Mailboxes

Although it is not widely recommended, you can take a special mailbox or set of mailboxes and create them in their own store. One instance when this might be useful would be for a journalizing recipient who receives copies of all appropriate e-mails in your organization to ensure they comply with local laws or industry-specific regulations. Another instance might be for a project team who is working with highly sensitive and mission-critical company information. Their work might warrant the use of a separate store or public folder tree.

Circular Logging for a Single Storage Group

You might need to control the transaction logs for some storage groups because of limited disk space. It could be the case, for example, that information held in one native content file is expendable while information held in a different native content file is not. Because you are limited to recovery at the last full backup when using circular logging, you could place your expendable information (such as a history of companywide memos) in one public folder in one storage group for which you permit circular logging, and you could place your users’ e-mails in a different storage group that has circular logging turned off. That way, you’d be able to focus your disaster recovery efforts on the most important information. For a description of how circular logging works, refer to Chapter 2.