JIRA is now available as three separate applications, JIRA Software, JIRA Service Desk, and JIRA Core. For more information on administering these applications, refer to the Administering JIRA Applications documentation.

Sending JIRA Data to Support

To replicate reported problems, Atlassian support staff may ask you for a copy of your JIRA data.

As of JIRA 4.1.1, it is no longer possible to send data via the Administration -> Support Request page. Please see below for instructions on providing a manual XML Backup.

Manual XML Backup

To perform a once-off backup, follow the steps below.

  1. Log in as a user with the 'JIRA System Administrators' global permission.
  2. Select 'Administration' > 'System' > 'Import & Export' > 'Backup System' (tab) to open the 'Backup JIRA data' page.
    (tick)Keyboard shortcut'g' + 'g' + type 'backu'

    (info) As shown in the screenshot above, the backup will be stored within the export subdirectory of the JIRA Home Directory.
  3. When the backup is complete, a message will be displayed, confirming that JIRA has written its data to the file you specified.
  4. Attach the generated file on disk to a support request on support.atlassian.com.

Support requests are often resolved significantly faster if a data export is provided as it will allow our legendary supporters direct access to a copy of your instance. We understand that sometimes this may be a difficult option due to the sensitivity of your data and have written an anonymising tool to handle this particular scenario.

Anonymising JIRA Data

The JIRA inbuilt backup functionality will produce a ZIP file containing either 1 or 2 XML files, depending on the version that is being used. These files are a copy of the entire contents of JIRA's database, encoded in XML, that can be used to restore an instance - we have further detail on this in our Automating JIRA Backups documentation.

As of JIRA 4.4, the backup functionality will produce a ZIP file that contains 2 XML files. These files will be activeobjects.xml and entities.xmlOnly entities.xml will need to be anonymised - please do not attempt to anonymise the activeobjects.xml. For versions prior to 4.4, only one XML file will be produced with the same naming convention as the ZIP it is compressed as (for example 1970-Jan-01–0001.zip will expand to 1970-Jan-01--0001.xml).

  1. Ensure that the JAVA_HOME variable has been configured, as in our Setting JAVA_HOME documentation.
  2. Download the JIRA Anonymiser.
  3. Create a temporary directory.
  4. Unzip the anonymizer in the temporary directory.
  5. Unzip the JIRA backup ZIP file (for example 1970-Jan-01--0001.zip) in the temporary directory.
  6. Anonymise the backup file with the below commands:

    $ java -Xmx512m -jar joost.jar <JIRA BACKUP>.xml anon.stx > <NAME OF ANONYMISED BACKUP>.xml

    For example, this would be anonymising a JIRA backup with the naming convention from JIRA 4.4+:

    $ java -Xmx512m -jar joost.jar entities.xml anon.stx > anon-entities.xml

    (warning) Depending on the size of the backup, additional memory may need to be allocated to the JVM. In order to do this, increase the value of the Xmx in increments of 128m.

  7. Compress the generated anonymised XML backup file (e.g: anon-entities.xml) and the activeobjects.xml(JIRA 4.4.x + only) into a ZIP or tarball.
  8. Attach that ZIP or tarball onto the support issues as raised on support.atlassian.com.
  9. The temporary directory can now be removed.
The screenshot below is a simple example of how it is run in the command prompt of Windows XP:

Information about the Anonymiser

The anonymiser currently replaces the following text with x's:

  • Issue summary, environment, and description.
  • Comments, work logs, change logs.
  • Project descriptions.
  • Descriptions for most elements (notification schemes, permission schemes, resolutions).
  • Attachment file names.
  • "Unlimited text" custom fields.

Please check the anonymised backup, anon-backup.xml, to ensure it's clean enough for the needs of your organisation before sending it to Atlassian.


Invalid XML Characters

If, when the anonymiser runs, an error indicates that there are invalid XML characters in the XML backup of the database, run our utility to remove invalid XML characters first before anonymising.

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

