nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Atlassian's New Backup and Restore Experience is now in Open Beta

Lakshmi Behl

UPDATE: Please see our new automated restore capability post here

Hello everyone,

I am Lakshmi Manasi Behl, Senior Product Manager for Atlassian’s Backup and Restore capabilities. I'm thrilled to announce that our new backup and restore experience will transition from a closed to an open beta! We're kicking off this transition in the 2^nd week of June and wrapping it up by the end of the month.

If you've got an Enterprise plan for any of these apps—Jira*, Confluence, or Jira Service Management—you'll be part of our open beta. No need to lift a finger; you'll be auto-enrolled and ready to enjoy all the new features. Plus, you'll be able to back up and restore app data across all your organization’s sites, for Jira, Confluence, Jira Service Management, and Jira product Discovery, not just the ones on Enterprise plans.

_{*All Jira family apps, i.e., Jira, Jira Service Management, and Jira Product Discovery will be backed up together they cannot be backed up individually.}

Want to try it out?

If you have org admin permissions, it’s easy to try out the new backup and restore experience. Just go to http://admin.atlassian.com/ > the Settings tab at the top > and then Backup and restore tab on the left panel. We strongly encourage you to test backing up your app data AND restoring your app data from backup as part of your participation in the open beta.

What problem are we solving for?

Our main goal is to empower you to effectively respond to customer-owned disasters and further assist you in meeting your compliance requirements, helping ensure seamless business continuity. Atlassian will continue to implement the necessary strategies to address Atlassian-owned disasters as part of our shared responsibility model.

What is our backup and restore solution?

Our new backup and restore experience is designed to make protecting your Atlassian app data both straightforward and secure. It offers all the capabilities needed to back up and restore your data in case of a customer-owned disaster, like accidental deletion, ensuring compliance with internal and regulatory requirements. The goal is to provide you with peace of mind, knowing your critical information is safe even in the event of a catastrophe.

How does it work?

You can define backup policies, which are rules to protect your Atlassian app data. These policies specify what data to back up, how frequently to perform backups, and where to store them. Here are the key aspects of a backup policy:

Data Selection: You can decide which apps and data to back up, such as attachments or personal spaces.
Scheduling: You can determine when and how often backups should occur. This can be daily, weekly, or on-demand.
Storage Location: You can choose where to store the backups, such as in Atlassian storage or an organization's Amazon S3 bucket.

What can you expect from the open beta?

Features	Description
Data Backup	Atlassian app data can be backed up daily, which means a 24-hour Recovery Point Object (RPO).
Data Recovery	You can restore from a backup in less than or equal to 12 hours, which means a 12 Hr Recovery Time Objective (RTO). You can restore to a new site from a backup for up to 30 days from when the backup was taken.
Data Storage	Backups can be stored in Atlassian Storage for up to 14 days. Backups can be stored in your AWS S3 storage for as long as you wish. However, backups expire and cannot be restored from after 30 days.
Audit-ability	Proof of backup via the Admin Hub dashboard or Audit Logs.
Compliance	Works with Commercial and FedRAMP sites. Works with Bring Your Own Key (BYOK) or Customer-managed Keys (CMK) encryption for both Atlassian internal storage and your AWS S3 storage
User Experience	Backups can be scheduled via the UI You will have access to backup and restore APIs to make programmatic calls to the Atlassian Backup & Restore experience.

For additional details on the specifics of how backup and restore works please see

Manage backup and restore for Atlassian products | Atlassian Support.

Performance Expectations and Guardrails during Open Beta

During the open beta, most customers can expect an RPO of 24 hours and an RTO of 12 hours. However, we have implemented certain guardrails to manage performance during the open beta for customers who exceed the below:

App \| Guardrail	Recovery Point Objective (GB)	Recovery Time Objective (GB)
Jira Apps	240 GB	60 GB
Jira Attachments	12 TB	3.5 TB
Confluence	120 GB	30 GB
Confluence Attachments	12 TB	12 TB

These guardrails are designed to ensure that the system remains responsive and that all users can benefit from stable performance. If you exceed a guardrail you are not prevented from using the back and restore capability however, you may experience times over the above RPO and RTO. However, if you are performing a restore in above the guardrails we recommend reaching out to Atlassian Support.

What’s next?

