-
Bug
-
Resolution: Fixed
-
Low
-
7
-
Severity 3 - Minor
-
1
-
Issue Summary
When a user generates a Jira backup with attachments, there's a 48 hours cooldown period where users can't generate another backup with attachments. They are allowed to generate a backup without attachments as this type of backup doesn't have any timer. However, this will reset the backup timer for the Jira backup with attachments.
Steps to Reproduce
- Generate a Jira backup with attachments (48 hours timer)
- After 24 hours, the timer should be reduced to 24 hours left.
- Now, generate a backup without attachments.
- The timer for backup with attachments is reset back to 48 hours.
Expected Results
- The backup without attachments should not reset the timer for backup with attachments.
Actual Results
- The backup without attachments resets the timer for backup with attachments.
Workaround
None.
[JRACLOUD-73314] No attachment backup will reset the timer to 48 hours if there is existing timer due to backup with attachments previously
Hello everyone,
Thank you for your votes, comments, and patience on this issue.
We are delighted to inform you that the bug has been successfully addressed.
As a result of this fix, generating backups without attachments would no longer affect the cooldown timer for backups with attachments.
This enhancement ensures a seamless and convenient experience when generating backups, regardless of attachment requirements.
If you encounter any further issues or have any questions, please reach out to our support team. We are here to assist you and address any concerns you may have.
Thank you,
Varad Pingale
Product Manager, Jira Cloud
Any status updates on this bug? It was created 31/Oct/2019 8:21 AM and it is impacted our ability to pass the disaster recovery portion of audits.
Not having the ability to complete backups with attachments is extremely impactful to our business operation. We have multiple work projects in flight at the same time with different production release dates. It is therefore critical that we have a regular cadence of executing both full and partial backups on routine intervals in the event of failure that would would prompt to need to restore our work. In addition, having the ability to backup and restore as required is paramount to any effective disaster recovery program. I am requesting that you please reconsider the minor priority of this bug and move it up to high priority so that we can be compliant with our audit requirements. Thank you!
Is there any update on this? Having both full and partial backup options is high priority to most companies, and we now can only have a choice of one or the other – not both! We must run partial backups 2x per day and full every 50 hours due to the restriction. With Confluence it works perfectly; however, with Jira it doesn't work at all.
This is VERY IMPORTANT for disaster recovery! We have to run full backups every 48 hours and partials 2x per day around full. It is way more important than roadmap features – it is a BUG.
I would appreciate it if you consider to fix it. Its very annoying if you implement your own automated backup and try to achieve a daily back and every 48h with attachments. 
Hi everyone,
Thank you for previously raising this bug and bringing it to our attention.
Within our company roadmap and work capacity, we try to address or review each bug request but admit that not each one will be resolved. To continue the culture of being honest and open, we are closing this bug to focus on our upcoming roadmap for all Jira users.
As we continue to roll out features we do look at requests made by our users and if you feel like this bug is still impacting your team please let us know.
Thank you again for providing valuable feedback to our team!
Jira Cloud team
WONDERFUL!!! Thank you so much!!