-
Suggestion
-
Resolution: Unresolved
-
None
-
0
-
30
-
Problem Definition
Currently, when creating a backup without attachments in Jira Backup Manager, user will be able to create another backup without attachments immediately, there's no timer. However, if the user wants to create a backup with attachments, it has the 48 hours timer, regardless of any type of backup created previously.
Suggested Solution
Have a separate timer that only starts counting when backup with attachments are created.
- relates to
-
- In Progress
-
- Gathering Interest
-
- Gathering Interest
[JRACLOUD-70167] Backup Timer only counts when include attachments
@Peter Deschenes I agree strongly with your comment. The Confluence delay is currently 24-hours in between full (with attachments) backups. It only make sense for consistency that the Jira delay would be the same. Currently, I'm going to have to set our Jira backup job on a very non-standard 2-day schedule, while our Confluence backup job runs every 24 hours.
are there any plans to provide a shorter frequency when backing up with attachments? Even getting it to 24h would be a big improvement!
@Földes László Hello, thanks for your insight. No i think you can keep the 48h delay but only considering full backup reset the timer (and simple backup do not reset the timer). So it wont change the load on your server, as user can only do full backup every 48h (by the way you should set it to 47h30 min for instance, so cronjob every 2 days will work sure).
Subject is about not reseting the full-backup timer if we do simple backup. It is not about changing the delay needed to wait for full backup.
This issue is just about the trigger which reset de delay to wait, but you can keep the 48h delay for sure.
Földes László
added a comment - Reverse engineering the thought behind this idea (full backup vs. simple backup) is not to overwhelm the system with continuous full backups.
With simple backups useless, people will only do full backups thus requiring more resources to do the backup, which quite defeat the purpose decreasing the load on the system.
Földes László
added a comment - Reverse engineering the thought behind this idea (full backup vs. simple backup) is not to overwhelm the system with continuous full backups.
With simple backups useless, people will only do full backups thus requiring more resources to do the backup, which quite defeat the purpose decreasing the load on the system. Just to add, this problem leads to a 48h period without any backup (as small/soft backup without attachement will reset the timer to 48h) if you want to make a full backup. You have to cross the finger that nothing bad happens during this 48h period needed before being able to make the full backup...
Jira own back (daily) are only in disaster recovery, not if people delete datas in JIRA.
So we are left on our own without a proper solution for now.
I hope this issue will progress as it is an important subject.
Please vote on it.
It does seem a little silly that, as I understand it currently, for a daily backup schedule with attachments only on Sunday, I would need to use a Sunday - Thursday schedule with no backups on Friday or Saturday.