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
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.
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:
bin/config.shto set up the
I can think of three advantages to the XML backup:
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.
"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.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Every time you release software, there's a bit of risk – that there's a bug, that something breaks, or that the feature doesn't resonate with customers. Feature flagging helps make high stakes s...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs