If your organization has used Jira for any length of time, you’ve likely built up a trove of data inside the platform. That data is crucial to running your company and making business decisions, and as with any important data, you want to make sure your Jira data is backed up in case it gets corrupted, you experience a data loss, or in a rare event of an outage.
However, once you’ve decided you need a backup solution, there are many options to consider. There are self-built solutions, which can have a lower up-front cost, but require that you maintain the infrastructure that actually makes the backups and all that entails. There are also backup solutions that you can purchase, often called BaaS (backup-as-a-service), which often have a higher up-front cost but take care of all that management for you.
Regardless of which backup solution you choose, having a backup of your Jira data is important to ensure business continuity in case of failures or service interruption. Backups also give you peace of mind and prevent data loss that, in some cases, might be permanent without a backup. However, even though backups are critically important, Jira Cloud doesn’t offer support for automated backups, which raises the question of if it’s better to build or buy your own solution.
In this article, you’ll be taking a look at various possibilities for backup solutions and comparing them on:
- Reliability and efficiency
- Ease of creating backups
- Content and coverage of backups
- Frequency of backups
- Backup setup and configuration
- Time to create a backup
- Backup granularity
- Ease of restoring data to a Jira Cloud instance
With that in mind, let’s take a look at some of the tradeoffs that come with the various possible backup solutions.
Building your own Jira backup
If you’re looking to build your own Jira backup solution and are okay with some programming work and setting up and monitoring the infrastructure on your own, you can do this either using Atlassian-provided backup scripts or with Jira Automations.
Using Atlassian-provided backups scripts
Atlassian maintains a repository with backup scripts in various languages. While these are not endorsed by Atlassian or guaranteed to work, they can provide a good starting point when you’re trying to automate your backups. To get these backups running, you’ll need to complete a few steps.
Because these scripts connect through the Atlassian API, you have to have an Atlassian API associated with the account you use to log in to Jira Cloud. If you’ve never gone through this process before or if you need more information on exactly where this can be found, Atlassian’s official documentation on how to obtain an API key for your account will get you going.
The scripts in the repository are available in Bash, PowerShell, and Python, and you’ll need to select the one that works with your system configuration. You can clone the entire repository onto your system, and the files will then be cloned into your current directory. Then you’ll be able to execute the backup script, using the appropriate commands for the language you’re working in.
At this point, you can run your backup script, but running it manually every time you need to make a backup isn’t a great solution. To handle this, you can set up a cron job to automatically run the command above every week at the same time. You can use a site like crontab guru to help you with the correct syntax, then create the cron job by editing your crontab file on the server where you’re hosting the backup script.
That’s all it takes to get an automated backup of Jira running! The downsides to this approach are that you’ll need to maintain and secure your infrastructure, and you’ll need to figure out how to restore your own backups. Unfortunately, restoration is significantly more complex than creating the backup itself. There aren’t any Atlassian-provided scripts to help you restore your data, so you’ll have to build your own solution using the same API access you used to make the backups.
This is what pushes some organizations toward a purchased solution like Rewind. With Rewind, you can easily restore your backups whenever you need to, without having to write any custom code or worry about restores breaking under the load of too much data.
Using Jira Cloud automation
In addition to the unofficial backup scripts that Jira provides, there are also automations, which help you automate actions in Jira based on the criteria that you set. The only prerequisite is that you have a Jira cloud account that you will use to create the automations. Let’s take a look at how to set up a Jira automation to create a backup.
As before, you’ll need to start by obtaining an Atlassian API key. Once you have your API key, you can encode your key, along with the email for your Jira Cloud account, by running the following command in the console:
bash echo -n "EMAIL@EXAMPLE.COM:API_KEY" | base64
Where the two strings in capital letters have been substituted for your actual email and actual API key. After running this command, you’ll see an output string. This is your encoded credentials and will be needed in the next few steps, so be sure to make a note of it.
To actually set up the Jira automation rules, you can follow the steps in Atlassian’s documentation.
Backups are stored for a limited period of time—a maximum of fourteen days or until the next backup is completed. This means that if you want to keep a record of your backups for auditing or compliance purposes, you’ll have to be sure that they get downloaded on a regular basis. There’s also no option to restore your backups, so once again, you’ll need to build a solution for that on your own.
With both these approaches, it’s important to consider how often your backups are being taken. With the backup script approach, you can configure your crontab to set the frequency of the backups; with the Jira cloud automation, you can set up the frequency in much the same way, using cron notation. If your data in Jira changes frequently, it may make sense to run daily backups. Though if data changes much less frequently, you may be able to get away with only running backups once a week or once a month.
In addition, an important consideration of these solutions is that neither offers an automated way to restore your backups to your Jira instance. That would either have to be a separate script or automation. While a purchased solution such as Rewind makes restoring your backups as easy as clicking a button, with a self-serve solution, you not only need to test your backup process to ensure data is saved correctly, but you need to design, implement, and test your restoration process, as well. This can get tricky if you don’t have a separate instance to which you can restore test data, as well as test a multitude of other potential edge cases. Since backups are only as useful as your ability to restore them, these limitations have led many organizations to look for a better way.
Using a purchased Jira backup solution
The alternative to self-built or self-configured backup solutions is purchased backup solutions, such as the one offered by Rewind. Among the benefits of purchasing a solution like this is that all the infrastructure, scheduling, and everything else related to backups are managed for you rather than needing to be handled internally. This is an amazing benefit, saving your team hours of work and ensuring that your backups—and restorations!—work as expected without constant maintenance and management. Let’s take a look at an example of how you would set up Rewind to handle your Jira backups.
The only prerequisites for this are that you’ll need both a Rewind account and a Jira Cloud account. To ensure Rewind has access to your Jira Cloud account, you’ll need to give Rewind access to Jira from within the Rewind dashboard. Once there, you can use Rewind’s no-code platform to set up your automated backups and be sure that your data is managed and secure, as well as ready for automatic restoration when needed. If you need to restore the data, all it takes is a few clicks in Rewind’s user-friendly interface to start the process, and the platform handles the rest for you.
Comparing backup solutions
Thanks to the shorter setup time and easier restoration, purchased Jira backup solutions are often preferred over self-built ones. However, let’s take a look at both solutions, using the criteria we had laid out previously.
Reliability and efficiency
Because you maintain all your own infrastructure with the self-built solution, it’s inherently more fragile than a purchased solution. A company that’s entirely focused on keeping your backup infrastructure up and running will always be more reliable than running the infrastructure yourself.
Ease of creating backups
With a third-party solution like Rewind, you don’t have to have any programming knowledge or any knowledge of the backend of Jira to set up your backups. Most self-built solutions require at least some technical knowledge to implement and significantly more to restore the backups that you’ve created.
Content and coverage of backups
While both the self-built and purchased solutions allow you to have full coverage of all your Jira-hosted content, it’s worth noting that a complete backup with attachments can only be run every forty-eight hours. If you have a high-volume account, this could lead to data loss.
Managed backup solutions can often bypass this attachment limitation, including Rewind. See the full list of what Rewind backs up for Jira.
Frequency of backups
The self-built backup solutions require that you know cron syntax, so you can customize the frequency of your backups. A purchased backup solution allows you to customize the frequency of your backups without any special programming or syntax knowledge at all.
Backup setup and configuration
In order to get a self-built solution up and running, you’re going to need someone with programming and systems knowledge in order to get everything configured. With a third-party solution, all of this is managed for you, and it requires little work and no technical knowledge on your end.
Time to create a backup
Depending on how much infrastructure you allocate to the backup-creation process and how much data you have in Jira, your backup time with a self-built solution may take anywhere from a few minutes all the way up to multiple hours. With a purchased backup solution, you don’t have to worry about how much time your backup consumes. Your backups will always be performed on time, and resources to do so will be allocated appropriately.
When it comes to creating the backup, the ability to modify the provided backup scripts means that the self-built solution can sometimes offer more opportunities to adjust the granularity of the backups. When it comes to restoring, though, you’ll need a third-party solution like Rewind if you want to be able to control what, exactly, gets restored. Learn more about item-level restores with Rewind.
Though the self-built solution might initially seem more appealing from the cost-effectiveness perspective, the amount of engineering and system administrator time that has to be dedicated to setting up and managing a backup system can increase costs quickly, and that’s assuming everything goes well. If something goes wrong and you need to restore your data, you’re looking at more time and money, just to get your business operational again.
With a purchased backup system, you have a flat monthly cost that stays the same regardless of what else happens. Whether Jira implements API changes that need to be accommodated or your backup needs to be restored, the cost to you doesn’t change.
With a self-built solution, you have to manage all the security yourself. Depending on your industry and the security practices you comply with, this may be expensive and time-consuming. With a purchased solution, especially one that’s highly secure, your backups stay safe and secure no matter what the circumstances, which is one less thing for you to worry about.
Ease of data restoration
This is the biggest difference between self-built solutions and purchased solutions. With a solution like Rewind, restoring your backups is easy and doesn’t require any specialized knowledge or coding ability. If there’s an incident that causes data loss, all it takes is a few clicks, and your data’s on its way back to where it should be.
If you’re using a self-built backup solution, you’re responsible for restoring your own data, which has to be done programmatically and can add to the burden that your team might already be feeling as a result of an incident.
One of the last things you want to be worrying about while you’re in the middle of a crisis is whether your restore process is going to work successfully—or how to implement a restore process in the first place. With a solution like Rewind, which has restores baked into the core product, restoring your data is just one click away.
When it comes to deciding on a backup solution for data as important as the information your organization has stored in Jira, you want to make sure you choose the option that best fits your organizational needs. If you already have a large technology team with the capacity and skill set to manage a custom backup and restoration solution, a self-built backup solution might be a strong option.
On the other hand, if you want to make sure there’s someone watching your backups around the clock to make sure they’re not only captured and stored properly but can be restored at the click of a button, consider a solution like Rewind. You can set up automated daily backups in minutes and know that you have full backup coverage—and the ability to restore your data quickly and easily in the event that something goes wrong. And if you’re looking to back up your Jira data, that’s everything you could hope for.