Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What kind of storage configuration would you recommend for a small Exchange server deployment supporting about 50 users? Probably won't grow past 75 users in 3 years. Majority will be "medium" users, with a few "heavy" users and BlackBerry clients.

So far, everything that I've read suggests keeping the Exchange database and the transaction logs on separate physical drives, and keeping both of those off of the system drive. It also says to put the transaction logs on something fast, like a Raid 1+0 array. Considering that all the data needs to be protected, it looks like this would be an optimal setup:

System drive - 2 small drives in RAID 1 Exchange database - 2 big drives in RAID 1 Transaction logs - 4 fast drives in RAID 1+0

However, using 8 drives for a tiny Exchange server seems like incredible overkill. Where would it be safe to cut back?

share|improve this question
up vote 4 down vote accepted

Even with heavy users and a lot of headroom you are not going to see much more than 2 IOPS per user and you will probably never even break 1 IOPS per user if it's a small environment like this [See this Technet article. Even taking a fairly conservative number of 80 IOPS per drive (assuming you opt for large 7200rpm SATA drives for the data) and factoring in the double IOPS overhead for write IO, you should still be fine with lumping all the Exchange data and logs onto a two drive RAID1 pack. If you have the option and want to isolate the logs, then by all means go ahead but you are never going to stress a half decent 2-drive RAID-1 set up with the sort of IO that your Exchange environment is going to generate even at 75 users.

share|improve this answer
+1 - I agree. I'd probably put the transaction logs on the RAID-1 set with the operating system, and the database onto another RAID-1 (since the OP mentioned he might want to get down to 4 disks). That'll offer some redundancy in case of losing either spindle (since you'll still have either the database or transaction logs intact). Realistically, you could do it on 2 drives and be just fine, but I'd sleep better w/ the separate spindles for the database and transaction logs, personally. – Evan Anderson Oct 18 '09 at 23:59
Good point Evan - it's always a good idea to get as much use out of the available redundancy as possible. – Helvick Oct 19 '09 at 0:04
This is exactly the kind of answer I was looking for. We tend to be more limited by capacity than performance, so I think two RAID 1 sets of SATA drives will be perfect. – Nic Oct 19 '09 at 0:39

I'd say the first place to cut back would be not using striping for the t-logs. On such a small server you really don't need striping-backed performance there.

You could also consider not putting the logs on a separate storage, but the first thing I'd cut would be the two extra drives for striping and just run two drives in RAID 1 for the t-logs.

share|improve this answer
That sounds like a great start. If I wanted to get down to 4 drives, should I put the database or transaction logs on the system drive? – Nic Oct 18 '09 at 21:41

How much traffic will each user generate? This is quite an important factor to take into account. How much storage per user? How much growth a day?

Whatever you do, don't cut down on RAID. Use at least RAID 1 for each volume. A crashed server because of a single disk failure is definitely something you don't want.

Also, there's a really good reason to physically separate databases from transaction logs: disaster recovery. It's really, really bad to have them on the same volume, because you risk losing both at the same time. If you by chance lose your database, you want to have you transaction logs ready, otherwise the most you can do is restore your last full backup (which may be from some days before the crash).

Summary: RAID 1 for the O.S., RAID 1 for transaction logs, RAID 1, 5 or 10 (depending on your storage needs) for database(s).

share|improve this answer
That's a great point about the reasoning for separation of transaction logs and database. Do people normally also back up transaction logs at all? – Nic Oct 19 '09 at 0:36
That would be pointless, because they're automatically truncated when you do a full database backup. The only time you need them is when you're restoring (but you WILL need them, then). – Massimo Oct 19 '09 at 5:55

With the small number of users you have, I don't think you should be going too far down the route of optimizing storage. Bottom line is, unless you do something completely daft, the storage subsystem is not going to be a bottleneck. So take some basic common sense recommendations and don't worry overly much about it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.