It's almost required to lock down your JIRA instance when performing a full XML backup, so that the data isn't in an inconsistent (unrestorable) state. It's also recommended to use native database backups for disaster recovery. But, I don't see any recommendation about locking down your JIRA instance during native backups.
I don't know exactly how my native tool works, but what should I do to ensure a restorable native database backup?
The easiest answer is "Stop Jira" - same as the XML export. Then you know no updates are going on
Some databases support "point in time" backups - that is you kick off a backup at say 10pm, and the process doesn't take any data that changes after 10pm, so you end up with a snapshot, exactly as you get with "stop Jira"
Another option is replication (quite common in large installations). You've got a second database server which takes data replicated from the first. When you want a backup, you break replication (so the master carries on being Jira and the slave has no updates going on), backup the slave database and then reenable replication at the end
There are even more clever options too, but I'd read up on your chosen database to find out what they are. Or better, take your local friendly DBA for a pint!
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
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