A Complete Guide to Backing up Your Jira Cloud Data

You’ve just finished onboarding your team to Jira Cloud or finally finished your mandated migration from Jira Server and are relieved to think your work is finally done.

Then, as you waltz through the Jira Cloud documentation, you trip over a troubling sentence like this: “Atlassian doesn’t officially provide data rollback based on customer requests. So it’s essential to take site backups regularly.”

You dig a little deeper into the implications of this inability to roll back data, which leads you to learn about Atlassian’s automated backups via Amazon Relational Database Service (RDS). Data redundancy is great, but the company admits it can’t perform granular restores or rollbacks based on customer requests due to the data architecture. In other words: Those backups are for Atlassian’s disaster recovery plans, not yours.

You quickly find details about the shared responsibility model, which you already agreed to in procuring Jira Cloud. In the unlikely event of a critical incident—think meteorite falling on Jira Server’s primary data center—they’ll be able to recover from their most recent RDS backup, but that could be hours or days behind your organization’s latest updates.

Atlassian guarantees the availability of their Jira Cloud platform, not the security of your organization’s data—that’s up to you. Let’s walk through all the options for backing up and restoring your Jira Cloud data so you can actually consider your hard work done:

1. Manual Jira Cloud backups the ‘Atlassian way’
2. Automated Jira Cloud backups with unsupported scripts
3. Truly automated Jira Cloud backups with Rewind

At the end, we’ll also touch on the whole reason you’re backing up Jira Cloud in the first place: To restore it quickly during a data loss disaster.

1. Manual Jira Cloud backups the ‘Atlassian way’

In a few steps, you can export the contents of your organization’s Jira Cloud instance:

1. In Jira Cloud, using an account with administrative privileges, click Settings -> System.
2. Select Backup manager under IMPORT AND EXPORT.
3. Under Backup for cloud, click Create backup for cloud.
4. When the backup is ready, click Download backup file and save the file to your local workstation.

You now have a copy of your Jira data saved locally, but your IT instincts are unsettled: An export file, particularly in a .zip file, is not a legitimate backup solution. Why?

• The export process doesn’t include all your Jira Cloud data, like automation roles and settings around user access to the Jira Cloud platform.
  
• It also doesn’t include organization-wide data, like audit logs or managed accounts, which would be essential to restoring your Jira Cloud instance in case of a data loss incident.
  
• You can only export a full backup every 48 hours. This creates large gaps where Jira updates, like new tickets or valuable conversations between engineers about implementation details, are vulnerable to disappearing during a data loss incident, even if you can recover everything older than two days.
  
  Perhaps even more critically, someone from your organization must create an export file every 48 hours to prevent large gaps in your backups. Don’t forget to log in on weekends and holidays!
  
• You can only save the export file to your local workstation (or a networked on-premises storage if you’re lucky), which creates a dangerous single point of data recovery failure.

2. Automated Jira Cloud backups with unsupported scripts

In theory, you could mitigate a few of those flaws through automation, but unfortunately, Jira Cloud doesn’t have built-in support for automated backups. Atlassian employees say the issue is “under consideration” via their public feature request board, but progress has gone unchanged since 2021.

Instead, Atlassian provides two options for automation: as-is scripts you need to cobble together, or supported external partners like Rewind.

If you opt for the unsupported backup scripts, you can pick from PowerShell, Bash, and Python flavors, the latter two of which haven’t been updated since 2019. The bash script, for example, only queries the Atlassian API to download, with curl, a .zip file directly to your local workstation.

Even Atlassian employees say these scripts are “only good as a temporary workaround,” but any alternative to tedious and risk-prone manual exports is a good thing.

In the end, both of Atlassian’s built-in options leave you with extra IT burdens, like:

• Establishing a manual or (unsupported) automated process to create export files from Jira Cloud.
• Creating API keys and managing them appropriately to prevent leaks.
• Writing cron entries to run backup scripts on schedule.
• Provisioning VMs and storage in the cloud to send export files to prevent a single point of failure and letting more of your peers access backups during a data loss incident.
• Maintaining the export processes and data storage for changes to Jira Cloud’s architecture, deprecated API routes, and controlling your costs via pruning.

