Atlassian Team members are employees working across the company in a wide variety of roles.
July 10, 2025 edited
@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.
@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.
@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).
Atlassian Team members are employees working across the company in a wide variety of roles.
July 10, 2025 edited
@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!
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
@Branimir Kain I am also raising my hand as one of the "has a data retention duty for several years"-customer. We currently have an alternative extra-paid Backup Solution that secures our state into an AWS S3 bucket every 48h to ensure that our JSM data is archived read-only for 10 years like our authorities wants us to.
If Atlassian could do that by themselves we would be glad.
Atlassian Team members are employees working across the company in a wide variety of roles.
July 17, 2025 edited
@Herman Zuurhout, we don't support it right now, but I'm curious about the specific requirement that's preventing you from using Azure. I just want to make sure I can articulate the why properly to the team.
Atlassian Team members are employees working across the company in a wide variety of roles.
July 17, 2025 edited
@Richard Scholtes, would you be willing to share your industry and what regulatory authority requires you to keep it for 10 years? Also, could you give me a little more detail on how your existing solution functions? More precisely, is it an interactive JSM environment? Or is it more of a read-only XML coupled with a changelog/key information? Just curious what level of depth you're getting from your existing solution.
Atlassian Team members are employees working across the company in a wide variety of roles.
July 17, 2025 edited
@María José Vázquez Poza, I believe a broader conversation is happening here. It seems like this would apply to all our Cloud products, not just our backup and restore solution.
@Branimir Kain We are looking to perform a test restore of our AWS backups to an existing test site. The current documentation includes the following limitation for restoring backups (similarly mentioned in the Restore interface),
"To restore your backup, the app should not contain any user-generated data. It can’t contain active, deleted, or archived content. For newly provisioned Confluence products, you need to delete the default personal space too."
We would like to avoid deleting the entire site, i.e., canceling and restarting the subscription, since it sounds like this loses the site URL. Is there any documentation or guidance for how best to clean/reset an app so a backup can be restored to it?
@Lakshmi Behl Thanks! That seems to be working so far (restore in progress), but in the hopefully unlikely case where we would need to restore to an existing site with data, we would still be interested in knowing what the process for cleaning/resetting an app would look like so we can include/reference that in our own documentation.
43 comments