Unsolved
This post is more than 5 years old
161 Posts
0
1600
Some thoughts on Exchange Log LUN size design
I encountered some LUN size issue runnning Exchange sizing. Hypothetic workable formula Log LUN size = (logs per day, per mailbox)*(number of mailboxes per database)*(protection buffer from log truncation failure, in days)*(free space requirement factor). The third parameter (protection buffer from log truncation failure, in days) triggers my interets on the value. The sample from WP presents 3 as usual option. But from Microsoft Calc side, the value set is varied from Backup Frequency option(Daily Differential/Daily Incremental).
I have not much experience on Exchange Backup operation. Shall we have any best practice on the parameter (protection buffer from log truncation failure, in days) or in other word which backup methodology adopted according to specific scenario? Because it is effecting a lot on Log LUN size design.
BryanWalsh
11 Posts
1
January 13th, 2012 04:00
Ross recently wrote up a blog regarding this topic. However, my general rule of thumb is 7 days instead of 3.
http://blogs.technet.com/b/exchange/archive/2011/11/09/capacity-planning-yes-transaction-log-space-is-critical-to-keeping-your-databases-healthy-and-mounted.aspx
pgaljan
61 Posts
2
January 13th, 2012 06:00
I agree with Bryan – my recommendation is typically 7 days (and then some). In theory, this is so that you can tolerate backup failures for 7 days – presumably failed backup jobs won’t truncate the logs. If you have a couple failures in a row for whatever reason, you may run out of space on the logs LUN, thereby stopping the database. But in reality, it helps mitigate transient issues that generate an abnormal volume of transaction logs (mailbox migrations, MAPI issues, bugs and that sort of thing). You want to make sure you have enough runway to recognize and resolve the problem before the whole database comes down. I don’t think 3 days is enough.
As it turns out, many of my configurations are nl-SAS lately, and there’s nothing about a normal Exchange log workload that precludes it. A handful of nl-SAS disks dedicated to transaction logs results in lots of capacity, so I don’t usually have to worry about it.
--paul