Restore of a JIRA backup using native backup tools

[Onno van der Straaten]

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.  

[crf]

A database backup will work just fine.  The problem is that the products do not know how to do the low level restore that is required, and the setup flow does not get along with the database already being populated.  If you configure the database directly in the application, then it expects the target database to be empty.  This is for safety as much as anything else – if there is data already there, we want to make sure we don't clobber it.

The path to restore from a database backup would be:

1. Restore the database image
2. Configure the database explicitly.  For example, with JIRA, you can use bin/config.sh to set up the dbconfig.xml file.

I can think of three advantages to the XML backup:

1. The product understands it directly and can take care of automated backups for you.
2. JIRA can do a project import from an XML backup (with certain conditions met); this feature cannot work on a raw database backup.
3. You can use it to migrate from one database to another, such as from SQLServer to Oracle or vice versa.

[Gregory Hicks]

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!

[crf]

"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]

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