Confluence Backup Best Practices
Confluence is where teams keep operational knowledge: runbooks, architecture decisions, postmortems, HR policies, product specs, onboarding docs, and internal knowledge bases. Atlassian’s status pages show that disruption is not theoretical: on April 8, 2026, Atlassian reported search failures impacting multiple products, and on April 13, 2026, some users were unable to log in across Atlassian products.
Keep in mind that deleted items first go to trash, but once content is purged, the item, its versions, and its attachments are permanently gone. Even when you restore from trash, the content loses inherited permissions and comes back at the root of the space rather than its original place in the sidebar.
Moreover, it is crucial to adhere to Atlassian’s Shared Responsibility Model. That way, users get clear understanding of what the provider secures and what the users’ duties are. The gaps in the Shared Responsibility Model can lead to data loss and huge costs.
So, what should proper Confluence backup actually look like? This guide breaks down the Confluence backup best practices that matter in DevOps environments.
Part 1: backup performance
For Confluence, backup performance is not just about how fast a job finishes. It is about whether the backup covers the right data, runs often enough, stays restorable for long enough, and gives admins enough visibility to spot problems before any recovery is needed. Currently, Atlassian’s backup model is policy-based: you assign an app, choose included entities, and set a schedule. That makes coverage and recoverability the real starting point for the next section.
Make sure backup covers critical Confluence data
Atlassian’s Confluence backup scope covers the core layers most teams actually rely on, including spaces, pages and blogs, attachments, comments, content history, and a range of site and space-level settings. It also extends beyond standard page content to newer Confluence objects such as whiteboards, databases, folders, and Team Calendars. In practice, that means backup coverage can include both the knowledge itself and much of the structure around it, from permissions and templates to audit and configuration data.
Still, that scope is not complete. Atlassian explicitly excludes some Confluence data from backup and restore, including analytics data, space shortcuts, related pages settings, reactions, custom emojis, public links, user avatars, and passwords. That is why one of the first Confluence backup best practices is to compare what your teams actually rely on with what the backup system truly protects, rather than assuming all Confluence data is covered by default.
Define backup scope before choosing a tool
Tool selection should come after scope definition, not before it. Atlassian states that only the items listed in its support tables are backed up and restored, which means backup planning starts with a recovery checklist: spaces, page trees, comments, attachments, history, settings, and anything else your teams would need to recover to keep working. If a required data type is missing from the supported-entities table, it is outside native protection.
This matters even more if your Confluence environment depends on apps. Atlassian says Atlassian Backup and Restore does not support Marketplace app data. It also matters at the commercial level: Atlassian’s Backup and Restore add-on is not available for Free or Standard plans; for Confluence, it is available with Premium and Enterprise.
Adjust backup frequency and schedule
Backup frequency should be based on how fast important Confluence content changes, not on habit. Atlassian recommends scheduling backups daily or weekly, and its current policy model supports one-time, daily, and weekly backups for production sites. Sandboxes are more limited: they support one-time backups only and do not offer recurring daily or weekly schedules.
Atlassian defines RPO as the amount of data an organization can afford to lose based on backup frequency. While Atlassian currently lists a 24-hour RPO for Confluence Backup and Restore under stated size limits, each organization still needs to assess whether the native backup cadence matches its own recovery requirements.
There is another operational constraint teams should not ignore: Atlassian assigns the backup run time after you choose the date, because it restricts concurrent backups and restores, so you cannot freely choose the exact time slot yourself. Atlassian also notes that if the user who scheduled the backup later loses either organization admin or app admin permissions, the backup will not run again until a qualified admin updates the policy. That means backup scheduling in Confluence is not just a checkbox; it is part of your actual RPO discipline.
Retention and restore window
Native retention is currently hard-limited. Atlassian states that each backup is stored for 30 days in Atlassian-owned storage, after which it expires and cannot be restored. Atlassian also states that you can restore only backups taken within the last 30 days.
That has a direct consequence for Confluence backup strategy: the native restore window is suitable for obvious incidents discovered quickly, but weak for delayed discovery cases such as slow content corruption, late-found deletions, or audit-driven lookbacks months later. That is not a guess; it follows directly from the 30-day restore limit.
Backup health visibility and central monitoring
Atlassian’s backup details view exposes the backup ID, status, start and end time, size, encryption status, included data, region, whether attachments and users or groups were selected, who initiated the backup, and the total time taken. Atlassian also lets admins download a report summarizing what was backed up and what was not. That is the minimum raw material needed for backup health checks and centralized oversight.
Restore visibility also matters in DevOps. Atlassian says organization admins receive emails when a restore starts and completes, and that restore details are visible from the Restore tab on the Backups home page, where admins can assess backup health. In practice, that means Confluence backup monitoring should cover both sides of the process: backup execution and restore readiness.
Exports compared to real backup
Exports still have value, but they are not the same thing as a managed backup strategy. Atlassian’s Confluence Cloud backup manager can create a copy of all content in a Confluence Cloud instance, and Atlassian says that file can be saved as a way of taking occasional offline backups. Atlassian also supports exporting individual pages or spaces in multiple formats.
The weakness is that exports are still just export artifacts. Atlassian says space exports currently cannot export databases with their content, data, or functionality. Atlassian also says that backups from Atlassian Backup and Restore cannot currently be downloaded into your own storage. So exports may help with offline copies, migration work, or one-off preservation, but they are not a substitute for monitored, policy-based backup with repeatable restoreability.
Part 2: backup security
In DevOps, Confluence backups should be treated as sensitive data in their own right. A backup can contain the same operational knowledge that lives in production Confluence: documentation, internal procedures, architectural notes, and other content that should not be casually exposed. Atlassian also warns that Confluence features such as export and public links can create data-loss risk if they are not governed properly, which is exactly why backup security deserves its own section rather than being treated as an afterthought.
Protect backup data with encryption and key control
DevOps environments require encryption to be the baseline, not a premium extra. Atlassian states that default encryption is automatically applied to data within Atlassian apps using Atlassian-managed keys. Atlassian also supports customer-managed keys, and if an organization is enrolled in the CMK encryption policy, backups stored in Atlassian storage are encrypted with those customer-managed keys. In other words, backup security is not only about whether backups are encrypted, but also about who controls the keys that protect them.
This is also where key management becomes operationally important. Atlassian says that backups are protected with the active encryption keys in use at the time of backup, that old backups are not re-encrypted when apps are re-encrypted, and that backups encrypted with revoked or old keys can become inaccessible. That means encryption improves control, but it also creates a responsibility: if key lifecycle management is sloppy, recovery can fail even when the backup itself exists.
Limit backup and restore access as tightly as possible
Least privilege matters because backup access is powerful access. Atlassian’s current native requirement is not very granular: to back up and restore Confluence data, a user must have both Organization Admin permissions at the Atlassian organization level and Confluence product admin permissions for the relevant Confluence app/site. That makes the practical rule simple: keep the number of people with both permissions as small as possible, and review that access regularly. If a team needs finer separation of duties, that should become a selection criterion when evaluating third-party backup tooling, because Atlassian’s native backup permissions are currently admin-heavy rather than backup-specific.
Strengthen authentication with SSO and MFA
Authentication controls belong in backup security because compromised identities often become the fastest route to data loss. Atlassian supports configuring and enforcing SAML single sign-on through authentication policies, and it supports enforcing two-step verification for managed accounts as well. Atlassian also notes that if single sign-on is enforced, two-step verification is configured in the identity provider rather than directly through the Atlassian authentication policy.
There is also a useful policy angle here. Atlassian’s authentication policies allow different security settings for different user groups, and Atlassian Guard Standard is required to create more than one authentication policy and apply SSO, advanced session controls, and related settings across different user sets. That matters because in DevOps, backup access should not inherit the same loose authentication posture as ordinary day-to-day users. Administrative accounts, service accounts, and high-sensitivity users should not all be treated the same.
Address backup isolation and independent copy logic
A secure backup strategy should not depend entirely on the same environment it is supposed to protect. Atlassian’s native Backup and Restore stores backups in Atlassian-owned storage for 30 days, and Atlassian currently says those backups cannot be downloaded into your own storage. Atlassian also notes that using Amazon S3 for storing backups is no longer available except for customers who used it in the past. That means native backups can be useful, but they are not the same thing as an independently controlled copy outside the source SaaS boundary.
That matters for security because isolation limits blast radius. If the same provider hosts production and the only native backup copy, organizations with stricter resilience or compliance requirements may still want an additional independent backup path. The point is not to dismiss Atlassian’s native backups; it is to recognize that “backed up” and “independently recoverable” are not identical security states.
Ransomware resilience starts with controlled access and recoverability
For Confluence, ransomware resilience is less about dramatic malware terminology and more about reducing the ways a compromised account or security event can block recovery. Atlassian’s CMK documentation makes that clear: when keys are revoked, backups encrypted with those keys become unavailable for restoration, and future backups do not proceed because the encrypted cloud sites are deactivated. In practical terms, secure backup design has to consider not just storage, but also access controls, authentication controls, and key continuity.
Account for compliance and data residency requirements
Compliance-sensitive teams should verify where backup data is stored, not just where production data lives. Atlassian states that Atlassian Backup and Restore supports data residency starting from April 28, 2026. When data residency is enabled for an Atlassian app, new backups created with Atlassian Backup and Restore are stored in the same region as the app’s pinned location. Atlassian also notes that backups created before the app was pinned are not moved to the new region automatically and remain where they were stored at the time the backup was taken.
That means backup residency should be validated as part of compliance review, especially in regulated environments. It also means teams should be careful with app ecosystems: Atlassian explicitly says Marketplace app data is not included in Atlassian Backup and Restore, and Marketplace app residency should be checked with the app vendor rather than assumed.
Preserve visibility and auditability
A secure backup system should leave evidence. Atlassian’s backup details view shows the backup status, size, encryption model, included data, region, initiator, and total time taken, and admins can download a report showing what was backed up and what was not. That kind of visibility is not just operationally useful; it is part of the security story because it helps prove what happened and what was protected.
For broader oversight, Atlassian’s audit log tracks key activities across the organization and can be used to diagnose issues and answer questions related to organization and app administration, user and group management, and troubleshooting. The exact activity coverage depends on the subscription plan, but the principle stands: backup security is stronger when administrative actions are visible, reviewable, and attributable.
Part 3: disaster recovery
In DevOps, especially Confluence, disaster recovery should be judged by one standard: when content is lost, damaged, or made unavailable, can you bring it back in a controlled way without creating a second incident? Atlassian’s current native restore model can only restore backups taken within the last 30 days, and restores target empty apps inside the same organization rather than live, populated environments.
Point-in-time recovery is limited to available backup points
For Confluence, “point-in-time recovery” should be described carefully. Atlassian Backup and Restore lets admins select a specific backup from the available list and restore from that backup, but only if it was taken within the last 30 days. In other words, recovery is tied to discrete backup points, not to an arbitrary timestamp chosen on demand. That distinction matters, because teams often hear “point in time” and assume fine-grained rollback when what they really have is restore-from-selected-backup behavior within a 30-day window.
Set realistic expectations for page, attachment, space, and site recovery
Recovery expectations also need to stay grounded in what Atlassian actually supports. Atlassian says you can’t back up specific spaces, and that granular controls on all data types are not available, although you can choose to include or exclude personal spaces and attachments when you back up. During restore, if the backup includes attachments, users and groups, or personal spaces, you can choose whether to restore those components. That is useful, but it is not the same thing as full page-level or space-level selective restore inside a live Confluence environment.
There is also a quality caveat. Atlassian recommends restoring only complete backups. Incomplete backups can still be restored, but for Confluence they may be missing some spaces. So recovery planning should assume that backup completeness matters directly to what you can recover later.
Native restore is designed for a clean target, not for restoring over live data
This is one of the most important Confluence DR constraints. Atlassian says backups can only be restored to apps that are empty and contain no user-generated data, and recommends restoring to a newly provisioned app. For Confluence specifically, that means deleting all spaces, including personal spaces, and permanently removing them from trash before restore. Atlassian’s FAQ goes even further: the target app cannot contain active, deleted, or archived content, and for newly provisioned Confluence apps the default personal space must be deleted too.
That means native Confluence recovery is not an in-place, non-destructive rollback of a live knowledge base. It is closer to restore-into-clean-target recovery. If your recovery strategy assumes you can simply drop lost content back into an already active Confluence app without clearing the destination first, that assumption is wrong.
Recovering after accidental deletion or purge
In Confluence, when an item is deleted, it moves to the space’s trash and can be restored until it is purged. But once it is restored from trash, it loses inherited permissions and is restored to the root of the space rather than to its previous place in the sidebar. If an item is purged from trash, the item, all its versions, and its attachments are permanently deleted.
That means Confluence has two very different recovery layers. The first is operational convenience: trash restore for recently deleted content. The second is actual disaster recovery: backup restore after content has been purged, after a space has been broadly damaged, or after the loss goes beyond what the trash can fix. For DR planning, that distinction should be made explicit so teams do not confuse short-term content recovery with full backup-based restoration.
Restoring to another environment or clean target
Native restore does support recovery to another target, but with strict boundaries. Atlassian says you can restore any backup into an empty sandbox, and more broadly you can restore only into apps that are available in the same organization. Atlassian also recommends newly provisioned apps for restore. That makes sandbox or spare-app recovery useful for validation and controlled recovery, but it is still not the same thing as restoring wherever you want or exporting data back into infrastructure you fully control.
Atlassian documents that backup and restore are shard-aware: restores are supported to app instances in the same shard and region, and if the destination app is on a different shard, Atlassian may need to move it first, which can take around 30 minutes. That is not necessarily a blocker, but it is part of the real recovery path and should not be ignored when estimating restore time.
Test restores regularly, not just backups
A backup job completing is not proof that recovery will work. Atlassian’s current health-check model includes automated restores: when enabled, Atlassian creates a secure, isolated sandbox, restores backups into it, generates a report, and then deletes the sandbox. The frequency of automated restores is generally set to occur on a weekly basis, and they do not affect manual restores because they happen in separate sandbox environments.
That makes restore testing one of the strongest DR practices for Confluence. It shifts backup validation from “the job ran” to “the data could actually be restored.” For a knowledge platform, that difference is everything.
Plan for provider outage, admin error, and malicious deletion
Disaster recovery planning should also be scenario-based. Atlassian explicitly frames backups as protection against data-loss events such as accidental deletion, software corruption, and security breaches. For Confluence, common scenarios include an admin deleting the wrong space, a malicious or compromised account removing content, or a provider-side issue that makes normal access unavailable. In those cases, what matters is not whether Confluence usually works, but whether your restore path is fast, tested, and realistic under Atlassian’s current restore restrictions.
👉 Before you go:
