2TB seems like such a good size for a mailbox database

I am sometimes asked about how large an Exchange mailbox database should be allowed to grow. In an era of ever-swelling mailboxes, it’s a good question. After all, if you’re going to indulge users with 100GB mailbox quotas, you have to figure out where those mailboxes will be stored.

The first thing to realize is that mailbox quotas actually have less of an influence over database sizes than you might think. Allocating someone a 100GB mailbox quota does not mean that they will fill the quota. After all, it takes time to receive sufficient messages to fill such a large mailbox, even if you decide to sign up to just about every mailing list that’s going and store every message that subsequently arrives. Assuming that 100 mailboxes of 100GB will result in a 10TB database is not correct. It might do over time, but not immediately.

The next thing to understand is that the maximum size of an Exchange mailbox database is 16TB. But this is a theoretical maximum as practical difficulties get in the way long before such a monster develops. Little things like the maximum capacity of the disks that you want to use to hold databases. Or, possibly even more important, how your backup regime works. After all, backing up (or even worse, restoring) a multi-terabyte database can take time.

The third thing is to venture into the shadowy world of “best practice” and ask what experts think. In fact, it doesn’t really matter what experts think because they’ll probably be wrong. Any text, including this, written on the topic will age rapidly as software and hardware evolve. What you can do is to look at what Microsoft says on the topic and see if that makes sense when put into the context of your own business and operational requirements.

Important guidance comes from TechNet’s “Exchange 2013 Storage Configuration Options.” The page is filled with some pretty interesting data about storage options for Exchange, including that not much has changed in terms of database maximums from Exchange 2010. Microsoft still recommends a relatively puny 200GB for non-replicated databases and 2TB for replicated databases.

The differentiation is very important. It reflects the basic Microsoft philosophy that all Exchange databases should be protected through replication because replication provides protection against so many evils that can arise through flawed storage. Some will argue that small customers cannot afford to deploy two servers just to be able to replicate databases. This is true, but I would argue that these customers should be using Office 365 or some other cloud solution instead of trying to run Exchange by themselves. It’s true that some companies are located at the end of pretty doubtful network connections that make it impractical to use the cloud, but I submit that we’re now talking about edge cases and that the advice to be protected through replication is good for the vast majority.

But it’s not just philosophy that causes Microsoft to say that it’s safe to allow replicated databases to grow 10 times larger than their standalone counterparts. There’s also the small matter of technology like single page patching included in Exchange to maximize the advantage of replicated databases.  Managed Availability is another example. Failover is the basic response to storage woes that affect a database on an Exchange 2013 server, so Managed Availability is handicapped if replicated databases are unavailable.

Of course, a single replicated copy is barely able to deliver redundancy in any meaningful sense. As the saying goes, “one replicated copy is nice, two is much better, and three provides a warm feeling of comfort.” Alongside the vast increase in resilience that comes with multiple database copies, the possibility of moving away from traditional backup strategies also arises. You might not want to go the whole hog and use Exchange Native Data Protection the way that Microsoft does for Exchange Online but you might be able to move from daily to weekly backups.

Two-terabyte databases seem like a good size to me. They accommodate a reasonable number of mailboxes; together with their logs and a good amount of space for expansion, they fit on 4TB drives; and they are not so horribly large that you fear any maintenance that might have to be done (who runs ESEUTIL today anyway?). In addition, 2TB databases are small enough to assign space for database autoreseed to take advantage of even more automation.

But 2TB replicated databases are only “best practice” and if you have good reason to run larger databases you can do so right up to that 16TB theoretical limit. But note the word “theoretical.” It’s there for a reason. ESE (the database engine) is designed to run to that maximum and the chances are that everything will work properly up to that point. But wouldn’t you look foolish if the most important message that your CEO ever wanted to send couldn’t be saved into the database because of some obscure and undocumented condition? Who wants to live on the wild side – play safe and stay away from maximum limits!

Follow Tony @12Knocksinna