Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

License Error Event ID 9518

Event ID 9518 with error -1808: the log volume filled and the store dismounted

10 min read Updated October 4, 2026 Exchange Server

Fix it now

The store could not start the database and the error carried with the event names the reason. Microsoft publishes -1808 as JET_errDiskFull, there is no space left on disk. Free space safely, restore log truncation, then mount; do not delete transaction logs to make room.

Run these in the Exchange Management Shell, in order

Get-MailboxDatabase -Status | Format-List Name,Mounted,LastFullBackup,LastIncrementalBackup
Get-MailboxDatabaseCopyStatus * | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength
Mount-Database DB01
  1. Look at the log volume first, not the database volume. Log growth is what fills a disk suddenly.
  2. Free only what is safe to free: unrelated data on the volume, expired diagnostic and protocol logs under the Exchange logging directories, IIS logs, and the Windows temp directory.
  3. Run a full Exchange-aware backup of the affected database. A successful full backup is what truncates the logs, and it is the supported way to reclaim the space.
  4. Read the error code carried in the event before assuming it is disk space. -1808 is a full disk; -529 JET_errLogDiskFull names the log disk specifically; 0xfffffddc is a different condition entirely and is covered below.

Moving the logs is a valid emergency measure, but Move-DatabasePath cannot be run against a replicated database and it dismounts and remounts a mounted one. Neither is a surprise you want at 2am.

If the database mounts and the logs truncate after the next backup, you are done. If the space comes back and fills again, the next section explains why truncation stopped.

Why it happens

Every change to a mailbox database is written to a transaction log first and into the database file later. Those generations sit on disk until something tells the engine they are safe to discard. In a standalone deployment that something is a successful Exchange-aware full or incremental backup. In a database availability group it can also be replay on every copy, where continuous replication circular logging is enabled. If neither happens, logs accumulate at exactly the rate your users generate mail until the volume is full.

So the real fault is almost never Exchange. It is the backup: failing quietly, running through a file-level agent that is not Exchange-aware, or excluding the database it was supposed to protect. In a DAG there is a second common answer, which is a copy that is failed or suspended. Logs cannot be truncated while a copy still needs them, so one broken passive copy can fill the log volume on the active server.

One code in this family is worth reading carefully rather than glancing at. 0xfffffddc is the unsigned form of -548, which Microsoft publishes as JET_errLogSequenceEndDatabasesConsistent: the databases have been recovered, but all possible log generations in the current sequence have been used, and all log files and the checkpoint file must be deleted and the databases backed up before continuing. That is not a full disk. It is the log generation sequence running out, and its remedy is specific and different.

Backups have stopped succeeding

You have this one if The last successful full backup is old, or the backup job reports success while never touching Exchange.

  1. Check when Exchange last recorded a backup: Get-MailboxDatabase -Status | Format-List Name,LastFullBackup,LastIncrementalBackup.
  2. If those fields are empty or stale, the backup product is not talking to Exchange, whatever its own console says. A file-level copy of the files truncates nothing.
  3. Run a full backup with a product that uses the supported Exchange shadow copy writer, and confirm the logs truncate afterwards.
  4. Alert on the age of the last successful backup recorded on the database, not on whether the backup job reported success.

A database copy is failed or suspended, so truncation is blocked

You have this one if The active copy is healthy but log files build up, and a copy is not healthy.

  1. Check every copy: Get-MailboxDatabaseCopyStatus DB01 | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength.
  2. Resume a suspended copy with Resume-MailboxDatabaseCopy, and reseed a failed one once you know why it failed.
  3. If a member is down for a long rebuild, consider removing its copy rather than letting it pin logs on every other server.
  4. Lagged copies hold logs deliberately. Confirm the lag setting matches the space you provisioned.

The log generation sequence has been exhausted

You have this one if The error carried with the event is 0xfffffddc, and the volume is not actually full.

  1. Read Microsoft’s description before acting: the databases have been recovered, but all possible log generations in the current sequence have been used.
  2. The published remedy is to delete all log files and the checkpoint file, and to back the databases up before continuing. Take a copy of everything first and confirm the databases really are in a clean state.
  3. Treat this as a planned maintenance operation, not a quick fix during an outage call.

This is a genuinely different failure from a full disk and it is easy to miss, because both leave you with a dismounted database and a log folder that looks alarming.

The volume was never sized for the workload

You have this one if Backups succeed and copies are healthy, but a busy day still fills the disk.

  1. Size the log volume for the largest realistic gap between successful backups, not the average day.
  2. Put the logs on their own volume so their growth can never fill the one holding the database.
  3. Enable circular logging only where you accept the trade: it caps growth by discarding logs, and your ability to recover to a point between backups goes with them.

Full reference

The codes that turn up in this event

