A certain 1970s-era car commercial used to show a diamond cutter at work in the back seat of a moving car. The implication was clear: The car was steady enough to permit the precision that diamond cutting requires. Fortunately, you don't need to be a diamond cutter (or own a fancy car) to successfully break large Exchange Server Stores into smaller, more manageable chunks.
When Microsoft designed Exchange Server 4.0, a large mail server might have several dozen users and tens of megabytes of data. However, the designers had the foresight to build a database structure that could handle much larger volumes of data. Exchange Server 5.5, Enterprise Edition (Exchange 5.5/E) introduced the "unlimited" Information Store (IS), which has no built-in size limit (although I've never seen a single IS larger than about 220GB). Until Exchange 2000 Server hit the streets, though, each IS was limited to one private store. This restriction made backing up and restoring large databases an adventure: Until you restored the entire IS, no one on the server could get mail. Considering the speed of tape-backup systems at the time that Microsoft released Exchange 5.5/E, this proposition was disheartening for administrators who wanted quick recovery of email data.
Exchange 2000 addresses the problem by permitting as many as four storage groups (SGs) per server. Each SG can mount as many as five databases, and an SG contains the transaction logs for all its databases. Each database in an SG is independent of its peers, so dismounting or restoring a database affects only the mailboxes or public folders that the database contains. This change is a great boon to availability and simplifies backup management by letting you back up multiple SGs in parallel—slashing backup times in the process.
The key to effectively splitting up your databases is to work backward. How long can you tolerate being without a particular database? (The answer depends on the service level agreement—SLA—that you have with your customers.) Microsoft's rule of thumb is that a restore takes twice as long as a backup. Halve the amount of time you can afford to be down; that interval represents your backup window. For example, if your SLA requires that your executive team's mailboxes never be offline for more than 8 hours in a row, you can't let your Store grow beyond a size that you can back up in 4 hours.
Next, figure out exactly how much data you can back up within that window. The answer depends on the type of backup you perform (i.e., full, incremental, or differential), whether you back up to a locally attached or Storage Area Network (SAN) device, how many tape drives you have, and how fast your tape drives and backup software are.
After you know how much data you can back up in the available time, you can estimate how big your Stores can get. For example, suppose that I want to be able to restore a database within a 1-hour window. I need to be able to back up that database within a 30-minute period. If I use a garden-variety tape subsystem, I can probably back up about 35GB per hour, so I shouldn't let my databases get much bigger than 18GB. I can enforce that restriction through mailbox limits or vigorous use of Mailbox Manager.
You can use other methods to decide how to break up databases. A common tactic is to put the most important mailboxes in one database within an SG, then back up that SG more frequently. For bonus points, do the backups to disk (fairly feasible if you keep the number of critical mailboxes low), then push the backups to tape when time permits. That way, you get quick recovery of your most important mailboxes while keeping the backup size and media count manageable. (You're on your own deciding who's important enough to include in the special database.)
