# OrientDB corruption after manual S3 blob deletion: BufferUnderflowException & OSBTree NullPointerException during CHECK DATABASE

**URL:** <https://community.sonatype.com/t/orientdb-corruption-after-manual-s3-blob-deletion-bufferunderflowexception-osbtree-nullpointerexception-during-check-database/16728>\
**Category:** Best Practices\
**Created:** [October 22, 2026, 1:25pm UTC](https://community.sonatype.com/t/orientdb-corruption-after-manual-s3-blob-deletion-bufferunderflowexception-osbtree-nullpointerexception-during-check-database/16728 "2026-10-22T13:25:48Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![branka.marinkovic](https://avatars.discourse-cdn.com/v4/letter/b/9dc877/32.png) [@branka.marinkovic](https://community.sonatype.com/u/branka.marinkovic)\
**Post date:** [October 22, 2026, 1:25pm UTC](https://community.sonatype.com/t/orientdb-corruption-after-manual-s3-blob-deletion-bufferunderflowexception-osbtree-nullpointerexception-during-check-database/16728/1 "2026-10-22T13:25:48Z")

</div>

Hi everyone,

We are experiencing database corruption on our Nexus Repository 3 instance (OSS 3.61.0-02, OrientDB v2.2.37).

**Root Cause:** Data files and folders were deleted directly from the backend S3 blob store instead of through the Nexus UI. As a result, the metadata in OrientDB became desynchronized and corrupted.

**Observed Errors:**

- **Web UI:** Navigating through folders throws `"A database error occurred"`.

- **OrientDB Record Access:** Running `LOAD RECORD` or `DELETE FROM #...` on corrupted records (such as in `browse_node`) fails with `java.nio.BufferUnderflowException`.

- **Storage Status:** Storage was forced into `read-only` mode due to `OPageIsBrokenException` and `"Magic number verification failed"` errors across page files.

- **DB Check Failure:** Running `CHECK DATABASE` reported 3,214 storage errors and crashed at 35% while checking the `component_bucket_group_name_version_idx` index on cluster `component` with the following stack trace:

Plaintext

```auto
Exception `782A4FFF` in storage `plocal:/data3/db/component/component`: 2.2.37
java.lang.NullPointerException
	at com.orientechnologies.orient.core.index.sbtree.local.OSBTree.findBucket(OSBTree.java:1674)
	at com.orientechnologies.orient.core.index.sbtree.local.OSBTree.get(OSBTree.java:194)
	at com.orientechnologies.orient.core.index.engine.OSBTreeIndexEngine.get(OSBTreeIndexEngine.java:128)
	at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.doGetIndexValue(OAbstractPaginatedStorage.java:2289)
	at com.orientechnologies.orient.core.db.tool.OCheckIndexTool.checkThatRecordIsIndexed(OCheckIndexTool.java:153)
...

```

**Questions / Proposed Solution:** Due to the database size (~1.5TB across ~450 million records), a full JSON export/import would require 20+ hours of downtime and carries a high risk of failure during index recreation.

We are considering stopping Nexus, running `TRUNCATE CLASS browse_node UNSAFE` directly in the OrientDB console, and letting Nexus rebuild the browse tree and Elasticsearch indexes upon restart.

1. Is truncating `browse_node` sufficient?

2. What is the recommended procedure to resolve these broken index pages and clear the `read-only` state without a full database re-import?

Any guidance would be greatly appreciated.

Kind Regards,

Branka