nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best practices for Jira Cloud backup, restore, and disaster recovery — what should we have in place?

Mahanth Prudhvi P

Hi all,

We're currently reviewing our Jira Cloud setup and want to make sure we're properly prepared for any unforeseen circumstances (accidental deletions, corrupted data, failed migrations, security incidents, etc.). I'd really appreciate input from anyone who has been through this or knows the right process.

Specifically, I'm trying to understand:

1. **Backup options**: What backup mechanisms does Atlassian provide natively for Jira Cloud (automatic backups, manual export, Backup Manager, etc.), and how frequently do they run? Are there retention limits I should know about?

2. **Restore process**: If we ever needed to restore data — a single project, a set of issues, or the whole site — what's the actual process? Can this be self-served, or does it require raising a request with Atlassian Support?

3. **Scope of restore**: Can restores be scoped (e.g., just one project or space) or is it always a full-site rollback? What are the tradeoffs?

4. **Preparedness**: What should we be doing proactively — scheduled exports, third-party backup apps from the Marketplace, documented runbooks — to be ready before something goes wrong, rather than scrambling after?

5. **Who to contact**: In an actual emergency (data loss, corruption, accidental bulk delete), who is the right point of contact — is it standard Atlassian Support, a dedicated Premium/Enterprise support channel, or something else depending on plan tier?

6. **Approach/escalation**: What information should we have ready when reaching out (timestamps, affected projects, screenshots, etc.) to speed up resolution? Are there SLAs we should expect based on plan (Free/Standard/Premium/Enterprise)?

7. **Testing**: Has anyone actually tested a restore end-to-end (not just relied on the theory)? Any lessons learned or gotchas worth flagging?

If anyone has documentation links, past experience with an actual incident, or a checklist your team follows, I'd be very grateful. Trying to get ahead of this rather than find out the hard way.

Thanks in advance!

Accepted answers

Florian Bonniec

Hi @Mahanth Prudhvi P

The Backup and restore option are not great on Atlassian Cloud. Also Atlassian backup do not include app Data (even Apps on Forge).

You may have to explore third party solution like:

Rewind Backups for Jira | Atlassian Marketplace

Revyz Command Center for Jira (Configuration Backup Optimiz) | Atlassian Marketplace

Regards

Marc -Devoteam-

Hi @Mahanth Prudhvi P

You have the manual backup opton, see https://support.atlassian.com/jira-cloud-administration/docs/export-issues

There is the paid option, https://support.atlassian.com/organization-administration/docs/overview-of-atlassian-backups/ (note; you need a premium or enterprise subscription)

Deleting is a permission in the System, best practice is to limit deleting permissions, as work items deleted, can't be restored. if you don't have a backup.

You would need to restore in another instance to not overwrite existing data, then export the needed data and import this back in.

Documentation on Data Management can be found here; https://www.atlassian.com/trust/security/data-management

James Gamble

Hola Mahanth,

The two existing answers highlight the key distinction: Atlassian’s platform-level disaster recovery protects the availability of Atlassian Cloud, but it shouldn’t be treated as a customer-accessible backup for accidental deletions, misconfigured automation, or unwanted bulk changes. For those customer-caused incidents, you need your own recoverable backup strategy.

Jira Cloud’s Backup Manager can create downloadable site exports that include work items, configuration, boards, sprints, comments, users, groups, and, optionally, attachments. It doesn’t include everything, though. Automation rules, Marketplace app data, Assets data, Opsgenie-powered operations data, and some other product-specific data aren’t included. Backups containing attachments can only be created every 48 hours, so this is useful for periodic exports but not for low-RPO disaster recovery. Atlassian documents the contents and limitations here.

Atlassian also now offers Atlassian Backup and Restore as a paid add-on for Jira Premium and Enterprise subscriptions. It supports one-time, daily, or weekly backup policies, stores backups for 30 days, and provides organization-admin restore controls. Marketplace app data still isn’t included.

The native restore model is important to understand before relying on it. Atlassian Backup and Restore restores into an empty Jira app in the same organization and region. It isn’t an in-place rollback of a live production site, and it doesn’t provide a simple “restore these three deleted work items” button. The target can’t contain active, archived, deleted, or trashed customer data.

