Retry policy for backups

This document demonstrates the retry policy we have when it pertains to backups

When each backup is initialized, the app tags the process to completion, this way the app knows that it has gone through a series of checks and it can be certain it's completed. However, certain situations may arise that may cause the process not to be completed. This is where the “retry” process comes in as it will attempt to perform the same action at a different interval.

Colour scheme

• The retry process uses 4 colour schemes to denote what is happening between each scheduled task.

  • GREEn → This means that everything is processing at a normal parameter while monitoring for a failure event

  • red → This means that a backup has failed once and the scheduled interval has been adjusted slightly

  • yellow → This refers to a second failure of the same scheduled task and now the interval should be adjusted to cater for the failure

  • blue → At this stage, the failures has occurred for the third time and the app will typically apply the original interval for this specific task

How does that work for backing up projects?

• For project extraction, the app uses an interval to determine the next schedule. When a failure occurs, the “retry” process shifts from “green” to “blue” and applies 10 mins, 20 mins, and 40 mins respectively.

How does that work for Jira Cloud backups?

• When backing up your Jira Cloud site, there might be instances where the backup will not start again due to a cool-off period or probably an attachment threshold hasn’t been reached. When a failure occurs, the “retry” process shifts from “green” to “blue” and applies 1 hr, 3 hrs, and 5 hrs respectively.

Note: In the activity logs, you will see the activity as “Retrying…” → this indicates that a retry was run to account for any failed scheduled task