14 Archived comments

  1. User avatar

    Markus Lepper

    "The anonymiser currently replaces the following text with x's:...."

    Some more fields shall be anonymized as well!
    assignee, author, updateauthor, OSMembership, project keys/issue ids,...

    BR, Markus

    09 Dec 2010
  2. User avatar

    Yoram Weizman

    It would be good if it works on zipped backup too.

    31 Aug 2011
    1. User avatar

      Marcel "childno͡.de" Trautwein

      We should vote for JRA-29161 - Put the support backup Anonymizer into JIRA BTF Closed

      23 Oct 2012
      1. User avatar

        Marcel "childno͡.de" Trautwein

        as mentioned in JRA-19977 - Totally anonymous backup Closed , there is now a new (internal) improvement for this STP-196

        24 Oct 2012
  3. User avatar


    It should also changes:

    • user emails
    • user names
    • LDAP server and login details
    • Components
    • Base URL
    03 Nov 2011
  4. User avatar


    The article refers to backup.xml but the current backup process generates entities.xml and activeobjects.xml (zipped).

    30 May 2012
    1. User avatar

      Marcel "childno͡.de" Trautwein

      The support needs this activeobjects too to replicate database problems! So you have to re-zip the bundle again!


      23 Oct 2012
  5. User avatar

    Marcel "childno͡.de" Trautwein

    (warning) for all who are using jenkins / hudson plugin :

    Jenkins / Hudson password is stored plaintext in activeobjects.xml!

    23 Oct 2012
    1. User avatar

      Philip Schlesinger

      That's no bueno!

      01 Jun 2015
      1. User avatar

        Marcel "childno͡.de" Trautwein

        no, that's not. You might check if it's still the case in the new jenkins plugin but I'll bet yes.

        Why?: any / most plugin(s) storing passwords for external connections will save their data in an activeobject table as this is the preferred way to store plugin data. Since external systems do not use proper and secure authentication methods that doesn't only need username/password you'll end up at the same problem: anywhere you need to save the plaintext credentials to do the authentication from JIRA to XXX. Those who don't save "plaintext" passwords for those auth methods, perhaps may cover them by pseudo-Crypto but I expect most of them are even not safe at all because they will make the mistake to save the "encryption key" aside in the same DB. Just "obfuscated" but no more "secure" at all.

        refer to https://developer.atlassian.com/docs/atlassian-platform-common-components/active-objects and https://developer.atlassian.com/docs/atlassian-platform-common-components/active-objects/developing-your-plugin-with-active-objects/best-practices-for-developing-with-active-objects if you want to read more about what "activeobjects" are.

        So: no time to "blame" but to "take care" if you send out your support zip.

        The "anon" script will mask all default / JIRA Application known sensitive data but is not able to do this for any plugin.

        That's what I want to say (wink)

        01 Jun 2015
  6. User avatar

    Susanne Harelius

    The download link does not seem to work from 5.1 version of the documentation (cannot comment that page though). 

    07 Aug 2013
    1. User avatar

      Boris Berenberg [Atlassian]

      Thanks for the heads up! Will ask docs team to fix.

      07 Aug 2013
  7. User avatar

    Amos Shapira

    Here is a little saga I went through when I tried to follow the instructions above, I found a work around which might help others until the root cause (JIRA generating invalid XML files) is fixed:

    The java command kept breaking on control characters inside the XML file. Every time I replaced control characters by their "^X" representation manually with "vim" it found more characters.

    "cat -v" of the entities.xml file and feeding the result to the Java program triggered the following error:

    com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 2 of 3-byte UTF-8 sequence.

    I figured that it happened because "cat -v" also mungles bytes with 8th bit on.

    So I filtered the original .xml file through the following command and it worked:

    What this does is to replace all control characters except horizontal tab and newline by their "^X" representation.

    Hope this helps someone.

    BTW - this happened with JIRA 6.1.3#6158-sha1:b5b5eab, not the latest one.

    15 Aug 2014
  8. User avatar

    Kathy Plamann

    The Download the JIRA Anonymiser link doesn't work for me. What do I need to do- please advise?


    30 Jan 2015
Powered by Confluence and Scroll Viewport