This article can also be found in the Premium Editorial Download "IT in Europe: Break free with open source storage."
Download it now to read this article plus other related content.
Another consideration to take into account is the journal mailbox. If you use journaling to archive messages at the hub transport level then all the archived messages are placed into the journal mailbox.
I've never come across any Microsoft best practices for the placement of journal mailboxes, but I like to put the journal mailbox in its own mailbox database. This is because the journaling process tends to be very I/O intensive and placing the journal mailbox in a dedicated mailbox database ensures its I/O doesn't degrade the performance of the other mailbox databases. If all messages are journaled, locating the journal mailbox within the same store as the user mailboxes will double the I/O requirements because Exchange 2010 doesn't use single-instance storage. In other words, journaling causes an extra copy of each message to be created within the mailbox store.
If you were to create the journal mailbox in the same database as the user mailboxes, it would have a major impact on the replication process (assuming that database availability groups are being used -- see "Protecting Exchange Data," below).
|Protecting Exchange data|
Exchange Server has always been somewhat difficult to protect. If you do a traditional nightly backup of your Exchange servers, a failure could potentially result in the loss of a full day's worth of messages. For most companies, such a loss is unacceptable.
Exchange administrators have taken a number of different steps to prevent substantial data loss. In Exchange 2007, for example, it was a common practice to use continuous replication to replicate mailbox data to another mailbox server. A continuous replication solution provides fault tolerance and acts as a mechanism for protecting data between backups. (Of course, using a continuous data protection solution such as System Center Data Protection Manager is also a good option.)
Some observers feel Microsoft is working toward making Exchange Server backups completely unnecessary. The idea is that Database Availability Groups will eventually make Exchange resilient enough that you won't need backups.
Database Availability Groups are an Exchange 2010 feature that lets you create up to 16 replicas of a mailbox database. These replicas reside on other mailbox servers, and it's even possible to create database replicas in alternate data centers. Despite the degree to which Database Availability Groups can protect mailbox data, you shouldn't abandon your backups just yet.
Having multiple replicas of each database makes it easier to protect Exchange Server, but if a mailbox database becomes corrupted or gets infected with a virus, the corruption or viral code is copied to the replica databases.
But Microsoft does offer a delayed playback feature in which lagged copy servers are used to prevent transactions from being instantly committed to replica databases. If a problem occurs, you'll have enough time to prevent the bad data from being committed to a replica database. Once you've stopped the bad data from spreading, you can revert all your mailbox databases to match the state of the uncorrupted replica.
While this approach sounds great in theory, Microsoft still has a lot of work to do to make it practical. Right now the procedure requires you to take an educated guess as to which transaction log contains the first bit of corruption and then work through a complicated manual procedure to prune the log files. So while Exchange 2010's storage architecture makes it easier to protect your data by way of Database Availability Groups, you shouldn't rely on them as the only mechanism for protecting Exchange data.
Another advantage to locating the journal mailbox in a separate mailbox database is that it makes it easy to manage storage quotas and message retention based on mailbox function. You can create one set of policies for user mailboxes and another set of requirements for the journal mailbox.
This was first published in April 2011