As we approach general availability, we're dedicated to refining the open beta experience by integrating your feedback. Currently, access to the open beta is limited to customers with an enterprise plan, but we're exploring bringing the new backup and restore experience as a paid offering to all customers at GA. We'll provide specific pricing details as soon as they're available. Stay tuned!

Cheers,

Lakshmi Manasi Behl

Additional Resources:

Comments

Lori Brown

Is the paid functionality around being able to do this kind of backup at all, or for the space used (if we're not using an S3 bucket)?

Lakshmi Behl

Hello @Lori Brown , yes it will be able to

Rune Rasmussen

Will this new backup solution really only be available for Enterprise customers?
Or am I reading this wrong?

Antoine _Klee Group_

Still cannot see

Sami Shaik

Thank you, @Lakshmi Behl , for this detailed and exciting announcement. The new backup and restore experience, especially with support for AWS S3 and BYOK/CMK encryption, is a great leap forward in data protection and compliance readiness.

I had a quick question regarding storage options:

👉 If an organization is on Jira Cloud Enterprise, JSM Premium, and Confluence Premium, do they still qualify for storing backups in Atlassian Cloud’s unlimited storage, or would they require an AWS S3 bucket configuration to retain backups beyond the 14-day window?

Looking forward to your clarification to better advise teams on storage strategy and retention planning.

Thanks again for the great work and transparency around performance guardrails and future roadmap!

Branimir Kain

@Rune Rasmussen RE: "Will this new backup solution really only be available for Enterprise customers? Or am I reading this wrong?" The Open Beta of the new backup and restore experience is only available to customers with at least one Enterprise plan. No decision has been made on who it'll be available to for purchase at GA. We're still exploring that.

Branimir Kain

@Sami Shaik, this is currently separate from the app plan storage limits. Since this is an Open Beta, we're still exploring how this will be packaged at GA.

However, during this Open Beta, if you're within the guardrails and qualify for the Open Beta, i.e., have a CEE plan, you can backup your app data into Atlassian cloud storage. If you want to retain those backups for more than 14 days, you'll need to bring them into an S3 bucket.

I will call out this from the table above: "Backups can be stored in your AWS S3 storage for as long as you wish. However, backups expire and can't be restored from after 30 days."

Dirk Ronsmans

@Branimir Kain I strongly advice/plea to at least look at adding Premium customers to these plans or to have it as a separate product to purchase.

Oliver Siebenmarck {Polymetis Apps}

Wow, that's a big new feature! Will the backups include the data from any installed Runs-on-Atlassian apps?

Nicolas Esteves

Hi @Branimir Kain

I agree with @Dirk Ronsmans , this is a crucial feature that shouldn’t be limited to Enterprise customers. It’s something all Cloud users would benefit from. If it's not possible to extend it universally, it should at least be available to Premium plan users.

Thank you for considering this.

Kind regards,

Italo _Modus Create_

Are Automations included in this backup?

Darrel Jackson

Very surprised this is not being offered to Premium customers. When do we get a definitive answer on whether Premium will be supported or not?

Andy _ Fun Inc

@Lakshmi Behl - if we use this from now on, do we no longer require our app add-on from marketplace???

Alexander Tam

Where can I find and review old backup policies created?

Paul Stahlke

Will it be possible to recover or view a single issue if it is accidentally deleted?

Branimir Kain

@Italo _Modus Create_ automations are not currently included in the backup; however, it is something we're currently exploring, so stay tuned.

Branimir Kain

@Darrel Jackson, no definitive timeline on when I'll be able to share; however, we're actively working on what this will look like for General Availability and for whom it'll be available.

Branimir Kain

@Andy _ Fun Inc, that depends completely on your organization and your use case. Our Marketplace Partners provide some very powerful solutions that may be better suited to meet your needs.

Branimir Kain

@Paul Stahlke, today, the new backup and restore experience restores your entire site. So, in theory, you could restore the entire site to access a single issue. However, I suspect you're looking for a partial restore functionality, which we don't offer today.

Branimir Kain

@Alexander Tam you should be able to see all the backup policies you've created in the new backup and restore experience right on the main screen where your backup policies are. Screenshot 2025-07-03 at 5.52.15 PM.png

Sami Shaik

We have been actively using the new Backup and Restore experience for the past 20 days, and I must say this is truly a must-have feature for every admin managing Jira Cloud.

The setup is straightforward — configure it once, and you can relax knowing your data is being handled efficiently. Throughout our usage, we haven’t encountered any performance issues or slowness, which is impressive given the critical nature of backup operations.

That said, I would still recommend making it a best practice to check the status of your backups at least once a day to ensure everything is running smoothly.

Kudos to the Atlassian team for bringing this much-needed feature to life! 👏

Alexander Tam

How do I rename a backup policy?

How do I delete a backup policy?

David Pezet_yyhi7z

@Branimir Kain @Lakshmi Behl Regarding the note "Backups can be stored in your AWS S3 storage for as long as you wish. However, backups expire and cannot be restored from after 30 days." Are there any options for restoring or otherwise importing information from organization AWS S3 backups older than 30 days?

thbrandstaetter

@Branimir Kain I would also like to know how to rename a policy, because I can also not find a way to delete a policy?
Deactivating a policy is also only achieved by removing the schedule, correct?

Branimir Kain

@David Pezet at the moment no. The backups themselves are only restorable for up to 30 days. But I'd like to understand your use-case if you don't mind sharing here or you can email me at bkain@atlassian.com. We're currently exploring some enhancements that might solve for some compliance and internal IT reporting requirements and wondering if your use-case is similar to that.

Branimir Kain

@thbrandstaetter @Alexander Tam as of today you're not able to delete or rename backup policies. You can only edit the following attributes of a backup policy:

Included/excluded entities (e.g., attachments, personal spaces)
Backup schedule (edit or remove)
Storage location (switch between Atlassian-owned or your own S3 storage)

RE: Naming we're going to explore this further. At a minimum we're going to improve some of our documentation to let folks know that as of right now you can't rename and therefore you should probably have some type of standard naming convention for your policies. I'll also bring back renaming as a capability to our team for exploration.

David Pezet_yyhi7z

@Branimir Kain The most immediate concern is an issue not being recognized within the 30 day period. Not all data is accessed on a regular basis, and should something be discovered as "missing" or "broken" at a later date it would be nice to have a way to recover specific projects/spaces/configurations.

Another scenario we are looking at is being able to delete specific projects/spaces that have been archived for an extended periods of time. This would help keep size down, as well as simplify management. Also, Jira configurations cannot be deleted for archived projects, so we are forced to keep all applicable configurations and their associated issue types etc. We would like to be able to clean this up, but also recover if ever necessary without having to rebuild from scratch.

David Pezet_yyhi7z

@Branimir Kain Additionally, some organizations have data retention policies that can extend for years. Backups allow for them to more freely delete to keep things clean/organized, while still meeting these policies. If the data is not recoverable or recovery testable, it becomes highly debated whether the policy is being achieved (i.e., yes the data is there, but extremely difficult to work with).

Branimir Kain

@David Pezet yup, this all tracks and makes sense. I think the first thing to note is that we haven't gotten to the point of enabling selective restore. Right now, these restores are for your entire site, but if we support something like that in the future, I think what you're looking for makes sense. Not to get too deep into the specifics, but the gist of why it's 30 days is that last month's Jira is not necessarily this month's Jira, and the rate at which change and innovation occur in our cloud product and without "versions" to peg backups to there's a balance we need to meet for how far back do we require every system to be compatible.

RE: Compliance/Audit: Definitely. I've talked to a lot of customers, and it really depends. Some customers just need proof that the backup was taken, while others need to be able to see the data effectively, a human-readable backup. It's not something we have a date for, but it's a problem we've been discussing with customers to understand what information needs to be surfaced outside of providing an interactive version of the app that mirrors what it looked like at the time the backup was taken.

RE: De-bloating/clean-up is definitely really interesting. It's effectively this idea of long-term cold storage, where you'd like to remove unused product data to improve the overall cleanliness/performance of your organization's products. But obviously impacted by both of my responses above.

Appreciate the candor and I'll be sharing this more with the team. You've got my email and I'd definitely watch this post hoping to have some updates in the coming quarters!

Michael

@Branimir Kain @Lakshmi Behl This looks amazing definitely a much anticipated feature!

Just wondering, will this be available for premium customers? If not, is there a way to have it enabled on a premium instance

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

atlassian-backup-and-restore

atlassian-open-beta

cloud-data-protection

backup-policies-atlassian

data-recovery-atlassian

shared-responsibility-model-atlassian

atlassian-cloud-backup

data-compliance-atlassian

atlassian-enterprise-features