For a small-scale deletion, the practical recovery pattern is usually to restore the backup into an empty temporary site or sandbox, validate the recovered data there, export the affected work items, and import them back into production. That process may restore the work item content, but it won’t necessarily recreate every relationship, history entry, app property, or integration exactly as it originally existed. Full-site recovery is more complete but has a much greater operational impact.

I’d build the runbook around your recovery objectives rather than around the existence of a backup button. Document which Jira data is business-critical, the maximum acceptable data loss, how quickly service must be restored, which app data needs separate protection, who can authorize a restore, where backups are stored, and how restored data will be validated. Restrict Delete work items and bulk-change permissions as well, since prevention is considerably cleaner than reconstruction.

Testing is essential. A backup that’s never been restored is only a hopeful zip file. At least annually, restore into a non-production target and verify work items, attachments, comments, boards, sprints, users, permissions, automation rules, integrations, and Marketplace app data. Record what’s missing and assign a separate recovery method for those gaps.

During an incident, contact Atlassian Support and open the case at the severity that matches the business impact. Include the site URL, affected projects and work item keys, the earliest known occurrence, suspected cause, exact timestamps and time zone, audit log evidence, screenshots, recent bulk changes or automation activity, and whether changes are still occurring. Premium and Enterprise provide enhanced support response targets, but the product availability SLA isn’t the same thing as a guaranteed recovery time for customer-deleted data.

Before choosing between Atlassian Backup and Restore and a Marketplace solution, compare restore granularity, app data coverage, retention, off-platform storage, immutable backups, recovery testing, and the ability to restore configuration and work items. Atlassian’s Backup and Restore overview is here.

Thanks,

James

All comments

Florian Bonniec

Hi @Mahanth Prudhvi P

The Backup and restore option are not great on Atlassian Cloud. Also Atlassian backup do not include app Data (even Apps on Forge).

You may have to explore third party solution like:

Rewind Backups for Jira | Atlassian Marketplace

Revyz Command Center for Jira (Configuration Backup Optimiz) | Atlassian Marketplace

Regards

Marc -Devoteam-

Hi @Mahanth Prudhvi P

You have the manual backup opton, see https://support.atlassian.com/jira-cloud-administration/docs/export-issues

There is the paid option, https://support.atlassian.com/organization-administration/docs/overview-of-atlassian-backups/ (note; you need a premium or enterprise subscription)

Deleting is a permission in the System, best practice is to limit deleting permissions, as work items deleted, can't be restored. if you don't have a backup.

You would need to restore in another instance to not overwrite existing data, then export the needed data and import this back in.

Documentation on Data Management can be found here; https://www.atlassian.com/trust/security/data-management

James Gamble

Hola Mahanth,

Thanks,

James

Mahanth Prudhvi P

Thanks @Florian Bonniec

That's helpful. I'll also evaluate backup options since app data coverage is important.

Mahanth Prudhvi P

Thanks @James Gamble This is very comprehensive and clarifies the recovery limitations and best practices. Really appreciate the detailed explanation.

Mahanth Prudhvi P

Thanks @Marc -Devoteam-

That clarifies the backup options, restore approach, and the importance of restricting delete permissions. Appreciate the guidance.

Alex Reinhart

@James Gamble thank you for this! Killer answer! When Atlassian released their Backup and Restore feature, they linked their documentation about what it is/ how it works. They did not provide any thorough insight as to how it differs from their (site-specific) Backup Manager. It's difficult to aid clients in their decision to go with one over the other when they don't create documentation comparing the two features.

Will

Disclosure up front: I work at ProBackup, a backup vendor on the Marketplace, so read point 5 with that in mind. Points 1–4 apply whether or not you ever touch a third-party app.

A few things worth having in place:

Scheduled site exports. Backup Manager in the admin console gives you a full-site export (CSV/JSON zip). Two catches: if you include attachments, you can only run it every 48 hours, and restoring means importing into a clean site. There is no way to pull a single project or work item out of it. Treat it as a last resort, not your recovery plan.
Atlassian Backup & Restore went GA this year. If you're on Premium or Enterprise it's worth evaluating: point-in-time backups with restore into the same site or a sandbox. It's an add-on purchase, and there are size limits, so check those against your instance before you rely on it.
Know what deletion actually means in Jira Cloud. Deleted projects sit in trash for 60 days. Deleted work items don't; there's no recycle bin for individual issues, so they're gone the moment someone deletes them unless a backup predates it. Most teams find this out during their first incident, which is the expensive way.
Test your restores. Pick a quarterly cadence, restore into a sandbox, and time the whole thing end to end. Your real RTO is whatever that exercise measures. A backup you've never restored from is a hope, not a plan.
If you need granular recovery, restoring one project or one deleted issue without touching the rest of the site, that's the gap Marketplace backup apps fill. They run scheduled API-based backups and do item-level restore. Ours is one of several; compare a few against your actual recovery scenarios.

Natalia_Kovalchuk_SaaSJet_

Hi Mahanth Prudhvi P ,

Great questions! I would probably approach Jira Cloud disaster recovery as a combination of Atlassian's native backup capabilities + a documented recovery process + work item history/recovery tools.

What is important is that "backup" and "recovery" should not be regarded as identical. It is useful to have a backup, but in many actual cases, such as an accidental bulk update, the deletion of work items, or incorrect field values, you may need to locate and recover only certain changes rather than restore the whole site.

1. Backup options

Backup Manager offers native backup and export facilities for Jira Cloud. Regular backups should definitely be included in the disaster recovery strategy, but one should not depend on them alone. It is also necessary to specify who is responsible for the backups, where the exports are kept, and for how long they are retained.

2. Restore process

With regard to site-level recovery, Atlassian's restore procedures apply. However, in the case of an accidental bulk update, restoring a large backup might be excessive and could have an impact on changes that were legitimately made afterward.

In such situations, it is usually advisable to first find out what changed, when, by whom, and what the earlier values were, before recovering only the data that was affected.

3. Scope of restore

The first thing it's worth asking is whether the entire site, the project, several work items, a deleted work item, or just the wrong field values need to be recovered.

Issue History for Jira (Work Item History) app by SaaSJet can be used together with Jira backups since it offers a detailed change history and enables you to restore deleted work items and undo unwanted field changes, including bulk changes. It doesn't replace Jira Cloud backups; instead, it offers a more detailed recovery option (restoring one or a few deleted work items without needing to restore a full site backup) and a bulk update revert option.

4. Preparedness

I’d create a recovery runbook covering:

backup frequency and ownership
storage and retention
recovery permissions
how affected data is identified
when to escalate to Atlassian

For audit or compliance purposes, Issue History for Jira app also allows historical data to be exported to Excel/CSV/PDF or accessed through API.

5. Who to contact

When there are infrastructure- or site-level recovery problems with Jira Cloud, Atlassian Support should be included in the escalation procedure, and I would also assign someone to assess whether the incident requires Atlassian's involvement or can be managed as an individual or bulk data recovery.

6. Approach / escalation

Before you get in touch with support, gather the projects or work items that are affected, the approximate time when the incident occurred, the users involved, any screenshots or errors, and the expected state that prevailed previously.

The detailed history of work items is very useful in this case since it shows who made the changes, when, and what the previous and new values were before you decide on the recovery method.

7. Testing

I'd definitely test the process end-to-end rather than only checking that a backup exists:

Incident → identify affected data → determine previous state → restore/revert → validate.

It's also a good idea to test typical situations: suppose a work item is deleted, or hundreds of work items are mistakenly bulk-edited; how quickly can they be identified and recovered?

In practice, I see these as two complementary layers:

Jira Cloud backups → broader disaster recovery
Issue History for Jira app capabilities → granular investigation and recovery

I have also prepared a detailed article on this subject specifically: "Jira Cloud Backups and Work Item History: A Complete Guide", in which I cover Jira backups, their limitations, and the way work item history can complement them.

I hope this helps you put together your process!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud