Log files are vital to how Exchange Server functions. Brush up on how log files have changed in Exchange 2013 to protect your setup against disaster.

Exchange Server 2013 improvements show Microsoft is focused on using physical servers and Exchange data protection features to protect against disaster. A new Exchange install shouldn't look to older, unsupported methods for recovery, such as disks filling up unexpectedly and logs that must be manually removed. Ensuring that Exchange is properly designed before a disaster strikes relies on built-in functionality to protect against outages.

We'll look at some of the new and updated Exchange Server transaction log features to help you prepare for and recover from disaster.

Exchange is similar to traditional database servers in that it uses databases and log files. As with Microsoft SQL or Oracle databases, changes are written to the transaction log files before being committed to database files. From Exchange 2010 onward, there is a 1:1 relationship between each database and its corresponding log files; if there is a database, you can be sure to find corresponding log files.

Why log files are important in Exchange Server

Database files in Exchange Server have the file extension "EDB" and, as you might guess, the log files have the extension "LOG." To complement these files, we'll also find the checkpoint file; for example, "E00.CHK."

Like the database itself, the log files are not in a form that humans can read; unlike Web server log files, you can't open them in Notepad. The log files are effectively a binary record of the changes made to the database, such as delivering a new email message or moving a mailbox between databases. Each log file is a maximum of 1 MB in size.

If Exchange is backed up using legacy backup software, the Exchange log files are typically left in place until the next backup. The full or incremental backup will then delete old log files, freeing up space. A badly managed Exchange Server will typically suffer from failures due to log drives filling up, a symptom of not monitoring backups.

This isn't an issue with modern Exchange deployments, which use the server's native backup features. They have circular logging enabled, meaning logs can be removed as soon as the data is committed to disk.

Multiple databases per disk

Using multiple databases per disk is a new Exchange Server 2013 feature that directly relates to log files. This might not sound entirely new, as many Exchange admins and architects have done this for Exchange backups using legacy software against their better judgment. In older Exchange versions, this often meant two large RAID volumes were created -- one for databases and one for logs. The bad thing about this is there would be a large, catastrophic outage if a single volume filled up.

As you might expect, multiple databases per disk is different in Exchange 2013. It should be used with Exchange Native Protection, which replaces legacy backup methods in modern Exchange deployments. In Exchange 2010, this concept was aimed at using a single database and log combination per non-RAID disk and then using multiple database copies spread across multiple servers, or RAID at the server level.

The maximum supported database size in Exchange 2013 remains at 2 TB. With larger disks available, Exchange 2013 was designed to allow multiple database and log file sets to reside on single disks. In the event of a disk failure, multiple databases fail over to another server; the automatic re-seed process -- copying the database from another server -- also completes more quickly, as it benefits from the ability to re-seed from multiple database copies rather than a single copy. A re-seed for 2 TB that would take 23 hours, for example, might only take 9.7 hours using multiple copies.

Benefits of loose truncation in Exchange Server

With Exchange Native Protection, log files are no longer needed after the transactions are committed to disk on available copies. By default, circular logging will keep the Exchange Server transaction logs around until they have been replayed on all copies. Therefore, if a disk fails and a database copy is offline, transaction logs will continue to build on the disks containing the remaining copies. If the disk isn't replaced in time, disks containing the remaining copies will eventually fill up and the databases will dismount.

Loose truncation helps prevent this outage from occurring. If a disk is lost, the only way for that copy to be recovered will be through a database re-seed, which means that the logs kept for replay are less relevant. Loose truncation was introduced in Exchange 2013 SP1 and allows the offline copy that won't catch up to be ignored and truncation to be performed against remaining copies.

In practice, this enables a set of registry values on the Exchange 2013 mailbox servers to specify the minimum number of passive copies to protect against loose truncation and the threshold before loose truncation is triggered. After switching on loose truncation and leaving thresholds at default settings, logs won't be expunged until there is less than 200 GB free on a passive copy. This means temporary maintenance such as a reboot won't trigger loose truncation.

Automatic log replay for lagged copies

Automatic log replay is new in Exchange 2013 and relates to lagged copies, which are database copies in which transaction logs aren't immediately replayed. Lagged copies allow administrators using Exchange Native Protection to guard against logical corruption of the database. Even though lagged copies aren't used for high availability, they are designed for disaster recovery and count as one of the mailbox database copies in a Database Availability Group.

In general, lagged copies ensure that a mailbox database lags behind active copies for a set amount of time. This helps admins ensure that, if the worst happens, they can roll transaction logs forward to a point just before corruption.

Automatic log replay ensures a log replay will activate in the event of a non-corruption-based disaster. When the feature is enabled, it replays Exchange Server transaction logs when fewer than three healthy copies remain, such as when you lose two copies of the mailbox databases at once. Additional automatic log replay can protect against low disk space scenarios on the lagged copy server. This ensures that if Exchange has been unusually active, the lagged copy can roll forward and expunge logs rather than stop functioning when disk space is exhausted.

About the author: Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners. Goodman has worked extensively with Microsoft Exchange since version 5.5 and with Office 365 since its origins in Exchange Labs and Live@EDU.

Join the conversation

2 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Your password has been sent to:

Please create a username to comment.

Using physical services exchange data protection features to protect against disasters exchange is properly designed before a disaster strike relies on built in functionality to protect against outages