Exchange transaction logs filling the disk: backups, circular logging and safe recovery

Exchange never changes a database without writing the change to a transaction log first, so the log volume is the first thing to fill up when backups quietly stop working or a migration is running. When it hits zero, the database dismounts and everyone on it is offline. In this post I'll show why logs aren't being truncated, how to buy space without losing data, and how to use circular logging deliberately rather than in a panic.

Symptoms#

The Application log shows ESE event 413:

Unable to create a new logfile because the database cannot write to the log drive. The drive may be read-only, out of disk space, misconfigured, or corrupted.

Around it you typically see:

• Free space on the log volume falling fast, with thousands of 1 MB files named after the database's log prefix (for example E01000A2F3C.log).
• The database dismounted: Get-MailboxDatabase -Status shows Mounted : False and Outlook disconnects.
• After space is freed, mount attempts failing with recovery errors such as Database recovery/restore failed with unexpected error -510.
• In a DAG, logs growing on every copy, not just the active one.

Why it happens#

Logs are removed (truncated) in only two ways: after an Exchange-aware full or incremental backup completes through the Exchange VSS writer, or continuously when circular logging is enabled. A DAG adds a condition: a log can only be truncated once every copy has copied and inspected it and the non-lagged copies have replayed it, while lagged copies keep logs for their lag period. Anything that breaks those conditions, or generates logs faster than usual, fills the disk:

How to fix it#

1. Work out how much time you have#

On the server that hosts the active copy, count the logs, then repeat after 30 minutes to see the rate:

$db = Get-MailboxDatabase DB01
$logs = Get-ChildItem -Path "$($db.LogFolderPath)" -Filter "$($db.LogFilePrefix)*.log"
"{0} logs, {1:N1} GB" -f $logs.Count, (($logs | Measure-Object -Property Length -Sum).Sum / 1GB)
Get-MailboxDatabase -Status | Format-Table Name, Mounted, LastFullBackup, LastIncrementalBackup, CircularLoggingEnabled -AutoSize

If the volume will be full within hours, extend it first. Adding space is the only fix with no side effects.

2. Don't delete log files#

Logs newer than the checkpoint hold changes that aren't in the .edb file yet; deleting them leaves the database in Dirty Shutdown with data loss. Older logs are your roll-forward chain for a restore, and in a DAG the passive copies may still need them. Leave the small reserve log files in the folder alone too — ESE keeps them so it can shut the database down cleanly when the disk fills.

3. Get the backup working#

vssadmin list writers

The Microsoft Exchange Writer (since Exchange 2013 it runs inside the Microsoft Exchange Replication service and handles active and passive copies alike) should show State: [1] Stable and Last error: No error. Configure the job as an application-aware full backup of the databases, run it, and check that LastFullBackup updates. Truncation follows the completed backup; in a DAG it then happens on every copy once replication catches up.

4. Use circular logging as a controlled tool#

Set-MailboxDatabase DB01 -CircularLoggingEnabled $true

On a database without copies this is JET circular logging, which takes effect only after Dismount-Database DB01 and Mount-Database DB01. On a database with DAG copies it's continuous replication circular logging (CRCL), which applies immediately without a dismount.

Running CRCL permanently is a sound design only as part of Exchange Native Data Protection, with enough DAG copies — often including a lagged copy — to stand in for backups.

5. Find what is generating the logs#

Get-MoveRequest -MoveStatus InProgress
Get-StoreUsageStatistics -Database DB01 | Sort-Object TimeInServer -Descending | Select-Object -First 10
Get-MessageTrackingLog -Start (Get-Date).AddHours(-1) -EventId DELIVER -ResultSize Unlimited |
  Group-Object { $_.Recipients -join ';' } | Sort-Object Count -Descending | Select-Object -First 10 Count, Name

Moves into a database generate roughly as much log data as the mailboxes they bring in, so schedule or throttle migration batches (see hybrid migration batches). Get-StoreUsageStatistics lists the busiest mailboxes on the database, and a recipient receiving thousands of deliveries an hour usually points to a mail loop or a runaway application.

6. If the database already dismounted#

Free space with one of the steps above, then run Mount-Database DB01; ESE replays the outstanding logs during the mount. If it refuses, follow Exchange database won't mount. In a DAG, also resume or reseed any copies that failed while the disk was full.

Verify the fix#

• The log count from step 1 drops shortly after the backup completes, and the growth rate returns to your normal baseline.
• LastFullBackup shows today's date and CircularLoggingEnabled has the value you intend.
• Get-MailboxDatabaseCopyStatus DB01\* shows Healthy copies with low CopyQueueLength and ReplayQueueLength.
• The database is mounted and no new ESE 413 events appear.

Prevent it next time#

• Size log volumes for your daily log generation multiplied by the number of days a backup could be missed, plus headroom for migrations.
• Alert on free space early, and on the age of LastFullBackup rather than trusting the backup console alone.
• Before a large migration, increase backup frequency or enable circular logging temporarily — and plan the full backup that follows.
• Keep logs off the system drive and off the volume that holds the transport queue database, so a filling log drive can't also trigger back pressure.

References#

• Configure circular logging for a mailbox database (Microsoft Learn)
• Get-StoreUsageStatistics (Microsoft Learn)