ISBN 9781787126930 identifies Exchange Backup and Disaster Recovery
When Exchange log growth turns recovery into a race
The hard part of Exchange recovery is often not the database itself. It is the log stream beside it. Logs tell Exchange what changed, in order, and they are the first place storage pressure shows up when a mailbox database is busy.
I treat log count as a simple warning signal. If the log directory grows past a set threshold, the database may still be mounted, but the environment is already telling a story. That story matters because log growth can point to delay in backups, lagged copy replay, or a storage path that is not keeping up.
Reading mounted databases the right way
A mounted database is one that Exchange is actively using. That matters because the recovery picture changes once a database is online. In practice, the first step is to ask Exchange for database status and then keep only the mounted ones.
From there, I build one object for each database. The object holds the database name, the log path, the server name, and the number of files in the log folder. The log path needs one small fix before it can be used as a UNC path. The colon in the drive letter becomes a dollar sign, so C: becomes C$. That turns a local path into a network path that another system can read.
The log count itself comes from the folder, not from file names. I count every file in that location. That is fast, and in this use it is good enough. Extra non-log files are rare and do not change the value much.
A simple example makes the idea easier to see. If a mounted database stores logs in C:\Exchange\Logs, the UNC form becomes something like \\TLEX1\C$\Exchange\Logs. If that folder holds 1,200 files and the threshold is 1,000, the database is not broken, but it is overdue for attention.
Turning the counts into an alert
The point of collecting data is to make one clean decision. If any mounted database has a log count above the threshold, the script raises a Boolean flag. A Boolean is just a true-or-false value. In this case, true means at least one database has crossed the line.
After all databases are checked, the script looks at that flag. If it is true, it sends an email alert to administrators. That is the practical value of the check. It turns a growing folder into a visible warning before the problem becomes a restore event.
If the script is run by hand, it also prints the database details to the screen. That gives a live view of the database name, server, log path, and log count. In a pressure moment, that is often easier to trust than a folder view in File Explorer.
The logic is plain. Find mounted databases. Measure log growth. Compare it with a threshold. Alert when any database passes that line.
What lagged copies do when space or health drops
Lagged database copies need special care because Exchange may replay logs for them on its own. Replay means Exchange applies saved log records to bring a copy forward. That replay can happen even when the copy is meant to stay behind.
Three common triggers push Exchange into automatic play down. The first is low free disk space, below 10,000 MB. The second is physical corruption in the lagged copy that needs page patching. The third is when fewer than three healthy copies stay available for more than 24 hours.
That is the part many people miss. A lagged copy is not frozen forever. Exchange protects itself. If the system decides the copy is too risky to leave behind, it starts replay work.
How ReplayLagManager changes the timing
In Exchange 2016 CU1 and later, ReplayLagManager is on by default. It watches lagged copies and helps decide when to replay logs. That does not mean replay happens at once in every case. Disk I/O latency now matters too.
If read latency rises above 35 ms, play down is deferred. If latency falls below 25 ms, replay resumes. The idea is simple. Exchange waits when the disk is too slow, then starts again when the path clears.
There is one hard exception. If the disk is short on free space, latency deferral is ignored. In that case, Exchange moves immediately. Space pressure wins over delay.
The default maximum deferral is 24 hours. That limit matters because it keeps a lagged copy from staying stale for too long. The delay can be changed with ReplayLagMaxDelay, such as setting 12 hours for one copy on one server. It can also be set to zero to disable deferred play down. But even that control does not override a disk that has run out of space.
Why log review and lagged copy replay belong together
These two subjects belong in the same lesson because they both deal with control under pressure. Log counting shows where growth is getting out of hand. Lagged copy replay shows how Exchange reacts when safety and storage collide.
An administrator who only looks at mounted status can miss the drift. A database can be online and still be in a bad shape for recovery. A lagged copy can also look quiet while Exchange is already planning replay in the background.
That is why the plain checks matter. Database mounted or not. Log count above or below threshold. Lagged copy stable or being pushed forward by space, corruption, or health loss. Those are the signals that tell the real story.
What this lesson makes possible
With this method, a log folder stops being a vague concern and becomes a measured condition. The same idea also explains why a lagged copy may replay logs sooner than expected. The reader now has a clear way to track mounted database logs, understand why replay starts, and see how Exchange makes that decision.
That is the kind of small, direct knowledge Exchange Admin Notes is built to carry forward: practical Exchange Server recovery tips, migration notes, and administration shortcuts for IT professionals.