Atlassian Cloud backup: what Jira and Confluence actually save (and don't)

If you searched for Atlassian Cloud backup, you already suspect the built-in trash bin isn't enough. It isn't — and the reasons are specific, not generic FUD. This post walks through exactly what Jira Cloud and Confluence Cloud save natively, where that protection stops, and what an independent backup adds on top.

What Atlassian actually gives you

Atlassian's own admin documentation is candid about this, and it maps to two mechanisms:

1. The trash — which is not one window but several. Atlassian's trash rules differ by product and by what was deleted. A trashed Jira project keeps its work items, components, attachments and versions for 60 days before permanent deletion, and Jira or site admins can restore it (space admins can only trash and restore team-managed ones). A deleted Confluence space also gets 60 days — Atlassian began enforcing that automatic purge on 6 January 2025. Deleted Confluence pages behave differently again: they stay in the space trash with no published expiry, restorable until a space admin purges them. And Atlassian's project-trash documentation does not extend that safety net to individually deleted Jira work items — which, as the next section covers, is not an oversight but a documented gap. The practical lesson is that "the trash will have it" is not a single, dependable rule — see what a Confluence backup actually keeps for the full detail.

2. Manual backup via the Backup Manager. Both Jira and Confluence Cloud admin panels have a Backup Manager that lets an admin trigger a full-site export to a compressed XML file, downloaded once the job finishes. It's real, but it's manual, rate-limited and time-boxed: if you include attachments, avatars or logos you must "allow 48 hours between backups," and since 22 January 2026 Atlassian limits Backup Manager restores "to those that are 30 days old or less." A backup you took in the spring is not a restore option in the autumn.

Bitbucket Cloud, the third Atlassian product we're asked about most, has no admin-triggered full-backup equivalent at all. Atlassian's documented recovery procedure is literally to rebuild the repository from a local clone — which brings back commits and branches, but not the pull request history around them.

Jira backup: the export is not a restore path

This deserves its own section, because Jira is where the gap between "we have a backup" and "we can restore" is widest, and because Atlassian documents it more plainly than most vendors would.

There is no recycle bin for individually deleted work items. Atlassian's own knowledge base says there is "an ongoing feature request to implement a recycle bin-like component" (JRACLOUD-36415) — that is, it does not exist today. The 60-day trash applies to a deleted project, not to a work item somebody deleted out of one.

And a site backup will not give that item back. Atlassian states directly that "Atlassian backups can't restore individual deleted work items." The documented workaround is to restore the XML backup into a separate site, export the item from there, and re-import it as CSV — at which point it comes back with a different work item number, and every link, board reference and automation pointing at the old key is now pointing at nothing. Without a backup, Atlassian's suggestion is to reconstruct the item manually from the email notifications sent to its watchers, assignee and reporter.

Restoring a single project is not supported either. Atlassian is explicit: "You can't use this process to import a specific project while maintaining your existing site data." Importing a site backup "will erase all existing data and replace it with data from your backup." So the only documented use of the file you carefully generated is to roll the entire site back — destroying everything every other team created since the export was taken. For a single deleted project, that cure is worse than the disease, and most admins correctly refuse to use it.

Parts of Jira are not in the export at all. Atlassian's export documentation lists what a site backup excludes, and the list is longer than people expect: automation flows, third-party apps and their app data, app access settings, Assets for Jira Service Management, Opsgenie features, and Jira Product Discovery configurations. If your delivery process depends on a marketplace app — and most do — that app's data is not in the file.

Put together: the native Jira backup is a full-site, rate-limited, 30-day-expiring, all-or-nothing snapshot that excludes app data and cannot return a single work item or a single project. It is a disaster-recovery artefact for a total-loss scenario, not a recovery tool for the things that actually go wrong.

Where the native tools stop

Ransomware and slow-burn attacks. An attacker who compromises an Atlassian admin account doesn't need to touch your infrastructure — they can bulk-delete or bulk-edit projects and spaces from inside the product. If that activity sits undetected past the 60-day project and space windows (and patient attackers count on exactly that), the trash has already emptied by the time anyone notices. The 30-day restore limit on Backup Manager files narrows the same window further.

Bulk automation gone wrong. A misconfigured Jira automation rule can rewrite thousands of issues — custom fields, statuses, assignees — in minutes. Every change is made by an authorised account doing something "legitimate." The trash bin doesn't catch field-level overwrites at all; it only catches deletions. A bad Confluence macro or space-wide find-and-replace has the same blind spot.

Departing admins. When you deprovision a Jira or Confluence admin, the projects and spaces they owned don't disappear immediately — but their account-linked automations, dashboards, and permission schemes can, and reconstructing who had access to what after the fact is exactly the kind of forensic work a point-in-time backup makes trivial and a trash bin makes impossible.

Granular, tested restore. As the section above sets out, a Backup Manager export is all-or-nothing by design. There's no restoring a single project, a single space, or a single issue's history from that file without significant manual work and a second site to do it in. If a customer needs one Confluence page tree back, not your entire Confluence instance, the native tools weren't built for that request.

Compliance evidence. NIS2 and similar frameworks expect demonstrable, testable recovery capability — not "we could probably export it if asked." An occasional manual XML dump sitting in an admin's downloads folder is not an auditable backup process.

What this looks like in practice

A mid-size engineering org we'd typify: 40 Jira projects, a Confluence space per team, Bitbucket for source control. An automation script meant to close stale tickets in one project instead matched a broader JQL filter and transitioned 6,000 issues across 12 projects to "Done" overnight. Every transition was a legitimate, authenticated action — nothing for the trash bin to catch, because nothing was deleted. Reconstructing correct state meant manually re-opening issues from memory and a handful of email notifications. An independent backup with point-in-time, field-level restore turns that incident into a ten-minute rollback instead of a two-day forensic exercise.

What an independent Atlassian Cloud backup has to do

The pattern is the same one we describe in our SaaS shared responsibility model post: Atlassian is responsible for the platform staying up and your data surviving their hardware failures. Everything about your data's lifecycle — how long it's recoverable, at what granularity, and how you prove that to an auditor — is on you. It is the same division of labour behind every platform we cover, which is why the criteria for SaaS backup generally are the criteria here.

An independent backup for Atlassian Cloud should give you:

• Continuous, incremental capture of Jira issues, Confluence pages, and Bitbucket repositories — not a manual export someone has to remember to trigger inside a 48-hour rate limit
• Restore to any point in time, not just whatever the last export happened to catch inside its 30-day restore window
• Project- and space-level granularity — restore one project or one page tree without touching the rest of the instance, which is precisely what the native import cannot do
• Ransomware anomaly detection so a bulk-delete or bulk-edit event gets flagged while it's happening, not discovered once the trash windows have already closed
• Audit-grade restore logs for NIS2, ISO 27001, and GDPR conversations

We help you choose and deploy that layer — you keep ownership and control of the platform; we get you set up with guided onboarding so it's actually running, not sitting half-configured. See our full breakdown on the Atlassian Cloud backup and recovery page for what gets protected workload by workload.

If you're not sure whether your current Atlassian setup would survive a bulk-delete incident or a ransomware event that waits out the trash window, that's exactly what an assessment is for — a short, no-pressure look at your current exposure and what a proper backup would close.