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. 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, so it is not safe to assume one exists. 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: nobody runs it, remembers to run it on a schedule, or verifies the resulting file restores cleanly — until the day they need it and find out.

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.

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.

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. A Backup Manager export is all-or-nothing: the whole site, as one file, restorable (in most cases) only by raising a support ticket with Atlassian to import it back in. There's no restoring a single project, a single space, or a single issue's history from that file without significant manual work. 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 closes the gap

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.

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
• Restore to any point in time, not just whatever the last export happened to catch
• Project- and space-level granularity — restore one project or one page tree without touching the rest of the instance
• 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.