The Cloud container itself has automated backups taken regularly for disaster recovery scenarios, like a node crashing at the data center, and all the disaster recovery options would be done in the background, and a more detailed breakdown on the services are covered in our "Data storage FAQ"
However as this covers Disaster Recovery scenarios as noted in the article above it does not support the use of the backup data to roll back changes in the application, exe if you delete a project accidentally it's up to you to restore from a local backup to recover the project data.
So a recommended practice is that whenever you are preparing to do a major data update, like deleting a project or bulk deleting issues, you should create an XML backup of the site so you have the option to roll back the changes incase something getds changed or deleted that was not supposed to be altered, the process would be the same flow as "Migrating from one Cloud instance to another Cloud instance" but importing the data back into the same instance.
However there is an important point to cover here as well as there is currently a limitation in the Next-gen project types covered in the step for "Exporting issues" noting:
Currently, exports that include next-gen software projects won't include any epic link or other relationship data between epics and their children issues. This is a known error and we're working to fix it. Thanks for your patience.
So this will be fixed soon and only affects the next-gen projects and classic projects are unaffected but if you do need to do a recovery at this point in time the Epic Links will need to be manually reset post data recovery for any next-gen projects until this is fixed.
I was just circling back to this thread as I forgot to mentions something that is really useful here.
Check out this KB article that contains a walkthrough on setting up a automated backup script using the API we put together and have hosed on our public bitbucket repo that can be used to do a regular local backup from a automated task rather than manual backups ad-hoc:
Do note that this script was put together and maintained as a workaround to not having a in application backup automation tool (detailed in this feature request) so it is not a officially supported script so it can break from time to time as the system is upgraded and backend functionality changes the backup behavior but we do monitor this and update the script regularly when this occurs, so its still always recommended to verify the backup is there before proceeding with major changes
Learn how to use two new reports for next-gen projects in Jira Cloud: Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events