Question about long reindex time and restoring outdated Elasticsearch indexes in SonarQube 9.9.3

SonarQube Server / Community Build
1

Hi everyone! :waving_hand:
I’m facing a question about how SonarQube handles reindexing, and I’d like to confirm whether the scenario below is supported or if it can lead to inconsistencies.

Recently, I had to delete the data/es* folder to force a full reindex, but the process took more than 48 hours and never completed.
Because of this, we started keeping copies of the data/ directory to avoid having to reindex everything from scratch in case something goes wrong.

Here’s my question:
If, for example, the indexes are deleted on December 1st, but I restore an old copy of the data/ folder from August, while the database is fully up to date, will SonarQube be able to automatically complete the missing indexes from the current database data?
Or could this cause errors or inconsistencies (divergent indexes, incorrect data, Elasticsearch failures, etc.)?

Environment

  • SonarQube version: Community 9.9.3 LTS

  • Database: PostgreSQL 12.7 (external instance)

  • Orchestration: GKE (Kubernetes) – GCP

  • Resources:

    • 1 node e2-standard-16 (16 vCPUs, 64 GB RAM)

    • Boot disk 100 GiB pd-balanced (zonal)

    • Regional SSD Persistent Disk 50 GiB (used for SonarQube data directories, including Elasticsearch indexes)

What I’ve observed

  • After deleting data/es*, the reindex process becomes extremely slow (over 48 h without completion).

  • The es.log shows activity, but progress is minimal even with a regional SSD disk.

  • Heap size is correctly configured (~16 GB).

  • Only one SonarQube instance is connected to the database.

Main questions

  1. Can SonarQube detect and automatically fix outdated indexes (for example, from an old data/ backup) and complete them using the current database data?

  2. If not supported, is there a real risk of inconsistency (for example, outdated mappings or references that no longer exist in the DB)?

  3. Are there official best practices to speed up a full reindex (e.g., heap tuning, I/O configuration, hardware recommendations, housekeeping)?

  4. Does reducing data retention (via housekeeping settings) actually help shorten reindex time for large instances?

  5. In case the data/ folder is lost, is the recommended procedure still to completely delete the indexes and let SonarQube rebuild them from scratch using the database?

I can share es.log and ce.log excerpts and I/O statistics if needed.
Thanks in advance to anyone who can confirm the expected behavior or share recommendations to make reindexing more efficient! :folded_hands:

2

Hi,

Welcome to the community!

Only the latest version of SonarQube Community Build is considered active, so you’ll need to update and see if the situation is still replicable before we can help you.

Your update path is:

9.9.3 → 24.12 → 25.10

You may find these resources helpful:

If you have questions about upgrading, feel free to open a new thread for that here.

Regarding your question, what you’re proposing is not supported. If you re-index never finished, then I would look at the resources available to the process. And I believe this will get at least some better for you with the upgrade.

 
HTH,
Ann