I am going to order a new exchange server soon and want advice on the RAID setup. My current plan is as follows. Is my idea sensible?

This will be a single server housing the Mailbox, CAS and Hub transport roles. We're not using Unified Messaging.

Server is a HP DL380 G7 and has 8 disk drive slots.

Disks 1 & 2 (146GB) - RAID1, Operating System (Windows Server 2008 R2)
Disks 3, 4, 5 & 6 (300GB) - RAID5, Exchange Databases
Disks 7 & 8 (72GB) - RAID1, Exchange transaction logs



If you've got a heavily used Exchange server with lots of mailboxes, mobile access (Blackberry, Windows Mobile, etc.), and\or Outlook plugins then I'd suggest configuring 4 drives as RAID10 instead of RAID5. If there's heavy disk I/O then RAID5 is going to kill your performance and you'll have users complaining constantly about their email client being slow.

  • Nice drive-by downvote. Whomever it was, you obviously haven't worked with Exchange server very much or you don't know what you're doing if you do work with it. – joeqwerty Aug 6 '10 at 16:42
  • Fixed. There sure is a lot of unearned love for RAID5 around here. – Skyhawk Aug 6 '10 at 16:54
  • Joe, I downvoted your discouragement of RAID5, with which I respectfully disagree. That was very true with Exchange 2003, but the storage I/O optimizations in Exchange 2007 and then 2010 on top of that makes RAID5 completely valid, even with the presence of mobile devices. Exchange 2010 requires 90% less disk I/O comparably to Exchange 2003. Honestly, the viability of RAID5 for the original poster could only be settled using the Exchange storage calculator, but RAID5 is viable for many orgs. Regardless, blanket statements about RAID5 being bad are no longer valid with E2K10. – amargeson Aug 6 '10 at 18:50
  • 1
    @amargeson: While I respect your opinion, I think downvoting because you disagree is inappropriate. Down vote if I'm wrong but not because I have a different opinion. While you're opinion that RAID5 is a perfectly acceptable configuration, my suggestion to use RAID10 is equally valid. – joeqwerty Aug 6 '10 at 19:18
  • @joeqwerty It's invalid to suggest you should use RAID10 with Exchange 2010 just because. Telling other people they don't know Exchange if they disagree with you is unacceptable. If you know E2K10, you know the disk i/o requirements are far less. That's a fact. I downvoted because those comments shouldn't be towards the top of the list because anti-RAID5 hand rules are irrelevant with E2K10 because they aren't useful. Use the storage calculator instead of assuming RAID5 is bad. – amargeson Aug 6 '10 at 20:22

I think your setup looks good. Exchange 2010 architecture requires considerably less disk I/O - upwards of 90% less than 2007. One thing you don't specify is the number of users supported, but overall I think your design is solid. You should see excellent performance.


I guess this configuration will work well, but how many raid cards will you order?

Two maybe enough, one for disks 1&2 and 7&8, and another for disks 3-6. Ensure the raid card support 4 disks.

  • Any decent RAID card today supports around 200 discs. Only VERY heap astuff is still using SATA as connectivity- all decent stuff is SAS based. – TomTom Aug 6 '10 at 10:36
  • It's a HP DL380 G7 - I updated the question. – mark Aug 6 '10 at 10:56
  • What @TomTom tells is rights, but I write so because many server include an integrated raid card with some limits. – lg. Aug 6 '10 at 11:52

That is indeed the recommended setup for a Mailbox server with a single database.

  • Thanks, this will be a single server installation, so it will have Mailbox, CAS and Hub roles. We aren't going to be using Unified Messaging. – mark Aug 6 '10 at 10:57

I personally recommend against RAID 5; you can have a drive with an unrecoverable error that doesn't get reported, then another disk suffers a full failure and the array won't rebuild. We had it happen on a Dell system. The system had to be restored from full backup.

Your setup should work, and might not give trouble for some time, but if you want to maximize your reliability I think I'd rather opt for RAID 10 now. There are other questions I've answered about RAID with links to articles about RAID 5 and URE's; the problem has gotten worse with improved drive densities.

  • +1 I would also try to opt for a database store on RAID10 or RAID6 or RAID5 with 3 disks and a hot-spare - if space permits. – Oskar Duveborn Aug 6 '10 at 13:07
  • 1
    I disagree with the RAID 5 discouragement. Whatever issue you had must be extremely rare (though I'm certainly curious about it). Additionally, Exchange 2010 requires far less disk utilization, so a RAID 5 should be more than adequate performance-wise... – Jes Aug 6 '10 at 14:49
  • Google "unrecoverable read error raid 5" and you'll see exactly what I'm talking about. As drive densities increase, it's NOT all that rare. – Bart Silverstrim Aug 7 '10 at 0:19

everyone case is different, so no need to be disparaging to one another. What vital information that wasn't asked or missing from the original post is what kind of redundancy he wants or has in mind in addition to any DR plan with what hardware to support it, and what is an acceptable amount of loss if you choose a point in time backup/restore.

I personally have RAID5 (HP MSA Array - iSCSI) for our Exchange 2010 based on <50 users. We run backup to disk and VM snapshots on a daily and weekly basis respectively. Along with Tape backups for end of month. The performance is good initially but over time if your users don't archive their mail or you dont set policies to manage mailbox sizes or archiving then you will run into performance issues with DB growth. RAID5 has great Read whilst slower write, whereas RAID10 is generally equal in both read/write. It's all down to how much redundancy/fault tolerance you want. I've had 1 drive failure, on a RAID5 the rebuild time was long and performance dropped slightly for users but that is to be expected and if adequet notice is given to users then its generally accepted.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy