In the SaaS world it is your responsibility to backup your data per the shared responsibility model used by Atlassian and other SaaS vendors. Know your responsibilities as a SaaS administrator when using Atlassian’s Jira Cloud here. Data deletion, be it accidental or malicious, occurs on an unpredictable basis, and such events are out of your control as an administrator and hence your insurance policy against data deletion is to backup your data. Lets review the pro’s and con’s of doing a Jira Cloud Database Backup using the tools that Atlassian provides.
Steps to create a Jira Cloud Database (XML) Backup
There are couple of things to consider as part of your Jira backup strategy:
- A backup file created using the database backup mechanism is a full backup i.e. includes all the projects / issues / attachments & configuration.
- A very important consideration for creating a database backup is the volume of data in the backup, which is determined by the no. of Jira issues you have in your site and volume of attachments.
- A typical Jira site having 500K+ issues with 200K attachments would create a zipped backup file which is approximately 150G, of course every site is different, this is based on what I have seen.
- The time taken for creating the backup and downloading the data is driven by the size of the backup file. The larger the file the more time taken, and potentially run into data transfer timeouts, because of which you may have to restart the process all over again.
- You can automate this process of creating a backup, but you would have to use some un-documented API’s using an API token
- Using API tokens has its own risks, ensure you are following the best practices on using API tokens
- The database backup along with attachments can only be performed every 48 hrs
The whole purpose of creating a backup is to ensure you can restore the data back in the case of any accidental data loss. Lets next review the steps that need to be taken to get the data back into your Jira site.
Steps to Restore a Jira Cloud database (XML) backup file
The Import Jira Cloud functionality is available under the “Settings → Import and Export” menu, but before you begin a restore of your Jira backup data lets review the steps that Atlassian recommends that you take.
- We recommend splitting your cloud backup file into two separate files: a data file containing your activeobjects.xml and entities.xml, and a separate one for your attachments and other media. Learn more
- The total size of the .xml files should be less than or equal to 10 GB before zipping and importing the file. To import larger files, contact support.
- Import your data first. Importing your data file will overwrite all data (except for users and groups) in your Jira Cloud site.
- Then, import your media file(s). If your media file is greater than 10 GB, split it into smaller (2 - 5 GB) files and import each separately. Learn more
Knowing how much data is in your backups is absolutely critical, as that will determine how you proceed i.e. do you need to engage Atlassian support or can you do it yourself. When you do a database import back into your production site, all existing data will be overwritten, be very careful when you do that as you will lose all the data that was added /modified between the date / time when you took the backup to when you are able to re-import the data back into a Jira site. While you intent may have been to recover back critical data from the backup that you lost, a full restore may not lead to the intended outcome.
Having now seen the steps that need to be taken to do a backup and restore of your Jira site, let me summarize the pro’s and con’s of doing a database backup and restore.
Pro’s and Con’s of Jira Database Backup & Restore
Pro’s
- Comprehensive, contains all Jira objects encapsulated in the database file
- When data is restored back timestamps are maintained along with history and change logs
Con’s
- Depending on the size of the dataset in your Jira cloud site, one may have to retry creating the backup file and then downloading it multiple times
- Incremental backup of the Jira site is not possible, which means the time spent each time you do a backup operation keeps on increasing
- A backup operation can only be performed every 48 hrs with attachments and every 24 hrs without attachments
- The backup is not held in the cloud but rather it has to be maintained by you
- Backup data is not searchable
- Potential loss in data when you restore the data back
- Depending on the size of the dataset you may have to work with Atlassian support to retrieve your data back and there may be some manual steps involved in the restore operation
How can Revyz Help
Implementing a data protection strategy for Atlassian Jira cloud has become a necessity and equally complex. With limited native options from Atlassian, you will have to either build some custom scripts, manage data on your own to address your data protection needs or you leverage 3rd party SaaS applications such as Revyz to offload data protection from your core IT team.
Revyz Backup & Restore app for Jira can store data securely & remotely, making it available for various recovery scenarios without having you to rollback the entire site.
Try Revyz for free - Atlassian marketplace link. Share your feedback on how we can improve & what other use cases you would want Revyz to address.
Blogs from Revyz
Atlassian Data Protection - Challenges in the Cloud
7 Reasons Why A Jira Backup & Restore Solution Is A Must Have
Pro's and Con's of using Jira Cloud Database Backup & Restore
Mystery of Incorrect Sprint Reports
Jira - Restoring Issue Family Hierarchy
SaaS Backup: An Antidote to Ransomware
Data Backup - A Key Pillar of Insider Risk Management
What’s your Atlassian Cloud Migration & Data Protection Strategy?
A Guide to SaaS Shared Responsibility Model
Why you need a SaaS backup strategy and solution
Why we built Revyz
