Hi,
My company would like to know the best practice to back up Jira software and Confluence cloud recommended by Atlassian.
We have seen the following threads about creating offline backup.
https://confluence.atlassian.com/jirakb/automate-backups-for-jira-cloud-779160659.html
https://support.atlassian.com/confluence-cloud/docs/create-a-site-backup/
Seeing that Alassian already makes backups of data for application recovery purposes, what are the planned use of these offline backups? Should we create these backups in specific occasions, like plan upgrade, or on regular basis? Can these offline backups be used to roll back changes?
Please share with us any other points regarding the cloud back if you deem relevant.
Thanks and regards,
Ying
>Seeing that Alassian already makes backups of data for application recovery purposes,
These backups are not designed for recovering individual systems, they are for recovering blocks of systems in case of server failure. It can be done of course, they contain everything, but it's a long and slow process, and Atlassian do not offer recovery as part of the service - you can't ask them to recover from a backup if you make a mess of something and feel like rolling back.
>what are the planned use of these offline backups? Should we create these backups in specific occasions, like plan upgrade, or on regular basis?
You don't have any control over upgrades, Atlassian do them. Changes of plan/access are not something you would want to take a backup before anyway, changes of plan just affect access to functions and numbers of users, not the data.
You should be taking a backup whenever you think you're about to make config changes that might break things, or if you have a concern about losing access to the service and need to retain a copy of the data for some reason
>Can these offline backups be used to roll back changes?
Yes, but they are totally destructive - if you take a backup at date/time X, then make changes, adding more issues or pages, config change, editing existing data etc for the next 6 hours, then restore the backup, you will lose everything done in those 6 hours. It's a complete roll-back, not a localised one.
Thank you for the detailed answer! @Nic Brough -Adaptavist-
I know that this is late to the party, but depending on how you have configured your site, backups may come in handy.
I recently took over administration of our Atlassian products and immediately started backing it up regularly. At the same time I was working on improving the configuration. Well, somehow someone deleted an epic and all it's linked tickets that had a few weeks worth of work history attached. I was able to recover just those issues that they lost. Obviously they were missing any recent changes tho. It also took about 24 hours because I had to download the backup of the entire instance, not just the project I needed. I have since put in place some better blocks to ensure people are not deleting huge chunks of work.
@Rob Hathawaywhat are the better blocks you put in place to ensure people are not deleting huge chunks of work? We don't allow users to bulk delete but if there are other blocks it would be good to know. Thanks
@PATRICIA MURPHY I removed everyone's ability to delete for now. I'm building a "Recycle Bin" structure where users will be able to push their unwanted issues to a recycle bin project where they can be restored if needed.
@Rob Hathaway Aside from the restore taking 24 hours, how easy did you find the restoration process? Do you have any specific recommendations to facilitate the process?
Hi again @Nic Brough -Adaptavist- Would you recommend making a backup before renaming the Epic feature type? Would that count as a config change that make break things e.g. filters?
It could be a breaking change, but actually, I wouldn't bother with a backup.
It's not going to break anything you can't easily fix (specifically, filters), and it's far easier to make another quick change to fix it than restore a backup. (Restoring a backup - hours, renaming it back to "Epic" - seconds)
At Rewind, we built a simple, automated backup and restore app to solve this exact problem for Jira Cloud. No coding or manual export/import required - we built restores to be self-serve and automatic, right in the app! No waiting for someone from support to handle your ticket.
It's available via the Atlassian Marketplace, and has a 7-day free trial with no credit card required:
https://marketplace.atlassian.com/apps/1226389/rewind-backups
I'm the PM who leads this product, so I'd love to hear any feedback you might have. Thanks!
It looks like you're new here. Sign in or register to get started.
