Exchange lost-flush recovery

An Exchange lost flush means storage acknowledged a page write that was not durably recorded where the database expected it.

Exchange ESE tracks page state to detect stale or misdirected writes. In a Database Availability Group, page patching may replace a bad page from a healthy replica, but a single-copy database or damaged replicas require careful comparison before hard repair.

Understand the symptom

Lost-flush detection protects transaction order beyond a simple page checksum.

WHY

What is happening

A page can contain structurally valid data yet be older than the state Exchange expects. Recovery correlates page history, log generations, database-copy health and storage events, then prefers a verified replica or restore path before any lossy page removal.

What you may see

Symptoms that change the recovery path.

01

Lost-flush event is logged

ESE detects a page generation that does not match the expected write history.

02

Page patch request fails

No healthy replica supplies the required current page.

03

Database copy becomes failed

Log replay or database scanning finds inconsistent page state.

04

Storage events appear near the incident

Controller resets, cache faults or path errors coincide with database damage.

Protect the source

Actions that can make the situation worse.

01

Reseeding can overwrite the best copy

A healthier passive database may be replaced before comparison.

02

Hard repair can discard content

Eseutil /p restores structure by removing unrecoverable records or pages.

03

Ignoring storage repeats the fault

Database repair cannot correct an unreliable controller, cache, fabric or disk path.

Do this now

Safe steps before evaluation.

01

Freeze copy changes

Pause automatic reseed, repair and maintenance where operationally safe.

02

Collect DAG and ESE evidence

Save copy status, event IDs, page references, logs, checkpoints and replication health.

03

Preserve every database copy

Keep EDB files, all logs, backups and configuration before choosing a source.

04

Protect the storage layer

Snapshot or image affected volumes and retain controller, SAN and Windows events.

NEPFOSYS process

How a data-first evaluation proceeds.

01

Copy comparison

NEPFOSYS maps page state, log continuity and health across available databases and backups.

02

Protected recovery testing

Page-level, restore and extraction paths are tested without changing the best copy.

03

Mailbox validation

Priority mailboxes, folders, messages and attachments are checked in the recovered output.

A clear next step

Preserve the original device before another repair or recovery attempt.

Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.

Start with a case review

Questions, answered

What customers ask before starting.

What is a lost flush?

It is a write reported as completed by storage that was not durably written, or was written to the wrong location.

Can Exchange page patching fix it?

A healthy replica may supply a replacement page, but copy and log health must first be verified.

Does this prove the EDB is the only problem?

No. Lost flushes often require investigation of the entire storage path and its write guarantees.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case