Random database corruption - invalid or nonexistent document

HCL Domino Domino Forum
1

Domino/Notes Version: 14.5.1
Operating System: Windows Server 2022
Client (Notes, Nomad Web, Nomad Mobile, Android/iOS, browser version): ALl

Problem/Query:

I’ve been having issues with random database corruption since about Domino V14.

When it happens, I see repeated messages like this in the console:

08/06/2026 23:08:02 Performing consistency check on kb\xxx.nsf…
08/06/2026 23:08:03 Completed consistency check on kb\xxx.nsf
08/06/2026 23:08:03 Recovery Manager: Assigning new DBIID for c:\notes\Data\kb\xxx.nsf (need new backup for media recovery).
08/06/2026 23:08:03 Performing consistency check on kb\xxx.nsf…
08/06/2026 23:08:04 Completed consistency check on kb\xxx.nsf
08/06/2026 23:08:04 Recovery Manager: Assigning new DBIID for c:\notes\Data\kb\xxx.nsf (need new backup for media recovery).

I then bring down the server and run fixup/compact:

load fixup -J -D kb\xxx.nsf
08/06/2026 23:11:04 Database Fixup: Started: -J -D kb\xxx
08/06/2026 23:11:04 Performing consistency check on kb\xxx.nsf…

08/06/2026 23:11:06 Completed consistency check on kb\xxx.nsf

08/06/2026 23:11:06 Recovery Manager: Assigning new DBIID for c:\notes\Data\kb\xxx.nsf (need new backup for media recovery).
08/06/2026 23:11:06 Database Fixup: Unable to fixup database c:\notes\Data\kb\xxx.nsf: Invalid or nonexistent document
08/06/2026 23:11:06 Database Fixup: Shutdown

load compact -c kb\xxx
08/06/2026 23:11:14 Performing consistency check on kb\xxx.nsf…

08/06/2026 23:11:15 Completed consistency check on kb\xxx.nsf

08/06/2026 23:11:15 Recovery Manager: Assigning new DBIID for c:\notes\Data\kb\xxx.nsf (need new backup for media recovery).
08/06/2026 23:11:18 Database compactor error: Invalid or nonexistent document

Given that I can’t recover the database, I end up deleting it and then replicating from another cluster member, which can be time consuming.

It’s mainly happening to my most heavily-used databases, and is very infrequent, perhaps once a month, although I’ve had two databases go corrupt on me this month hence the question.

Has anybody else experienced this?

2

Hi @tyrex1975 ,

Good day!

Regarding to your concern, the possible causes of these sporadic database corruptions generally can be one of the following:

  1. Corrupted View Indexes
    Often, the database file itself isn’t structurally damaged rather, the view index has become corrupted.

  2. Faulty or Interrupted Agents / Code
    If this happens in a specific application, custom background LotusScript or Java agents are a prime suspect.

  3. Antivirus and OS-Level Interference
    Third-party security software, backup agents, or endpoint protection scanning the Domino data directory while the server is live.

  4. Database Corruption / Damaged RRV Bucket
    The Record Relocation Vector (RRV) bucket maps Note ID to their physical positions in the .nsf file.

  5. DAOS or Transaction Logging Mismatches
    An outdated DAOS ticket, a missing .NLO file, or an uncommitted transaction log tail after a dirty server shutdown can leave reference stubs pointing to a vacuum.

How to Troubleshoot and Fix It

When encounter a database corruption, the usual course of action is to perform offline maintenance on the affected database to address the issue. Aside from running fixup and compact you need to run the updall to rebuild the views. You may check the article below on running database offline maintenance.

In the event that you are (still) having an issue, you can create a case to HCL Domino Support Portal for a deep dive investigation.

Hope the above information helps. Thank you.

3

The cause of the corruption in my experience is usually something interfering with Domino I/O activity, Anti Virus, lack of disk space (check all drives), have even had a failing drive.. I would check these kind of things as this keeps happening.

To allow the compact to complete have you tried -i

Copy-style: Ignore errors and proceed; Enables compacting to continue even if it encounters errors such as document corruption. Only used for copy-style compacting.

Bri.

4

Interesting, I’d not noticed the -i option, will give that a go next time corruption occurs. Thank you.

I suspected I/O too, but hard to imagine it’s a disk issue because it’s happening on multiple cluster members and all disks are RAID-1 which tends to isolate physical issues from Domino.

Anyway, it just seems odd that a database would suddenly go awry and literally no Domino maintenance process will touch it.

In any case, I’ve raised a support case with HCL, will report back here if we find the cause.