I did the following:
Curious if perhaps after you made the changes to the dbconfig.xml if you then restarted Jira. If you did NOT, then that would explain this behavior. Changes to that file have to be saved and Jira has to be restarted for those changes to take effect. If you did not restart jira, then the import actually went into the H2 database, and not the expected MySQL database. But to confirm that, I'd want to look closer at the $JIRAHOME/log/atlassian-jira.log file, particularly at the time of this import/restore.
When you are restoring data in Jira using the XML backup, I typically don't recommend using the method in the system administrator menus. Instead, I have found it is better to setup an empty database (since this process is going to overwrite any data anyway in the database Jira is connected to) and the use the setup wizard in Jira and select the option to 'import existing data'. This works in much the same way, but the major difference here is that this method can still perform Jira upgrade tasks (whereas restoring an xml backup in the system admin menu after Jira is setup cannot). That doesn't matter if you're importing a backup from the exact same Jira version, but is essential if your backup comes from an older version of Jira.
Even if my hunch here is incorrect, looking at the log files when Jira was restoring this data would probably be were I would start if you did indeed restart Jira after changing the dbconfig.xml file.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.