SonarQube database restore and plugin directory synchronization
0 reputation · 04 Sept 2024, 11:43 UTC
Goal
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.
Constraints
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.
Uncertainty
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.
- Does SonarQube validate plugin and extension compatibility against the restored database schema during startup?
- Which log entries indicate a timestamp mismatch between the restored database and the filesystem data directory?
- Is a coordinated filesystem snapshot required alongside the database dump to avoid inconsistent plugin state?
