An article covering some aspects of the deployment of archive mailboxes posted on SearchExchange by Brian Posey, a well-known and respected writer about Exchange, attracted my attention. While Brian makes some good points, I think the general thrust of his argument is flawed. Here’s why.

His central point is that organizations can create mailbox databases that contain only archive mailboxes and place them on low-cost storage attached to a low-end server. He says that administrators are “concerned with how much storage space the archives would consume” and that’s why they’d like to use low-cost storage.

I don’t have much argument with these statements. I do, however, argue that you should not use SATA drives with an archive server. First, while these drives are cheap, they tend to fail more often than their SAS counterparts and most administrators won’t want to be constantly monitoring archive servers to detect and fix failed drives. I think it makes more sense to invest a little more money and deploy SAS drives deployed in a RAID-1 array to host archive mailboxes. Something like the HP MDS 600 would do the job nicely but there are many other good, reasonably-priced SAS-based direct-attached storage modules available today. The extra hardware investment is justified by the lower operational cost. (the question has to be asked if your archives are worth anything, shouldn’t they be protected by reasonable storage?). If you do decide to use JBOD, be sure to follow the advice from the Exchange development group and deploy at least three database copies to protect your data and use high-quality 7200 rpm disks.

Brian then goes on to say that low-end hardware “can be problematic if you introduce DAGs (Database Availability Groups)”. His statement that DAG’s don’t distinguish a database that contains archive mailboxes is absolutely true. This is part of the charm of Exchange 2010 – that you can mix and match mailbox types to meet the precise needs of your organization. But Brian then says that creating an archive database in a DAG causes problems because “DAGs require each database copy to use the same storage path, which can be an issue if the archive server is using SATA storage.”

Hmmm… again, he’s absolutely on the money when he states that each database copy in a DAG requires the same storage path pointing to the database files and transaction logs (think E:\ARCHIVE\DB1-ARCHIVE.EDB).  I guess this might be an issue if you run out of drive letters on your server, but there are ways around that issue (mount points anyone?). See TechNet for more details about Exchange 2010 storage.

The biggest argument I have is with the statement that “You’ll also need to provide enough storage space for each server in the DAG to store a copy of the archive database.” This is factually incorrect. You absolutely need to create sufficient copies of a database within a DAG to provide resilience against failure. In most cases, three database copies is sufficient and I expect that this will be the optimum situation for archive databases (the more paranoid amongst us might favour four copies). I think that any DAG that hosts archive servers will have more than five member servers so you wouldn’t have to create copies of the archive databases on two of the five servers. Note that it’s a well-known tenet of DAG design that DAGs that have more member servers are more flexible and resilient against failure than those with fewer members. In other words, given the choice between deploying two DAGs of three members each and one of six, I’d always go with the larger DAG.

The article ends by recommending that you consider creating a low-end DAG to host archive mailboxes. I don’t go along with this advice because I think it makes more sense to incorporate a dedicated archive server (if that’s what you want to use) alongside the other servers within a DAG to provide a single entity to be managed. I just don’t see an advantage of having a separate DAG that’s dedicated solely to user archives and prefer the flexibility of being able to distribute a couple of passive copies of archive databases across other DAG members so that these copies are available and can be automatically activated just in case something goes wrong with the archive server.

Please don’t get the idea that I condemn Brian for advancing his ideas in his article. We’re at the start of defining best practice about the most efficient and effective deployment tactics for entities such as dedicated archive servers and I expect that many will support his perspective. That’s OK too – the important thing is that we debate the issues and gradually come to a view as to what best practice actually is that’s based on hard knowledge of operational realities encountered in real life deployments. For example, the question of RTO/RPO for archive data needs to be discussed in a deployment scenario so that everyone understands how quickly archive data can be restored if the need occurs. Another important point to discuss is the purpose of the archive database. After all, now that Exchange 2010 supports massive (in comparative terms to what we have had before) mailboxes of 25GB or larger, maybe you don’t need them as you can keep everything in the regular database and use retention policies to help users keep swelling folders under control? Of course, you might end up with a massive OST as well, but that’s another day’s work!

Let the discussion begin!

–  Tony

Need more information about Exchange 2010 archives? Read all about the topic in Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk. The book is also available in a Kindle edition. Other e-book formats for the book are available from the O’Reilly web site. Or if you’d like to discuss the topic in person, come to an Exchange 2010 Maestro training event and debate the finer points of this and other interesting areas of Exchange with Paul Robichaux and myself.