Rolling Back a JIRA Upgrade

The 'roll back' procedures on this page describe how to restore your previous version of JIRA in the unlikely event that you encounter an issue with your JIRA upgrade. Please follow the procedure below that relates to the upgrade procedure you used. Note that any data changed since the last backup will not be present after rolling back.

(info) If you upgraded JIRA using the Migrating JIRA to Another Server procedure, your previous JIRA installation should still be 'intact' (assuming you haven't deleted it) and there should not be a need to perform any 'roll back'.

Rolling Back a JIRA Upgrade Conducted Using the Upgrade Wizard

Use this procedure to roll back a JIRA upgrade conducted using the upgrade wizard.

(info) Prior to rolling back your JIRA upgrade, ensure that you have the following backups from your previous JIRA version:

  • The JIRA database (generated by your database's own backup tools).
  • The JIRA Home Directory.
  • The JIRA Installation Directory.

To roll back your JIRA upgrade conducted using the upgrade wizard:

  1. Stop the JIRA upgrade or the upgraded JIRA server if it is running.
  2. Use your database server's tools to restore the JIRA database backup you had created.
  3. Delete the contents of the JIRA Installation Directory.
  4. Restore the backed-up JIRA Installation Directory to the same location in the previous step.
  5. Delete the contents of the JIRA Home Directory.
  6. Restore the backed-up JIRA Home Directory to the same location in the previous step.
  7. Start JIRA (by running the start-jira.sh or start-jira.bat file in the bin subdirectory of your restored JIRA installation directory).
    (info) On Windows based systems if JIRA was installed as a service, restart the Atlassian JIRA service from the Control Panel. The JIRA service entry will be retained even if there is an error during upgrade in order to facilitate the rollback.

Rolling Back a JIRA Upgrade Conducted Manually

Use this procedure to roll back a JIRA upgrade conducted using the manual JIRA upgrade procedure (involving an 'in-place' database upgrade). The intended result of this procedure is to restore your previous JIRA installation to its original state (consisting of the restored database as well as the JIRA Installation and Home directories in their original locations).

(info) Prior to rolling back your JIRA upgrade, ensure that you have the following backups from your previous JIRA version:

  • The JIRA database (generated by your database's own backup tools).
  • The JIRA Home Directory.
  • The JIRA Installation Directory.

To roll back your JIRA upgrade conducted manually with an 'in-place' database upgrade:

  1. Stop the JIRA upgrade or the upgraded JIRA server if it is running.
  2. Use your database server's tools to restore the JIRA database backup you had created.
  3. If you had deleted the JIRA Installation Directory of your previous JIRA version, restore the backed-up JIRA Installation Directory to its original location.
  4. Delete the contents of the JIRA Home Directory.
  5. Restore the backed-up JIRA Home Directory to the same location in the previous step.
  6. Start JIRA (by running the start-jira.sh or start-jira.bat file in the bin subdirectory of your restored JIRA installation directory).

Was this helpful?

Thanks for your feedback!

10 Archived comments

  1. User avatar

    Carsten Beck-Astrup

    Is this method also possible?

    1. Drop all the tables
    2. Start JIRA (the old one)
    3. Click on the import link on startup-screen
    4. Copy an old backup file from the export directory to the import directory
    5. Write the name of the backup and start importing
    23 Apr 2012
  2. User avatar

    Andreas Gounaris

    What tool should be used in linux to unzip the application directory? In my case, I used unzip but it didn't preserve the x file attribute, all .sh files couldn't be executed and the launch stopped. Is there a way I can unzip JIRA installation directory with the x attribute preserved? 

    25 Sep 2013
    1. User avatar

      Anatoli Kazatchkov [Atlassian]

      Hi Andreas, 

      Unfortunately zip archive does not preserve file attributes. So there is no tool that would help.

      25 Sep 2013
      1. User avatar

        Andreas Gounaris

        I thought so.

        The information in this page is not valid for Linux systems. Someone shouldn't rely on the automated backups for a rollback, he has to manually backup the application directory using another tool (e.g. tar.gz).

        I had a bad incident and I had to rollback. Luckily it was my staging server and not production!

        26 Sep 2013
        1. User avatar

          Kostas Tsolakos

          I had exactly the same problem when i was doing some tests in staging environment.

          26 Sep 2013
        1. User avatar

          Anatoli Kazatchkov [Atlassian]

          Andreas, 

          Is it only the execution that you are worried about?

          chmod u+x *.sh 

          Should fix that.

          26 Sep 2013
          1. User avatar

            Andreas Gounaris

            What about the jre/bin folder if the embedded JRE is used?

            What about symbolic links? ( I saw at least one in the jre/bin folder: ControlPanel -> ./jcontrol )

            It needs more than that to be a "proper rollback", especially in cases where time is chasing you!

            27 Sep 2013
  3. User avatar

    Ivan Borges

    What a nightmare. There is no excuse for an upgrade to be this complicated. After going from 6.1.3 to 6.4.8, I have had problems logging back, since it says it can't find the user by the time I enter the key. Then run the query to update the database license information, which opened the application, and on logging in, oops, error on com.atlassian.jira.web.pagebuilder.AbstractJspDecorator.writeTemplate.

    Now trying to roll back to previous version and an afternoon has gone by which cost a big loss and everybody upset.

    Really? Just for an upgrade? It won't read the current users because of a change in structure?!?!?!?!?!

    16 Jul 2015
    1. User avatar

      Matt Doar [ServiceRocket]

      This is a good reason to make sure you have a JIRA Internal admin account so you can always log in.

      But you did do the upgrade in staging first, right? Upgrading any production server directly is rarely a wise idea.

      17 Jul 2015
      1. User avatar

        Ivan Borges

        Hi Matt.

        Thanks for the attention.

        I have managed to make it work, by the way. And I kind of feel we are now talking about the things I should have taken care of, instead of discussing what Atlasssian should have done for things like these not to happen.

        Anyway, maybe we lost my point somewhere, or more likely, I shouldn't even spend time on complaining.

        Cheers.

        17 Jul 2015
Powered by Confluence and Scroll Viewport