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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.