Backup and restore of sonarqube database/metadata

We have Sonarqube 7.1 Developer edition that was installed manually on a server using PostgresSQL 11 a while back.We now need to migrate it to a new setup and have a few questions,

  1. We need to rehearse the migration a few times to ensure it works and iron out any issues as we are not allowed access to the dbcopy tool under current developer licence. If we backup the source database from one server and restore it to another does this mean the licence will be running in 2 locations at once and will this cause any issues? If there are licence issues what options do we have, can we use a temporarily licence on the destination server until such time as we really intend to cutover?

  2. Is a postgres database backup via “pg_dumpall > filename.sql” and restore via “psql <DATABASE_NAME> -f filename.sql” sufficient or are other steps required?

  3. The documentation only covers backup and restore of the database, what about backup and restore of the metadata on disk eg: config/plugins/etc, is there detailed documentation on what needs to be backed up and restored and any caveats around it?



Hi Matt,

  1. Not being licensed will only prevent you from running fresh analysis. If all you’re looking to do is bring SonarQube up in the new location and verify it runs, this should be possible without a new license. Then request the new license once you think your situation has settled and your configuration (specifically the database location) won’t be changing.
  2. We don’t require or advocate for any particular database backup strategy, as long as transactional integrity is maintained.
  3. You’ll certainly want to backup and either restore or recreate the configurations you’ve specified in your file. Custom or 3rd party plugins you’ve installed will also need to be restored if you still want to run them. I.e. you should know if you added something there that needs to be preserved.

SonarQube 7.1 is quite old and no longer supported. I’d strongly encourage you to plan as part of this move to install our LTS version 7.9.4. Follow the upgrade guide if you’re interested. This could also simplify your backup/restore process. Rather than worrying about restoring any SonarQube files, simply install SonarQube 7.9 Developer Edition, copy your file into the conf directory, adjust the database properties (sonar.jdbc.*) to match your restored database location, and the database contents will be upgraded at first startup. I’d certainly recommend you keep a copy of your database backup should you choose to go this route.


Thanks for the quick response.

  1. I take it the licence or activation details are stored in the database and my understanding is that its tied to a unique ID of the system? If we take a backup from source and restore to destination (both copies running at same time) will this cause any issues with source as that is a live system currently and we dont want to affect its use until we are ready to migrate.

  2. We are using postgress 11 for both source/destination, and the limited tests I have performed so far after a restore show the process we are using appears to work, however are there any health/error log database tables/files on disk we can refer to after a restore to confirm if it was successful from the sonarqube apps perspective and what specifically should we be looking for? there is the sonarqube web server startup log we see is that sufficient to determine app health if it contains no errors?

  3. in terms of restoration we didn’t build the source server and it was done a while back so we arent 100% sure what has been added, currently we are backing up and restoring the following folders and their contents, the only ones we are excluding are the elasticsearch indices and logs, are there any others that can be safely excluded and are we missing any from that list?



logs/ <- excluded this and all subfolders

data/es6 <- excluded this and all subfolders

Sorry mistake in original post we are actually using sonarqube:8.4.1-developer container at source and destination

Yes, the license is stored in the database and is tied to system identity. Running another instance will not in any way affect the source system; it will just prevent the destination system which is now improperly using the “old” license from being allowed to run fresh analysis.

Looking through the logs/ directory for any obvious signs of error is what I’d recommend.

As I mentioned before, you really just need to focus on conf/ (the file) and any non-standard plugins you’ve added, which would be found in extensions/plugins/. If you want to prove to yourself whether you’ve got any non-standard plugins, you can compare with the contents of that folder from a fresh 8.4.1 installation.

1 Like