Restore of a JIRA backup using native backup tools

Question

Atlassian recommendation for backup is to use native backup tools.

But if we use that, will we be able to restore JIRA from a database backup? Can we test that it is possible to restore JIRA from such a backup?

I tested this and found that this doesn't work. Not with JIRA 6.3.12.

I installed 6.3.12 on a new machine and have restored

* JIRA home /var/atlassian/application-data/jira/
* JIRA install /opt/atlassian/JIRA
* PostgreSQL database

I checked the configuration to make sure that dbconfig.xml is pointing to the new database.

After (re)starting JIRA, JIRA starts the setup wizard, not my restored JIRA instance. The setup wizard does offer the option of importing data but my understanding is that this is the XML backup, not the backup created native backup tools.

So it seems that contrary to Atlassian documentation restore using native tools is not supported. It would be wise to update the documentation to make 100% clear that there is no purpose in creating backups using native tools.

Is this the same for other Atlassian products? Confluence for example.

Gregory Hicks · Answer

Wealth of knowledge my friend! Thank you very much for the details, this puts me more at ease moving our production env.

crf · Answer

"Exactly" is a very strong word.  If you were to compare the databases from before and after, they would probably not match "exactly".  However, what differences there might be would not be functionally relevant.  If you don't care about the details, then feel free to ignore the rest of this...

1. There is a set of tables that are deliberately excluded from the import/export process.  Most of these are tables like "clustermessage" and "nodeindexcounter" that are used to coordinate a JIRA Data Center cluster.  However, there is another table called "entity_property_index_document" which is also excluded.  In all honesty, I don't understand why it is even stored in the database; it seems to me like it shouldn't be.  However, since it is stored in the database but excluded from import/export, its values would be recreated dynamically after the import completes.  As a result, there would likely be differences in the values in that table, particularly the ID numbers and "updated" timestamps.

2. JIRA starts functioning again immediately after the import completes and would start, for example, running scheduler jobs.  These would update the information in the "clusteredjob" and "rundetails" tables accordingly, so their data would not match "exactly" either.  Depending on what jobs run, there could also be other changes; for example, a job that performs an LDAP sync could obviously alter information in your user directory tables.

But none of this is "missing data".  The system should be functionally equivalent after the restore.

Gregory Hicks · Answer

Question about the restore from XML. I just moved my Stage install from one server to another using a blank database. After the XML restore does that restore the new database to exactly what the old one was? I just want to make sure that when I move on to prod there isn't missing data.

Thanks!