What is an EDB File And Why It is Only Half a Database
Dirty shutdown reads like an error and is not one. Every database currently serving mail is in that state, which is why the header tells you so little.
An EDB is half a database. The other half sits in a set of transaction log files. A copy of the EDB taken without them may be missing work that Exchange considered finished. Almost every difficulty with these files traces back to that split rather than to anything being broken.
Nobody encounters one by choice. An EDB turns up when a server is decommissioned, when a storage event goes badly or when somebody in legal asks for mail from an account that closed three years ago. Every one of those situations is a recovery job. The first useful question is not how to open the file but what came with it. Mail formats mostly hold what belongs to one person. An EDB holds whole departments, which puts it at the far end of the range of mail formats.
An EDB Is One Mailbox Database Rather Than a Server
Exchange groups accounts into mailbox databases. Every one of those becomes a file with an EDB extension. Servers rarely run just one. Accounts get spread across several, chosen when the mailbox was created and rarely thought about again.
That distinction matters the moment somebody hands over a file and calls it the mail server. It holds many mailboxes. It does not hold every mailbox. The ones it does hold were whichever accounts happened to be assigned to that database.
Ask what else was on the server. If four databases were running and you were given one file, three quarters of the mail is somewhere else. Ask about a Database Availability Group too, since a DAG keeps passive copies on other servers and the file in front of you may not be the only one left. Both questions are far easier to answer while the server still exists.
What people picture
One file, one servermail server
└ database.edb
└ every mailboxThe file gets handed over as though it were the whole thing. Nobody questions that until a mailbox turns out to be missing.
What is actually there
Several files, one servermail server
└ DB01.edb sales, support
└ DB02.edb finance
└ DB03.edb engineering
└ DB04.edb executivesAccounts were assigned to a database when each mailbox was created. Nothing about that choice is visible from a single file.
The File Is Only Half the Database
Underneath Exchange sits the Extensible Storage Engine, still called JET Blue by people who met it in the nineties. It is the same engine that runs Active Directory. The service that owns the database and decides when work moves out of cache is the Information Store. It stores everything in B+Tree structures across fixed size pages, in the same family of design a PST uses on a smaller scale. It is also a transactional store, which means it does not write changes straight into the database file.
A change is written to a log first and only later flushed into the EDB. A checkpoint file tracks how far that flushing has got. Those three things together are the database. Any one of them alone is an incomplete picture.
-
database.edbThe storePages holding mailboxes, folders and messages, updated whenever work is flushed out of the logs -
E00.logThe write ahead logsEvery committed change lands here first. The open log carries no sequence number until it fills and closes. Numbering is hexadecimal
E0000000001.log -
E00.chkThe checkpointRecords how far through the log stream the flushing has reached. Losing it slows recovery rather than stopping it, since the engine can scan the whole log set instead
Ask whether circular logging was on. With it enabled, Exchange reuses a small set of logs and overwrites the old ones as it goes. That keeps the log drive small and it means nothing before the last backup can be replayed. Administrators turn it on to stop logs filling a disk. It quietly removes most of the recovery options described here.
What Clean And Dirty Shutdown Actually Mean
Two states matter. One of them is widely misunderstood.
Clean Shutdown
Dirty Shutdown
Exchange reaches clean shutdown when a database is dismounted properly and everything in cache is written out. A crash, a power cut or a flat file copy taken from a running server all leave dirty shutdown behind instead.
A restored backup is normally dirty too. Restoring the database file on its own does not replay the logs, so the expected result is a dirty shutdown rather than a sign the backup failed. The replay is a separate step and it needs the logs to have been restored as well.
Size Limits And the White Space Problem
Two numbers decide whether a database will mount at all. Neither of them is about corruption.
| Edition | Enforced limit |
|---|---|
| Standard Edition, 2013 onward | 1,024 GB by default, adjustable through the registry |
| Enterprise Edition | None enforced |
| Microsoft recommendation | Two terabytes, well below what the engine allows |
| Engine ceiling | Sixteen terabytes, from a thirty two kilobyte page size |
A database that has grown past the enforced limit will not mount. The message says nothing about size. Anybody chasing a mount failure without checking this first can spend a day on the wrong problem.
White space is why the file never gets smaller. Move a mailbox to another database and the EDB stays exactly the size it was. The space it occupied becomes white space, available for whatever arrives next. Reclaiming it on disk needs an offline defragmentation, which rewrites the database into a fresh file and needs room for both at once.
Why Repair Is the Last Option Rather Than the First
Two recovery paths exist and they are not interchangeable.
| Path | Command | What it does | What it costs |
|---|---|---|---|
| Check the state | eseutil /mh | Reads the header and reports clean or dirty | Nothing. It only reads |
| Soft recovery | eseutil /r | Replays the logs into the database | Nothing, when the required logs are present |
| Hard repair | eseutil /p | Discards whatever cannot be reconciled | Whole mailboxes. Sometimes just the newest mail in the survivors |
| Reclaim space | eseutil /d | Rewrites the database without its white space | Downtime, plus room for a second copy |
Soft recovery is what the design intends. It finishes the work the logs describe and brings the database to a consistent state without losing anything, provided the log sequence is complete.
Hard repair reaches a mountable database by throwing away the parts it cannot make sense of. It frequently succeeds in the narrow sense that the database mounts afterwards, while mailboxes that were there before are not.
Check the disk before starting either one. Both need working space of roughly one hundred and ten percent of the database size while they run. A repair that runs out of room part way through leaves you worse off than when it began.
Work on a copy, always. Both operations modify the database they are pointed at. Anyone running a repair against the only surviving copy has removed the option of trying something gentler later. What a hard repair discards is not coming back.
What Happened to the STM File
An EDB inherited from an older server may have arrived alone when it should not have.
Databases of that generation came in two files rather than one. They also carried names most administrators of the period could recite. A default install left priv1.edb for mailboxes and pub1.edb for public folders. Structure and MAPI content sat in the EDB while anything that arrived in its native internet form sat in a separate STM. Neither file was complete alone. The split was dropped in later versions.
Check the era before assuming the file is complete. Arriving without the STM means content is already absent before any recovery work starts. No amount of repair produces what the file never contained, which is worth establishing early rather than discovering after a week of effort.
Read next What is an OST File And Why It Cannot Simply Be Copied The cached slice of this database that ends up on a laptop.Why Reaching One Mailbox Inside It Is Hard
The usual request is small. Somebody wants the mail of one person who left, out of a database holding hundreds of accounts.
The supported route is to bring the whole database back to a consistent state, mount it on a working Exchange server and export from there with New-MailboxExportRequest in PowerShell. That means a server, a matching version, a licence and enough disk space for the whole database rather than the one mailbox anybody wanted.
The alternative is software that reads the file format directly and pulls a mailbox out without mounting anything. That skips the server entirely, at the cost of working with a rebuilt view of the data rather than a live store.
Mount the database
The supported routebring to clean shutdown
find a matching Exchange
provision a licence
restore the whole database
mount it
export one mailboxSix steps and a server, to reach the one account somebody asked about.
Read the file directly
The parsing routeopen the EDB
locate the mailbox
extract itNo Exchange and no mounting. What comes out is reconstructed from the file rather than served by a live store.
What to Do With an EDB You Have Been Handed
- Find out what came with it. Either the logs and checkpoint are present or the EDB arrived by itself. Everything realistically recoverable follows from that answer. It is also the question least likely to get asked while the server is still standing.
- Copy before touching anything. Recovery operations rewrite the file. Whatever you try first, try it on a copy and keep the original untouched.
- Establish the state before choosing a path. The header reports clean or dirty. Dirty on its own is not bad news. What matters is whether the logs needed to resolve it are present.
- Treat hard repair as the end of the road. It is the option you take when soft recovery is impossible, knowing that what it discards is not coming back.
Where the goal is reading what is actually inside rather than restoring a server, our EDB tools parse the file directly and pull mailboxes out without needing Exchange at all. Getting those mailboxes into something another program will open, whether that is PST for Outlook or individual messages for a review platform, is what the mail converters handle.
Engine behaviour and shutdown states checked against Microsoft documentation and against published recovery practice in August 2026.
Questions People Ask
7 questions, answered in full below.Can I open an EDB file on its own?
Often not. The reason is rarely damage. An EDB is one half of a transactional database, with the other half in the log files, so a copy taken without them may be missing work that was committed but never written to the file. Software that reads an EDB directly can still extract from one, which is a different job from mounting it.
What does dirty shutdown actually mean?
That the database has committed transactions sitting in logs that have not been flushed into the file yet. It is the ordinary state of a database that is running, not a symptom of corruption. It only becomes a problem when the logs needed to finish the job are missing.
Is one EDB the whole Exchange server?
No. One EDB is one mailbox database out of the several a server keeps. Whoever hands you the file may well believe it is the whole server. That difference is worth settling before anybody promises a mailbox that was never in it.
Why does eseutil /p have such a bad reputation?
Because it makes the database mountable by discarding whatever it cannot reconcile. That often works. The cost can be entire mailboxes or the most recent mail in the ones that survive. It is the last option rather than the first. It should never be the first thing tried on the only copy.
What is the STM file that sits beside an EDB?
A second file that older Exchange versions used to hold native internet content, while the EDB held everything else. Neither was complete on its own. Turning up with one and not the other means content is already absent. Later versions of Exchange stopped splitting databases this way.
Why does an EDB not shrink when mailboxes are removed?
Because the space freed becomes reusable inside the file rather than returning to the disk. Removing a mailbox marks its pages available for the next thing that needs them. Reclaiming the space on disk takes an offline defragmentation, which rewrites the database and needs room for a second copy while it runs.
Does an EDB still exist with Exchange Online?
Not one you will ever hold. Microsoft runs the databases and you get access through the service rather than to the file. The EDB files people are handed today almost all come from an on premises server that has been decommissioned.
Sources
Where the figures and behaviour described above were checked.
- Exchange Server Data Recovery, EDB, logs and eseutil Gillware Data Recovery
- Exchange Server Database Corruption and Dirty Shutdown Scenarios Practical 365
- How to recover an Exchange database from the Dirty Shutdown state Dell Support
- Manage mailbox databases in Exchange Server Microsoft Learn