Code Symbolic name Microsoft’s description
-1808 JET_errDiskFull There is no space left on disk
-529 JET_errLogDiskFull The log disk is full
-548 (0xfffffddc) JET_errLogSequenceEndDatabasesConsistent The databases have been recovered, but all possible log generations in the current sequence have been used. All log files and the checkpoint file must be deleted and databases must be backed up before continuing
-519 JET_errLogSequenceEnd The maximum log file number has been exceeded

Negative engine codes are often printed in unsigned hexadecimal. Subtract the hex value from 0x100000000 to get the decimal error: 0xfffffddc is 548, so the code is -548. That arithmetic is the difference between chasing free space and running the documented log sequence remedy.

Never delete transaction logs to free space, however desperate the situation looks. They are the only route back to a consistent database after a crash, and the database that will not mount today becomes the database that cannot be recovered at all tomorrow.

What is safe to remove, and what is not

Safe to remove past its retention period Never remove by hand
Protocol and connectivity logs under the transport logging tree Mailbox database transaction logs
Diagnostic logs under the Exchange logging folder The checkpoint file, while the database is in use
IIS logs on the same volume The database file itself
Windows temp files and old installers The transport queue database and its logs

The event itself

Microsoft does not publish a description for the store event in this article’s title, nor for the two engine events that often accompany it. That is not a reason to ignore them: each entry names a database or an instance and carries an error code, and it is those fields that matter. Read the code, convert it if it is in hexadecimal, and look it up in Microsoft’s error list rather than treating the event number as the diagnosis.

Getting the space back in the right order

  1. Take stock before deleting anything. Establish which volume is full and what is on it.
  2. Remove only files that are genuinely disposable, and record what you removed.
  3. Mount the database if it will now mount, so users are back while you deal with the cause.
  4. Run a full Exchange-aware backup and confirm the logs truncate as a result.
  5. Fix the copy health or the backup schedule that let it happen, and set an alert on the age of the last successful backup as well as on free space.

When a licence is the actual fix

There is nothing to buy to fix a full disk, and the backup that truncates your logs may well already be installed. The purchase case is narrower and worth naming honestly: a mailbox server on a Windows Server version that no longer receives updates is a platform you cannot properly support, and the shadow copy writers that Exchange-aware backups depend on live in that platform. Arco supplies Windows Server 2025 Standard licences and can check your core count and CAL position. Two cautions before you spend anything. Confirm your Exchange build is supported on the Windows version you are moving to, and note that Exchange Server 2016 and 2019 went out of support on 14 October 2025, so the Exchange side of the platform may be the more urgent half of the conversation. If your Windows Server is licensed and current, nothing here needs buying.

Every code this article covers

Code What it points at Source
Event ID 9518 No description is published by Microsoft. The store reporting that it could not start a database; the error code carried in your own entry names the actual reason not published by the vendor
-1808 JET_errDiskFull: there is no space left on disk Microsoft Learn
Event ID 623 No description is published by Microsoft. Read what your own entry names and correlate it with any long-running operation on the database not published by the vendor
Event ID 533 No description is published by Microsoft. Match it by instance name and timestamp and read the description in your own entry not published by the vendor
0xfffffddc The unsigned form of -548, JET_errLogSequenceEndDatabasesConsistent: the databases have been recovered but every log generation in the current sequence has been used, so all log files and the checkpoint file must be deleted and the databases backed up before continuing Microsoft Learn

Confirm the fix worked

  1. The volume has free space and log files are removed after each successful backup.
  2. Get-MailboxDatabase -Status | Format-List Name,Mounted,LastFullBackup shows the database mounted with a recent backup date.
  3. Every copy of the database is healthy, so truncation is not blocked again.
  4. An alert exists on free space on the log volume and on the age of the last successful backup, not just on job completion.

Questions people ask about this

Do I need to buy anything to get the database mounted?

No. Free space and a working Exchange-aware backup will do it. The cost, if there is one, is storage rather than software.

The error is 0xfffffddc, not -1808. Is that the same thing?

No, and it matters. 0xfffffddc is -548, which Microsoft publishes as the log generation sequence having been fully used. The documented remedy is to delete all log files and the checkpoint file once the databases are recovered, then back them up. Do not treat it as a full disk.

Can I turn on circular logging just for today?

You can, and it will stop the growth, but it discards logs as it goes and you lose the ability to recover to any point between backups while it is on. Treat it as a deliberate trade and turn it back off with a full backup immediately afterwards.

Why did the logs not truncate when the backup ran?

Either the backup was not Exchange-aware, or it covered only some databases, or a copy still needs the logs. Check LastFullBackup on the database itself rather than the backup console.

How much headroom should the log volume have?

Enough to survive the longest plausible gap between successful backups at your busiest rate, plus what a migration would add. Sizing for the average day is what produces this outage.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix 0x80090327 and 0x800B0109: Exchange TLS fails on certificate validation License Error MapiExceptionTooManyMountedDatabases: Standard Edition hits its database cap License Error Error 1642: an Exchange security update refuses to patch this build Free Fix Error -550 dirty shutdown: Exchange will not mount a database missing its logs
← Back to Knowledge Base