Jira Cloud backup: what Atlassian's native tools restore

Jira Cloud backup is the part of Atlassian's shared responsibility that teams tend to discover late, usually on the day they need it. Atlassian runs the infrastructure and keeps it available; what happens to your work items after somebody deletes them is your side of the line. The short answer is three facts from Atlassian's own documentation: a deleted project sits in trash for 60 days and can be restored, an individually deleted work item has no trash at all, and the full-site export expires after 30 days and can only be restored into an empty site. Each is reasonable on its own. Together they leave a hole exactly where day-to-day data loss happens.

What Jira Cloud keeps natively

Two mechanisms, operating at completely different levels.

Deleted projects go to trash. Atlassian's documentation is specific: "Spaces along with their work items, components, attachments, and versions will be available in trash for 60 days, after which they will be permanently deleted." (Atlassian's docs now use space for what most teams still call a Jira project.) During those 60 days the content sits in a half-state — it does not appear in search results, it remains reachable by direct link, and it cannot be edited.

Individually deleted work items do not. There is no recycle bin for a single deleted issue. A trash or recycle bin for work items has been an open feature request on Atlassian's own public tracker for years — JRACLOUD-36415 — and until it ships, deleting a work item in Jira Cloud is immediate and final. No undo, no 30-day window, no admin-only recovery path.

That asymmetry is the single most useful thing to understand about Jira Cloud backup, because it is the exact inverse of what people assume. The event that looks catastrophic — somebody deleted an entire project — is the recoverable one. The mundane event is the unrecoverable one: a developer tidying a board, an automation rule firing against a broader JQL filter than its author intended, a departing contractor clearing out "their" tickets, a bulk change applied to 300 work items instead of 30.

The Backup Manager export, and the 30-day clock

Atlassian's second mechanism is Backup Manager in the admin console, which produces a full-site export of your Jira data. It is genuinely useful and it is genuinely not an archive, for one documented reason: "A backup is stored for 30 days in Atlassian-owned storage, after which the backup expires and can't be restored." The same documentation states it from the other direction: "You have 30 days from the backup to restore your data from Atlassian storage."

So the native export is a rolling 30-day window. If a question arrives in October about what a Jira work item said in February — a customer dispute, an audit, an internal investigation, a contract argument about what was agreed and when — Backup Manager does not answer it. The copy that would have contained the answer expired seven months ago.

There is a second caveat worth reading carefully before you rely on an export as your recovery plan: "Not all data types are backed up and restored." The export is not a byte-for-byte image of your site, and the gaps tend to sit in the integration layer that teams build their process on top of.

Restores are all-or-nothing

This is where a Jira Cloud backup diverges hardest from what the word "backup" implies elsewhere in IT. Two documented constraints stack on top of each other.

The first is on the way in: "You can't back up specific projects or spaces. All projects and spaces will be included in your backup." There is no selective backup.

The second is on the way out, and it is the one that hurts. The destination site for a restore "should not contain any user-generated data. It can't contain active, deleted, or archived content." A restore goes into an empty Jira site — not into the one your company is using right now.

Follow that through to the thing you will actually want to do one day. To recover a single deleted work item from a native backup, you stand up a separate empty Jira site, restore the entire backup into it, go and find the item, and then re-create it in your live site by hand or via CSV import. What you cannot do — because the empty-destination rule forbids it — is merge the restored data back into production. For one ticket that is tedious. For the 300 that an automation rule quietly deleted last Tuesday, it is a project.

What this looks like in practice

Put the three facts together and the failure modes are easy to predict.

The routine deletion. Someone removes work items rather than a project. Trash never sees them, because trash only holds projects. If the deletion is older than your most recent export, there is nothing to go back to.

The question about the past. Compliance, a dispute, or a customer asks what a ticket contained a year ago. The 30-day export window cannot reach it, and Jira's own history will not help if the item itself was deleted.

The compromised admin. An attacker — or a disgruntled account holder — with project-delete rights operates at a speed the 60-day trash was designed to absorb, but the work-item deletions underneath it are permanent, and an export that is only ever 30 days deep may already contain the damage. Backup does not stop any of this from happening; it determines whether you can put the data back afterwards.

The departing team. Offboarding runs, permissions change, and a cleanup script does what cleanup scripts do.

If you want the Confluence and Bitbucket halves of the same picture, they have their own documented limits — the Confluence Cloud backup page trash behaves differently from Jira's, and Bitbucket's only documented recovery path is a git clone you made yourself. The native limits across Atlassian Cloud post covers how the three fit together.

What an independent Jira Cloud backup has to do

Judge any Jira Cloud backup against the specific gaps above, not against a feature list:

• Restore a single work item into your live site, with its comments, attachments and status — without an empty site and a CSV round-trip.
• Keep copies independent of the tenant, so an admin-level compromise or a mistaken bulk deletion in Jira does not also take the recovery copy.
• Retain beyond 30 and 60 days, to whatever your actual obligation is — and let you prove the retention, not just assert it.
• Cover Jira, Confluence and Bitbucket together, because a release process spans all three and a half-restored release process is not a restored one.
• Make the copy immutable, so it cannot be edited or deleted during its retention period. Immutable backup is a precise word with a precise meaning, and it is worth checking what a given implementation means by it.
• Be tested. A restore you have never performed is a hypothesis.

Most teams get this wrong in the same direction: they assume Atlassian's 60-day trash is the safety net, and never notice it does not cover the deletions they are statistically most likely to suffer.

Where to start

Start by checking what you would actually do if someone deleted 50 work items this morning. If the honest answer involves standing up a second Jira site, you have found the gap. We help you work out which backup approach fits your Atlassian footprint and get it deployed and verified — including the first test restore, so the recovery path is something you have done rather than something you own.

Take the free backup assessment and we will map your Jira Cloud recovery gaps against what your retention obligations actually require. More detail on what we cover is on the Atlassian Cloud platform page.