Confluence backup: what Atlassian Cloud actually keeps

If you searched for Confluence backup, you are probably trying to work out whether Confluence Cloud already protects you. The short answer: it holds deleted pages longer than most people assume, but its only native backup tool is a whole-site export that stores one copy at a time, expires after 14 days, and overwrites everything when you restore it. That combination — a generous deletion safety net attached to a blunt recovery tool — is where most Confluence data loss actually happens.

This post covers what Confluence Cloud retains on its own, what the Backup Manager does and does not capture, and what an independent copy adds on top.

What Confluence Cloud keeps natively

The page trash has no published expiry

When you delete a page, blog post or attachment in Confluence Cloud, it moves to that space's trash. Atlassian's documentation is explicit that the item "isn't permanently deleted and can be restored, until or unless it is manually purged from the trash." There is no published countdown on individual content items — they sit in the trash until somebody purges them.

That is more forgiving than the 30-day recycle bins people carry over from other SaaS products. Two catches matter, though:

• Restoring and purging are space-admin actions. A regular user with delete permission can send a page to the trash but cannot pull it back themselves — they need a space admin to do it.
• Purging is final. Purging an item removes it along with all its versions and attachments, permanently. One admin doing a well-intentioned "Purge All" tidy-up ends the safety net for that space in a single click.

Deleted spaces get 60 days

Spaces behave differently from pages. A deleted space moves to the trash and is permanently deleted after 60 days — Atlassian began enforcing that automatic purge on 6 January 2025. Only a Confluence admin can restore a trashed space or delete it permanently, and a trashed space's space key cannot be reused until the space is permanently gone.

So the safety net around the single largest unit of Confluence content — an entire team's space, with every page in it — is a hard 60-day clock, not the open-ended window that applies to individual pages. It is worth checking Confluence administration → Data management → Trashed spaces occasionally, because that list is the only place a 59-day-old mistake is still visible.

Page version history

Confluence keeps a version history for each page, so an edit that mangles a page can be rolled back to an earlier version without touching the trash at all. That is the right tool for "someone overwrote this page", and it is worth knowing it exists before reaching for anything heavier. It does nothing for you when the page itself, or the space around it, is gone.

What a native Confluence backup actually captures

The Backup Manager in the Confluence Cloud admin panel is the only native, admin-triggered Confluence backup. It produces a single full-site export file. Atlassian lists what goes in:

• Pages, with their classification status
• Whiteboards
• Space default classification levels
• User and group permissions
• Team calendar data
• Attachments — optional, ticked at backup time

The exclusions matter more than the inclusions:

• Databases are not exported. Atlassian states plainly that it can't currently export databases: they still appear in the page tree of a restored site, but they lose their content, data and functionality.
• Attachments are opt-in. A backup taken without ticking "Backup attachments" contains none of your files. When they are included, the export covers all attachments — including those sitting in the archive or the trash — so the resulting file can be considerably larger than your reported storage usage.

Three operational limits are worth planning around. A Confluence Cloud backup file can be up to 30 GB in total size, plus 800 GB of attachments. The download link stays available for 14 days. And Confluence keeps one backup at a time — any existing backup is overwritten by the new one.

Where the native model breaks

The restore is whole-site and destructive. A Backup Manager file can be restored into another Confluence Cloud site, where it will overwrite all the content on that site, or into Confluence Data Center 6.0 or later. There is no supported path to lift one space, one page tree, or one page's history out of that file and drop it back into your live instance. If the request is "restore the platform team's space to how it looked last Tuesday", the native tooling has no answer that doesn't involve standing up a whole separate site and copying content back by hand.

One copy is not a history. Because each new export overwrites the last and the download link expires after 14 days, the native model gives you at best a single point in time — and only if somebody remembered to download the file before it expired. Ransomware and slow-burn insider damage are exactly the cases where you need the copy from before the incident, which is often weeks earlier.

Atlassian's own backups are not your backups. The Cloud service takes backups of your instance every 24 hours, but those exist for application recovery on Atlassian's side. They cannot be used to roll your application data back to an earlier state. Reading "Atlassian backs up the cloud" as "our Confluence content is backed up" is a common and expensive mistake.

Nothing native detects a bad change. The trash catches deletions. It does not catch a macro or a space-wide find-and-replace rewriting hundreds of pages, because nothing was deleted — every edit was made by an authorised account doing something the product considers legitimate. Version history holds the truth page by page, but nobody is going to walk 400 pages back one version at a time.

This is the same split we describe across Atlassian Cloud's native backup limits and, more sharply still, in what a Bitbucket backup misses: Atlassian keeps the platform running and survives its own hardware failures. The lifecycle of your content — how far back it stays recoverable, at what granularity, and how you evidence that to an auditor — sits with you.

What an independent Confluence backup adds

An independent copy of Confluence Cloud should give you the things the export cannot:

• Scheduled, incremental capture of pages, spaces, attachments and permissions — not a manual export somebody has to remember to trigger and download inside 14 days
• Point-in-time restore, so you can ask for last Tuesday rather than whatever the last export happened to catch
• Space- and page-tree granularity, restoring one team's space without overwriting the rest of the instance
• Anomaly detection so a bulk-delete or mass-edit event is flagged while it is happening, rather than discovered when someone opens a page months later
• Audit-grade restore logs for the recovery evidence that NIS2 expects of SaaS data, and for ISO 27001 and GDPR conversations

We help you choose and deploy that layer and get it running properly — you own and run the platform, we make sure the setup actually fits your Atlassian estate. Our Atlassian Cloud backup and recovery page breaks down what gets protected workload by workload.

Where to start

If you are not sure whether your Confluence instance would survive a purged space, a runaway macro, or a ransomware event that outlasts a 60-day trash window, that is exactly what an assessment is for — a short, practical look at your current exposure and what an independent copy would close.