How to clone JIRA instance to a new server with same settings

[Kyle Zhang]

Hi,

We would like to setup another JIRA server and perform a full clone of the current JIRA server over to the new one. It would all just come over as part of the clone. 

Instead of the normal migration using import/export xml backup file, do we just need to reconfigure the Jira software and database with the new server name and IP address? The Jira application would still use the same port number on the new server.

If the entire OS and application file systems are cloned to the new server, can Jira be reconfigured with the new server name without requiring a new install? Also, if they are performing this clone using something like VMWare VMotion, can it be done with the existing application and database up and running or does everything need to be shutdown?

Thanks,

Kyle

[Jonas Andersson · Accepted solution]

This all depends on how you set up Jira. If the database is on the same machine and the database host is set to 127.0.0.1 it makes things easier.

You can clone it while running on low load, boot it with it's nic disabled, set a new ip, add /etc/hosts entries to all your Atlassian stack to localhost (otherwise you will have 2 applicationservers talking to all your application links from the same unique id).

Before starting it up, it makes sense removing your hardcoded hostnames in the database, so do a mysqldump, and do something like:

cat jira.sql | sed 's/http:\/\/jira\./http:\/\/jira-test2\./g' | sed 's/https:\/\/jira\./https:\/\/jira-test2\./g' | sed 's/http:\/\/other.hostname\./http:\/\/confluence-test2\./g' | sed 's/https:\/\/other.hostname\./https:\/\/confluence-test2\./g' | sed 's/http:\/\/jira\//http:\/\/jira-test2\//g' | sed 's/https:\/\/jira\//https:\/\/jira-test2\//g' | sed 's/http:\/\/other.hostname\//http:\/\/confluence-test2\//g' | sed 's/https:\/\/other.hostname\//https:\/\/confluence-test2\//g' | sed 's/http:\/\/confluence\//http:\/\/confluence-test2\//g' | sed 's/https:\/\/confluence\//https:\/\/confluence-test2\//g' | sed 's/http:\/\/confluence\./http:\/\/confluence-test2\./g' | sed 's/https:\/\/confluence\./https:\/\/confluence-test2\./g' > new.jira.sql

The import the new dump back to the mysqlserver.

At this point find your dbconfig.xml and verify that it does not point to your production database server

Lastly, edit your setenv.sh to make sure you have the disabled email row uncommented. If not you will receive 2 notifications from different servers.

Lastly, if your JIRA instance talks a lot to applications around your landscape, add all the hostnames, short and FQDN's to the hostfile pointing at 127.0.0.1. Better to have it chatter to itself than a production instance.

If you terminate SSL you might need to replace your cacerts file with a new keystore.

[Kyle Zhang]

Thanks Jonas for your quick reply. Looks like it is not as easy as using JIRA default export/import xml backup files.

Is the following way also good enough to do the migration?

1. Fully Clone the server.(JIRA & Database)

2. Export the data from old server using XML backups and Import them to the new server.

Do I still need to install all the plug-ins in cloned server?

[Kyle Zhang]

Another question is 

If the entire OS and application file systems are cloned to the new server, can Jira be reconfigured with the new server name without requiring a new install?

[Deleted user]

Hello @Jonas Andersson ,

Thank you for sharing this! It helps a lot to understand.

Would it be possible to share the script?

[Jonas Andersson]

I finally took the time to write a jira-cloner for work. It's written in bash but due to being developed at work they own the IP so i can't share the code but i can share a few things i learned along the way.

Stepstoning it functions with continues sanitychecks is a must. Two instances that accidentally talk to the database WILL crash production and test and leave the database in a mess very hard to recover from.

I start the process on production server. In short:

* kick of a script that verifies the status of the test server, makes sure it can SSH with a ssh-key, that the test-instance is not running, that mysql is installed, apache rewrite proxy exists and so on, then proceeds to delete most of the data/app directory (skipping logs as we have gigs of it). It also drops the database and recreates an empty one.

* Next on production i do a mysqldump that is added to /opt/atlassian/

* Next i rsync the database dump and a current copy of the filesystem to the test server.

* Next i kick off a script that updates:

server.xml (changes reverse proxy statements

setenv.sh (disable emails as you dont want notifications from test)

dbconfig.xml (change database server to localhost, renaming username/password/database)

* stringreplaces all instances of hostnames such as jira, bamboo, bitbucket, confluence to it's correlating test-server names in the database dump file, then imports it to the local database server.

* using openssl i download all the respective certificates to files, and imports them to the keystore.

* replace our jira logo with one that clearly states jira-test

* using atlassian guide on how to remove application links via the database, i automated this into a script too.

* using a list of host i dont want this server to be able to talk to, i add them to /etc/hosts (localhost) making sure if jira wants to talk to them, it will only talk to localhost.

Outcome:

I can now clone jira while it is still running in less than 25 minutes, by simply firing up a single script. Most of this time is spent on rsyncing 26gb of files over the network, and a fraction to sed replace hostnames in database and the import of the database dump. I noticed that not deleting all was an option, but the footprint of cache dirs might grow on test, but in return i can clone it in ~ 5 minutes.

It's well worth taking this time to automate it, because what was a gigantic task that took 5 hours and only happened every 3 months, can now happen on a weekly base.

The only manual labor left is reestablishing the application links, but once i have done this for all atlassian apps, i will approach this issue too, most likely via the database.

Next up: Confluence! :)

[Henry Auffahrt]

Thanks for sharing this with us! Very helpful!