I recently performed an availability assessment for a large client. The client was extremely interested in high availability, so the company had pulled out all the stops: The 1000 or so Exchange 2000 Server mailboxes (which contained a total of about 90GB of data) were stored on a high-end Storage Area Network (SAN), and mailbox access was courtesy of a clustered pair of beefy 4-way Pentium III Xeon servers. But despite all this exotic hardware, the client needed some help. Backups took all night, mostly because they involved nightly mailbox-level backups in addition to a normal full backup of the Store. Notice I said "the Store," not "the Stores"—all that data was concentrated into one mailbox Store, just as it might be in an Exchange Server 5.5 environment.
The client's objective was to reduce backup and restore time. This goal was key to the company's availability plan, considering Microsoft's rule of thumb that restoring an Exchange server takes roughly twice as long as backing it up. An 8- or 9-hour backup meant that the company had no hope of starting and finishing a restore during the same workday.
To help the company meet its goal, I asked some pointed questions about why it was performing backups the way it was. My biggest interest was in the mailbox-level backups, which are often unnecessary. Existing brick-level solutions use the Messaging API (MAPI) interface, so they must log on to each mailbox to enumerate and read the messages to be backed up. This process takes a long time. In addition, this type of backup loses single-instance storage, meaning that the backup takes up a lot more space and takes longer to write to tape or other offline media than other types of backup do. Exchange 2000 offers features that address the most common reasons for doing brick-level backups:
- Deleted-item retention for mailboxes and public folders lets end users restore deleted messages without any intervention from you. This ability protects you from the most common reason for mailbox restore: users who deleted an important message and need it back right away.
- Deleted-mailbox retention lets you recover a deleted mailbox during a specified retention period. This ability addresses the number-two cause for mailbox restores: a slip-up by an administrator who deleted a mailbox that should have been kept.
As it turns out, the client had a reasonably good reason to perform mailbox-level backups: Employees needed to be able to restore messages deleted at any point in time, not just during the retention window. The company was studying a range of archival products, such as CommVault Systems' Galaxy and KVS's Enterprise Vault, but was stuck performing mailbox backups in the meantime. However, after a careful look at usage patterns, the client decided it could reduce the number of mailboxes that it backed up individually and could change the schedule so that brick-level backups happened less frequently. This change helped backup times considerably because complete brick-level backups no longer took place each night.
The next step was to whittle down the size of the Store. My first suggestion was to run Mailbox Manager to help clean up mailboxes, but my client explained that the end users would revolt-—many of them used their Exchange mailboxes as their primary storage system (not uncommon, but not exactly what Microsoft intended when it designed the product). Instead, we created another storage group (SG) and three additional databases: one in the original SG and the other two in the new SG. This action gave the client four databases spread across two SGs. Exchange 2000 can back up more than one database at a time if those databases are in separate SGs. Because the client had two tape drives, the company could now back up two of the four databases in parallel—leading to a more than 50 percent improvement in the backup time requirement.
Even if you don't have multiple tape drives, splitting a large Store into smaller chunks can make good sense. Next week, I'll explore the dos and don'ts of making such a split. Until then, determine how long your Exchange backup takes. As your Store grows, be sure you can still afford the time necessary to back it up and restore it.