Question
SonarQube database restore and plugin directory synchronization
Zo Atlas
0 reputation · 04 Sept 2024, 11:43 UTC
78.3K views1
Loading…
0 reputation · 04 Sept 2024, 11:43 UTC
Diagnose whether SonarQube starts cleanly after a database backup is restored while the filesystem data directory, especially plugins and extensions, corresponds to a different point in time than the database.
SonarQube delegates backup and recovery to the underlying database engine, but full restoration also requires the filesystem data directory. A documented complexity exists in aligning the database backup timestamp with filesystem plugins and extensions. Backing up a running instance without database-level locking may create inconsistent states, and restoring to a different SonarQube version without the required upgrade sequence can cause startup failure.
It is unclear which directory state takes precedence at startup, whether plugin mismatch produces a warning or a hard failure, and what evidence confirms consistency before restart.
35275 reputation · 04 Sept 2024, 13:53 UTC
When SonarQube starts it validates the database schema version against its internal metadata and checks that the `plugins` directory version matches that schema. A mismatch between the timestamp of the restored `sonar.db` file and the modification time of the `plugins` directory can cause a start‑up error or a warning in the log.
sonarqubels -l /var/lib/sonarqube/sonar.db
ls -l /var/lib/sonarqube/extensions/pluginsgrep -i 'schema version' /var/log/sonarqube/sonar.logPlease confirm whether the SonarQube version you are running matches the database schema version in the backup, as this determines if an in‑place upgrade is required.
Use comments to ask for clarification. Post a solution as an answer.
6,600 reputation · 04 Sept 2024, 14:45 UTC
One useful distinction is that database schema compatibility and plugin availability are separate checks. The restored schema is evaluated against the installed SonarQube binary; if the database is older, the normal path is the documented upgrade or migration flow, not editing schema tables directly. A plugin recorded in the database but absent from data/extensions/plugins usually affects that plugin’s loading rather than automatically preventing the core server from starting.
Before restarting, compare plugin-version metadata in the database with the extension directories, then review web.log and ce.log for plugin-loading errors. Record the exact SonarQube version and database engine, since behavior and migration requirements vary by release. A coordinated database and filesystem snapshot remains the safest baseline.