Planning Your Disk Space Requirements

Disk space is one of the requirements of Exchange that most often confuses people or is not figured properly. The disk space requirements for supporting the Exchange server itself are relatively straight forward. The disk volume on which Exchange Server 2007 is installed requires approximately 1.2GB of disk space; the system disk requires another 200MB of disk space. If the Exchange server is supporting the Unified Messaging server role, plan for an additional 500MB of disk space for each Unified Messaging language pack that will be installed.

The operating system disk should also have sufficient free disk space to allow a page file that is at least the amount of RAM plus 100MB. This is to allow Windows to dump the memory in the case of an operating system crash. Exchange servers that support larger numbers of mailboxes often have dedicated spindles or partitions just for the page file.

Figure 3.11 shows a conceptual diagram of an Exchange 2007 mailbox server that is designed to support 1,000 mailboxes. In the following section we will explain the process through which we went to estimate the storage required. In some cases, we picked a typical large drive size. Mailbox servers are by far the biggest consumers of disk storage, and this is something you must plan for. You must also be prepared for growth.

Figure 3.11: Disk configuration for an Exchange 2007 Mailbox server

We have also taken into consideration the use of local continuous replication (LCR) in Figure 3.11 and thus have allocated disk space for it. Ideally, transaction logs and the operating system are on dedicated RAID-1 spindles and the databases are on dedicated RAID-5 spindles. Even though we have labeled this figure as having local drives, you could deploy this same configuration using iSCSI or SAN disks. We estimated 72GB of space for the operating system, page file, and Exchange binaries, 146GB for the transaction log volume, and 2.6TB of space for the database volume.

Mailbox Server Storage

Exchange servers holding the Mailbox server role consume the most disk space. Where Exchange system designers often fall short in their designs is that they do not allow sufficient disk space for mail storage, transaction logs, and extra disk space. Often the disk space is not partitioned correctly, either. Here are some important points to keep in mind when planning your disk space requirements:

• Transaction log files should be on a separate set of physical disks (spindles) from their corresponding Exchange database files. RAID-1 or RAID-0+1 arrays provide better performance for transaction logs.

• Allow for at least 7 to 10 days' worth of transaction logs to be stored for each storage group. The estimated amount of transaction logs will vary dramatically from one organization to another, but a good starting point is about 5GB of transaction logs per day per 1,000 mailboxes.

• Allow for 10 to 15 percent white space estimates in the maximum size of each of your database files.

• Allow for 10 to 15 percent deleted item and deleted mailbox retention space in each database file.

• When planning for local continuous replication, make sure the replicated transaction logs and backup copy of the databases are on separate physical disks from the source.

• Allocate enough free space on the disk so that you can always make a backup copy of your largest database and still have some free disk space. A good way to calculate this is to take 110 percent of the largest database you will support since that also allows you to defragment the database using ESEUTIL if necessary.

• Consider additional disk space for message tracking, message transport, HTTP protocol, POP3 protocol, and IMAP4 protocol log files.

So, to use some of these points when calculating necessary disk space, here is an example for a server that will support 1,000 mailboxes. Further, we are estimating that we will provide the typical user with a "prohibit send" size warning of 500MB and a "prohibit send and receive" limit of 600MB. In any organization of 1,000 users, you have to take in to consideration that 10 percent will qualify as some type of VIP that will be allowed more mail storage than a typical user; in this case, we will allow 100 VIP users to have a "prohibit send and receive" limit of 2GB.

This gives us 540GB of mail storage requirements (600MB times 900 mailboxes) for the first 900 users plus another 200GB (2GB times 100 mailboxes) for the VIP users. This is a maximum amount of mail storage of 740GB. However, this estimate does not include estimates for deleted items in a user's mailbox and deleted mailboxes, so we want to add an additional overhead factor of about 15 percent, or about 111MB, plus an additional overhead factor of another 15 percent (another 111MB) for database "white space." The white space is the empty space that is found in the database at any given time.

So at any given time, for these 1,000 mailboxes, we can expect mail database storage (valid e-mail content, deleted data, and empty database space) to consume approximately 962GB, but since we like round numbers, let's average that up to 1,000GB, or 1TB.

In this example, let's say that we have decided the maximum database size we want to be able to back up or restore is 100GB. This means that we need to split our users' mailboxes across 10 mailbox databases and storage groups.

For the transaction logs, we estimate that we will generate approximately 5GB of transaction logs per day. We should plan for enough disk space on the transaction log disk for at least 50GB of available disk space.

Next, since full-text indexing is enabled by default, we should allow enough disk space for the full-text index files. In this case, we will estimate that the full-text index files will consume a maximum of about 5 to 10 percent of the total size of the mail data, or approximately 100GB. If we combine the full-text index files on the same disk drive as the database files, we will require approximately 1.3TB of disk space.

Finally, on this server we are planning to implement local continuous replication, so we will need to plan for a separate set of spindles for the databases (1.3TB) and the transaction logs (50GB).

Anytime there is any doubt as to how much disk space you should include, it is usually a good idea to plan for more rather than less. Although disk space is reasonably inexpensive, unless you have sophisticated storage systems, adding additional disk space can be time consuming and costly from the perspective of effort and downtime.

Planning for Growth

Growth?! You may be saying to yourself, "I just gave the typical user a maximum mailbox size of 600MB and the VIPs a maximum size of 2GB! How can my users possibly need more mailbox space?" Predicting the amount of growth you may need in the future is a very difficult task. You may not be able to foresee new organizational requirements or that you might be influenced by future laws that require specific data retention periods.

In our experience, though, mailbox limits, regardless of how rigid you plan to be, are managed by exception and by need. In the preceding example, we calculated that we would need 1.3TB of disk space for our 1,000 mailboxes. Would we partition or create a disk of exactly that size? Probably not.

Instead of carving out exactly the amount of disk space you anticipate needing, add a "fluff factor" to your calculations. We recommend doubling the anticipated amount of storage you think you will require, but this is just a wild guess. In this example, though, we might anticipate using 2.6TB of disk space if we doubled our expected requirements. Here are some factors that you may want to consider when deciding how much growth you should expect for your mailbox servers:

• Average annual growth in the number of employees

• Acquisitions, mergers, or consolidations that are planned for the foreseeable future

• Addition of new mail-enabled applications such as Unified Messaging features or electronic forms routing

• Government regulations that require some types of corporate records (including e-mail) to be retained for a number of years.

Conversely, there are potential things in your future that could actually reduce the amount of mailbox storage you require. Many organizations are now including message archival and long-term retention systems in their messaging systems. These systems archive older content out of a user's mailbox and move it to some type of external storage such as disk, SAN, NAS, optical, or tape storage. The user can still access or search for archived content, but it no longer takes up space in your Exchange server mailbox databases.

Archive systems are great for organizations that must retain much of the information in their mailboxes but want to move it to external storage. However, depending on the system, you don't want to archive everything older than five days since the user may not be able to access it via Outlook Web Access or mobile devices. Further, once the content is archived from their mailbox, it will not longer be accessible from a user's desktop search engine such as the Google Desktop or the Windows Desktop search engine. So keeping a certain amount content in the user's mailbox will always make sense.