XML backup generation fails

Question

Hi guys,

I wanted to see if someone has encountered and hopefully solved an issue we are currently getting with a backup file generation.

We are trying to do a migration from Server to Datacenter, but for that we need to switch from a MySQL to a Postgres database. So far we've set up a totally new environment with the same Jira version we are using, but with a postgres db connected to it. Then following the native backup procedure we try to export our current system, to then import it into the new environment, but we are experiencing some issues with the backup file.

The file itself takes around 1.5h to be generated and it's a bit over 12GB (we have quite a big system). For that we've increased our EC2 memory and storage space but it seems to be corrupted or not complete every time. We get the following error when we try to unzip it:

$ unzip /var/atlassian/application-data/jira/export/backup.zip

Archive: /var/atlassian/application-data/jira/export/backup.zip

End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive.

unzip: cannot find zipfile directory in one of /var/atlassian/application-data/jira/export/backup.zip or /var/atlassian/application-data/jira/export/backup.zip.zip, and cannot find /var/atlassian/application-data/jira/export/backup.zip.ZIP, period.

When importing it we're getting an "Not a valid zip file" error.

We could unzip it using 7zip but we see that the activeobjects.xml file is either missing or has nothing inside.

We tried to import only the entities file and then we got another error which doesn't show after cleaning it up with the xml cleaner mentioned here:

https://confluence.atlassian.com/confkb/incorrect-string-value-error-thrown-when-restoring-xml-backup-in-confluence-777009599.html

If we do that it does partially import it but we are obviously missing a lot of stuff there (add-ons, JSM, assets, etc..)

The idea is to import the zip file, and assuming it works, then switch the license to a Datacenter one.

Please let us know if we are not following the correct steps or if anyone has encountered similar issues and has found a solution, as well as if you need any more details about the process or anything else that might help.

Yavor_ur5864 · Answer

Update - we exported our xml backup files and used an xml cleaner to clean both the entitites and activeobjects xml files, zipped those again and did the import - this time it got stuck at 90% due to some invalid characters in the AO_544E33_AUDIT_LOG_ENTRY table.

Yavor_ur5864 · Answer

Hi Payne, thanks for the answer. We are mostly doing that because this is Atlassian's recommended and supported DB type and because we are planning to switch to cloud at some point in the next few years so we would like to have that done now.

We actually got the backup file to work yesterday, by increasing our storage and memory so that looks good now. Our current issue is on the import stage - we were able to start it but for some reason it's ok until it reaches 20%, but then it's stuck there for hours. We've checked the logs but so far we couldn't find anything useful. Has anyone gotten into a similar issue?

Payne · Answer

I don't know your exact situation, but I don't see a need to move from MySQL to PostgreSQL. We recently moved from Server (using MySQL) to Data Center, and all we did was update our license key.