Please don't use the HSQL database that comes included with Jira Server. It's prone to data loss, it's not supported by Atlassian, and it has other potential issues with data integrity. It's really only good for evaluations. I would not recommend ever migrating Jira Cloud data directly to a Jira site using the HSQL database on the backend. From reading your description of your currently problem, I can't help but think that it is very likely your Cloud to Server restore did not complete to 100%. In turn this could cause the latest error you are seeing now of "No 'key' field for Issue 22354" as well as explain why you can't login to Jira after the restore. You should be able to login to with the username/password of sysadmin/sysadmin for any Cloud backup restored to Jira Server.
Basically I think that your first restore is actually failing somewhere and the subsequent backup created from this Jira Server site is corrupted fragments of your Cloud backup data. To confirm or deny this theory, go into the $JIRAHOME/log/atlassian-jira.log file and look for the log entries that show the initial import of that Cloud backup. You can search for these by searching for strings like '1%', '2%', etc. When importing data like this, you should have 100 entries in the log for all the values between 1% and 100%. If your restore did not make it to 100% before generating an error or Jira restarting, your restore did not import all your Cloud data.
It's better to use a supported database from the supported platforms page. I would recommend completing this step once more for restoring the Cloud backup to a fresh Jira Server install. I would also suggest selecting a postgres database, but the choice is yours.
The next fun fact, is that MySQL does not support 4-byte characters, which you appear to have found out already. This is a well known limitation that is documented in the supported platforms page, and in the Connecting jira to mysql database guide.
All Jira Cloud backups come from Postgresql databases that don't have this particular problem. One way to avoid this is to use another database on the backend of Jira such as postgresql or Microsoft SQL. If you're still set on using MySQL, check out workarounds on https://jira.atlassian.com/browse/JRASERVER-36135 There are other users that have tried out using the utf8mb4 character set when creating the MySQL database for Jira. While this is not official supported by Atlassian yet in Jira, it does appear to offer a way to let MySQL store those characters.
Otherwise if you're going to be importing data that came from a postgres instance into a database using MySQL, you are going to have to run that utility to strip out these 4 byte characters. I have had success in the past using that utility. For me it has never generated the error you have now.
So in my opinion, this first Server backup taken really is corrupted from that first restore, and the invalid characters are being removed correctly by the script, you just have missing entries because the first restore only partially completed.
Sorry this post turned into a book. Let me know if you have any questions/concerns about next steps to try here.
![Antoine [Klee Group]](https://avatar-management--avatars.us-west-2.prod.public.atl-paas.net/initials/AL-1.png "Antoine [Klee Group]"){kind=avatar}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.