3. Truly automated Jira Cloud backups with Rewind

But when it comes to truly automated backups, Rewind is the only solution that lets you quickly back up and restore your Jira Cloud data, either in granular steps for those little mistakes or the full database in the event of a disaster.

While Rewind is a paid SaaS platform, it offers a full backup of your Jira Cloud instance(s) and helps you create a comprehensive business continuity plan with just a few clicks.

From Day 1 with Rewind, you have automated daily backups of your full Jira Cloud dataset with no configuration, local software installations, fussy scripts to customize, cloud provisioning, or new IT overhead. If you’re doing something risky with your Jira Cloud data and want extra assurance, such as installing new third-party apps or making broad changes to users and user group settings, you can create one-off snapshots with a single click.

As you weigh the pros and cons of your investment, take a moment to forecast the time you’ll spend setting up a comparable backup and restoration process yourself. Think critically about how much simpler your disaster recovery playbook becomes when you’ve gone from Bash scripts and cron entries to one-click daily snapshots. Calculate how much your time is worth! Your investment in Rewind will pay off much faster than going the bespoke (often fragile) route of building more IT infrastructure yourself.

Restoring Jira Cloud data from a backup

The complexity of the path to restoring your Jira Cloud data depends entirely on whether you’re using the built-in features or a supported partner like Rewind.

Using Jira Cloud’s integrated import feature

As with manual exports, Atlassian allows you to overwrite your entire Jira Cloud data with the contents of an export file:

1. In Jira Cloud, using an account with administrative privileges, click Settings -> System.
2. Under IMPORT AND EXPORT, select Import Jira Cloud and follow the steps.
3. Re-assign application access to new users.
4. Set permissions as needed.

This import process comes with a big caveat: You can’t import/restore only a specific project, which is helpful for recovering quickly from granular data loss incidents, and a feature Jira users have been asking about for nearly 10 years.

Atlassian also suggests you take a few additional steps to verify your export file’s file/folder structure by unzipping it before restoration. If your Jira backup file is more than a few gigabytes in size, you’ll also need to manually split it into multiple .zip files, maintaining a specific folder structure and then importing all of them one by one.

Handling export files yourself also dramatically increases the potential failure points of your restoration process. It’s not hard to imagine a UK employee, thinking the export file time-stamped 01022024 is from Feb. 1st, only to realize after overwriting your Jira Cloud database that it’s dated all the way back from January 2nd.

Rewind

Rewind’s process is as simple as selecting the relevant snapshot and whether you’re restoring a part or all of your Jira Cloud data. With Rewind, you can:

• Choose between granular or complete data restoration.
• Store up to 365 days of snapshot history covered by 256-bit encryption.
• Manage user access and real-time audit logs for compliance and audit-readiness.
• Handle the process entirely from a user-friendly GUI, instead of .zip files, with no costs associated with how much you back up.
• Reach out to email and chat support 7 days/week, with restoration assistance from Rewind data engineers if you need it.

Creating (and restoring from) truly automatic backups of your mission-critical SaaS data

We praise Atlassian for offering manual exports and imports. Not every SaaS platform does the same, and these files can be useful for analyzing how Atlassian stores your organization’s data (and what they store in the first place), porting your organization’s knowledge onto competitive platforms, and archiving history for governance or auditing purposes.

That said, they’ve clearly staked their backup and restoration support behind external partners like Rewind. They’re not just some third-party app in their catalog—they’re backed by Atlassian Ventures and received a 2022 award for Atlassian Partner of the Year: New Cloud App.

And if your organization relies on more than Jira Cloud keeping things running, Rewind just might be the perfect choice for those, too—not to make you panic,  but the same risks around the shared responsibility model and data security apply to all the SaaS platforms your organization relies on.

You can worry about all that tomorrow—Rewind can help with plenty beyond Jira Cloud, but for the time being, take solace. Put a big ✅ next to Jira Cloud data security on your endless TO-DO list. 

With your organization’s invaluable data protected, you’ll actually finish the onboarding or migration you’ve been poking at for months and get back to solving more interesting problems.