Tip

Structuring Exchange Server for the best log file protection

Please let others know how useful this tip is via the rating scale at the end of it. Do you have a useful Exchange or Outlook tip, timesaver or workaround to share? Submit it to our tip contest and you could win

    Requires Free Membership to View

a prize. 


Exchange Server's transaction logs are in some ways just as important as the main data store. Without them, it's impossible to recover a database completely if there's a failure.

WIth a Microsoft Exchange backup, you can restore to the point the backup was made, but not beyond that. Only log files can help you step forward from the backup to just before the actual failure. So you need to structure your Exchange server so that log files are protected independently of the data store.

The most common way to do this is to place the log files on a completely different physical disk than the Exchange information store, preferably one that's mirrored.

If you're building a dedicated Exchange server, it makes sense to set aside an extra pair of disks for the sake of the transaction logs. The initial expense will more than pay itself back if either the data store or the transaction logs become corrupted.

Since multiple storage groups use a common set of logs in Exchange 2003, you'll need to plan the size of the transaction log disks around that -- based on how often you back up and how much data flows through Exchange, since transaction logs are deleted whenever the database is backed up.

Putting transaction logs on a separate physical drive is also a performance-enhancer, but it should not be the primary reason for doing this. Transaction logs are almost never read back, unless you're replaying actions for the sake of a backup. So performance gain is not even really the issue.

It may take longer to write data to a mirrored pair of disks, but at this point in time, the performance hit from using mirrored disks is negligible -- especially compared to the performance hit that'll come with losing the log entirely!

The only time performance really becomes an issue is when the server is placed under a very heavy load, at which point it's probably time to look at an upgrade or splitting the load across more than one server. Using a decent hardware RAID controller and 10K RPM drives should negate any noticeable performance issues you'd have.

Warning: Backing up the information store to the same drive that holds the transaction logs, for the sake of convenience, is never a good idea, even if the transaction log drives are redundant (i.e., RAID 1). On the off chance that both drives fail -- and it does happen -- you've lost your transaction logs and the backups that would be used in conjunction with them. Keep your logs and the information store as redundant and segregated as possible under all circumstances.

About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter

 


Do you have comments on this tip? Let us know.


Related information from SearchExchange.com:

 

This was first published in December 2005

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.