Because of performance issues, I wan't to export manually my current MySQL database to my new installation. Is this possible or do I really need the XML export function of Jira?



5 answers

0 votes

If you are not changing the database type, then no, you can use mysqldump to get a copy of the database and simply load it into another mysql system.  Repoing the JIRA installation to the new database and you're done.

0 votes

Hi Wouter,

You can create a database dump if you want to, but if you want to backup the entire JIRA instance we recommend using the XML export function, otherwise important directories that are inside $JIRA_HOME won't be included.

I hope this helps!

Kind regards,
Felipe Kraemer
Atlassian Support

thank you for your quick reply's! Great service!

Is it possible to schedule the XML export function? Because, if I will use this function, I can't export within office time.

0 votes

Hi Wouter,

Actually, in both situations you will import your data and not move folder information around. The only difference is that by copying the database and pointing JIRA to it, you will force JIRA to gather it's information, while with the XML Import you will make JIRA import the data, which might thrown a few plugin dependencies errors.

All in all the folders should be impacted by either of this approaches.


ok, maybe I should inform you why I want this. Our production server is a Windows 2003. The new server is a Windows 2012. Both VM's. I have installed JIRA within the 2012 server. Next I will be going to install severall plugins. Then I want to create an backup of the production JIRA and import this within the new installation.

But creating the backup file, with XML or the mysqldump, will both effect the production performance for the users. That is why I want to let this backup run after office hours. May with a cronjob?

Er no. When you take the backup, you want JIRA offline completely to avoid inconsistent data. By all means, use a scheduler to stop JIRA and do the backup. Atlassian also recommend the use of the database tools for this sort of work, NOT the XML. And finally, Benito has it correct - for this, you should copy the home directory from production, change the config file so it points at your new database, and then use the mysqldump route to clone the production database. You should also change the JIRA startup to add the three lines that say "do not connect to mail servers"

thanks Nic, this is really helpfull. I'm new in this organisation and new with Jira. So I'm finding my way while doing the job. I'm going to use MySQL Administrator to create the backup. I guess I should use the 'Lock all tables' backup method, to be sure that I have a consistent backup. Is this the good method? When I import this backup, it is within a test environment, just to make sure that I got all the migrate steps in order.

Yes, you could lock the tables. But this can cause Jira to crash if it is running. A far safer approach really is to stop it while you take the backup (then you don't need the lock!)

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,725 views 17 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you