Exchange log-chain recovery

An Exchange database and its transaction-log chain must agree on where recovery should begin.

Exchange writes mailbox changes to transaction logs before committing them to the EDB. After an outage, failed copy, storage loss, or partial restore, the database may require a specific continuous log sequence to reach a clean shutdown state.

Start a recovery case Call 682-325-7712

Understand the symptom

Log signatures and generations bind a database to its recovery history.

WHY

What is happening

The EDB header records database state and log requirements. Logs carry signatures and ordered generations; the checkpoint marks replay progress. Recovery identifies the correct chain, validates continuity and signatures, and separates soft recovery from last-resort extraction or repair paths.

What you may see

Symptoms that change the recovery path.

Database is in dirty shutdown

The EDB header indicates that required log replay did not complete.

Required log file is missing

Mount or recovery reports a generation gap.

Log signature mismatch

Logs came from another database, restore set, or generation history.

Passive copy and active copy differ

Replication may provide alternate logs or pages at different states.

Protect the source

Actions that can make the situation worse.

Log deletion removes committed changes

Unreplayed logs may contain the newest mailbox transactions.

Hard repair can discard pages or records

Structural repair prioritizes mountability and may remove damaged data.

Mixing chains creates false continuity

Renaming unrelated logs does not make them valid for the EDB signature.

Do this now

Safe steps before evaluation.

Dismount and stop write activity

Prevent mount loops, reseed, backup truncation, and application access.

Copy the whole database set

Keep EDB, every log, checkpoint, catalog, copies, backups, and volume snapshots.

Record header and error output

Save Exchange events, database state, required generation range, signatures, and timestamps.

Preserve alternate copies

Do not reseed or delete a passive copy that may contain usable pages or logs.

NEPFOSYS process

How a data-first evaluation proceeds.

Chain inventory

NEPFOSYS maps EDB state, signatures, required generations, checkpoints, and database copies.

Protected replay testing

Soft-recovery candidates are validated on copies without truncating the source logs.

Mailbox-data verification

Recovered stores or extracted content are checked against requested mailboxes and time ranges.

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.

Can I delete transaction logs to make Exchange mount?

No. Missing unreplayed logs can represent committed changes and may be required for consistency.

What does dirty shutdown mean?

The database needs transaction-log replay or another recovery path before it can be mounted consistently.

Should I run Eseutil /p?

Only as a documented last resort on a copy after softer paths and backups are exhausted, because hard repair can discard data.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case