Database Backup, Restore, Disaster Recovery, and Data Protection: Configuration, Design Patterns, and Trade-Offs

1. Recovery design begins with the failure you intend to survive

A database backup protects against some failures, but not every failure. Losing a single SonarQube container is different from losing the database host, a cloud region, the secret store, the deployment repository, or an administrator account. A design that survives “container deleted” may still fail completely during “database and secret store unavailable.”

Define the failure domain first, then decide which independent copies and reconstruction inputs must exist outside it.

2. Logical versus physical database backup

3. Configuration-as-code versus copying installation files

System properties can come from environment variables, Helm values, Secrets/ConfigMaps, command-line options, or sonar.properties. A reproducible recovery prefers a reviewed source-of-truth that can recreate those settings rather than a blind archive of a mutable installation directory.

During an update Sonar recommends a fresh distribution and reviewed settings, not blindly copying old configuration files and plugins. The same mindset improves DR: restore intentional configuration, not accidental filesystem history.

4. Database backup versus search-index copies

Database state and Elasticsearch indexes solve different problems. The database is the recovery authority for SonarQube application state. Search indexes make that state queryable. If the restored database and indexes disagree, the supported answer is to rebuild indexes—not edit the database or Elasticsearch documents until they happen to match.

This is also why RTO includes reindex time. Large instances may be technically restored at the database layer while global issue search is still becoming fully available.

5. Cold, warm, and staged recovery patterns

6. Backup frequency, retention, and recovery objectives

If the RPO is 15 minutes, a nightly dump cannot satisfy it. The database platform may need continuous WAL/log backups or managed point-in-time recovery. If the RTO is one hour, a multi-hour database restore plus multi-hour reindex cannot satisfy it without a different architecture or more capacity.

Track observed durations separately:

backup_start → backup_complete
restore_start → database_restored
sonarqube_start → HTTP operational
reindex_start → search fully available
validation_scan_start → CE SUCCESS
recovery_declared

Use drill measurements, not estimates, to determine whether RPO/RTO commitments are realistic.

7. Backup confidentiality and integrity are security controls

A SonarQube database may contain user identities, issue comments, project metadata, token records, integration settings, and analysis history. A copied recovery database can be sensitive even if source code itself is not stored as a full repository checkout.

• Encrypt backups at rest and in transit according to organizational policy.
• Restrict restore/read permissions independently from routine SonarQube administration.
• Keep integrity hashes or provider-native integrity evidence.
• Define retention and deletion rules; “keep forever” is not automatically safer.
• Use isolated networks for restore drills because restored credentials/identities may still be valid.
• Never include plaintext passwords/tokens in the recovery manifest or CI logs.

8. Restore version and upgrade path are separate decision records

Record the source SonarQube version, edition, Java/runtime, database engine/version, third-party plugins, and deployment configuration at the backup point. For DR, first prove that the backup can reconstruct that known state. If the original release is no longer acceptable for long-term operation, create a second controlled step using the documented update path.

Database-vendor migration is also separate. SonarQube provides a DB Copy Tool for vendor-to-vendor migration with SonarQube-specific checks; a disaster-recovery backup is not the place to improvise an Oracle→PostgreSQL conversion.

Recovery acceptance also needs fresh analysis provenance: preserve the validation report-task.txt and its ceTaskId so the restored server’s Compute Engine result can be tied to the exact post-restore source revision rather than inferred from a green UI.

9. Edition and deployment boundaries

10. Worked decision table

Knowledge check

Official references and version notes

• SonarQube Community Build — Backup and restore — use the database vendor's backup tooling; hot database backups are supported; restore the database and rebuild Elasticsearch indexes.
• SonarQube Community Build — Reindexing — startup after restore rebuilds Elasticsearch indexes; project availability and background reindex behavior are documented.
• SonarQube Community Build — Installing database — current supported database engines and versions; PostgreSQL 14–18 is supported starting with Community Build 26.2.
• Configuration methods — startup/system properties can live in environment variables, command line, Helm configuration, or sonar.properties, and are not all database state.
• Performing an update — use a fresh distribution/config review and install compatible third-party plugins rather than blindly copying an old installation.
• Sensitive settings — secret-key material and encrypted configuration require separate protected handling.
• PostgreSQL — pg_dump — produces a consistent logical backup while the database can remain in use.
• PostgreSQL — pg_restore — restores non-plain-text archives created by pg_dump.
• Official SonarQube Docker tags — exact Community Build image identity used in the lab.
• Official PostgreSQL Docker tags — exact PostgreSQL image identity used in the lab.