Offline JIRA backup

[Jason Adam]

In our production environment, we plan on having two JIRA servers.  One is going to be the primary, and the second will be used for testing changes/upgrades before installing to the primary.

The secondary server will also act as a backup, in that if we ever need to failover to it due to the primary being down, we can do so. 

Since the secondary should always be at the latest and greatest, my goal would be to take the latest dump of the issues on the primary (still need to work that out with Postgres) database to the secondary.

However, and I am not even at the place to test this, in building the two servers, I noticed that I had to manually setup things like ScriptRunner behaviors because custom field IDs were different between the two instances (I use Botron configuration manager to export most of the project).  It seems like if I backup the primary database and try to import to the failover server, issues wouldn't port because of those custom fields.

Is this a correct assumption?  When doing a backup of the JIRA db, is the idea to pretty much do a complete export/import/replace of the db?  Will doing so grab everything within JIRA? Including things like those ScriptRunner behaviors I normally have to manually setup between environments?

Thanks!

[Nic Brough -Adaptavist-]

Taking a partial copy of the data with PostGres is going to be a nightmare, as you'll have to separate everything out and then match it up and partially reload it.

The database contains all the config for your projects and issues.  You should simply stop using Botron for it and just restore the database.  Plus, you will need at least the attachments and if you're using saved scripts rather than in-line, the "scripts" sub-directories of your jira-home install).

[Jason Adam]

Ok so it sounds like recovering production data, using Postgres dumps is the way to go.  I was mainly wanting to make sure that all scripting that we had within JIRA itself (we do have server side script files but those will be there already) would be copied.

And good call about attachments.  Right now we're saving them to the file system but I think I might change that to save them to the database for this very reason.

Botron is really just for moving workspaces to new environments where we want the configuration but not the data.  Definitely wasn't planning on using it for a backup system.  It just threw me off when I first used it that my custom fields, between deployments, had different IDs.  So got me thinking about best way to restore.

Thanks!

[Nic Brough -Adaptavist-]

Definitely.  A database backup is the recommended solution for backups and restoring to test systems.  If you want to look at advanced disaster recovery, then replication is a word that crops up quickly, but for most people "I have a copy of the database and the attachments" is good enough.

If you keep scripts in-line, they're in the database.  If you use the "run from file" option, then they are text files in <jira home>/plugins/scripts usually, so just copy that and you'll be fine.

Attachments cannot be placed in the database, but they're easy to share/synchronise (rsync or shared storage works fine in most cases, and even if you lose a couple, it's just broken links on issues, nothing else stops working)

[Jason Adam]

Ah I didn't realize that.  According to our JIRA admins on another project (mind you, they're using a much older version), they said they were storing their attachments as blobs/clobs in the db.  Guessing they're mistaken.

[Nic Brough -Adaptavist-]

It's never been possible in the baseline product.  I suspect they are confusing it with Confluence, where you could do it (From memory, versions 3.0 to 5.4, but data-centre made it redundant so they stopped)