Process overview

This article describes Jira recovery process in GitProtect.

In GitProtect, you can restore your Jira data using granular recovery or disaster recovery.

---

Recovery methods

Granular recovery

Jira granular recovery in GitProtect lets you restore selected Jira data without performing a full environment rollback. Instead of recovering everything, you can choose specific projects, spaces, issues (work items), attachments, or other items that were deleted or changed. This makes the recovery process faster, reduces process disruption, and avoids overwriting healthy data.

Granular recovery is ideal when only a small portion of information needs to be restored — it provides more control and precision than a full disaster recovery restore. It’s especially useful when:

• Only a small set of data was lost, corrupted, or changed incorrectly.

• You don’t want to overwrite current data.

• You want a faster, targeted restoration with minimal disruption.

Granular recovery can be performed both on granular backup copies and disaster recovery backup copies.

Granular recovery types include:

1. Jira-level recovery:

Jira-level recovery refers to disaster recovery and data restoration for an entire Jira instance; in GitProtect, it allows you to recover your Jira organization as a whole. During the process, the system restores all Jira data included in the selected backup while keeping user accounts and assets unchanged. It overwrites existing content in the target Jira instance, so the restored organization reflects the state captured in the backup.

1. Space-level recovery:

A space-level restore in GitProtect is a type of recovery that focuses on a single Jira space rather than the entire organization. It allows you to restore all elements within that specific space—such as work items, boards, and configurations—without affecting other spaces in your Jira instance. It's useful when only part of your Jira environment is corrupted, deleted, or needs to be rolled back, letting you recover just the affected area while leaving the rest of the organization intact.

It’s essentially a middle ground between a full Jira-level restore and a fully granular restore of individual items.

Disaster recovery

Jira disaster recovery feature in GitProtect is a full environment restore designed to bring your Jira instance back to a functional state after a major incident, such as data corruption, ransomware, or widespread loss. Instead of restoring individual items, disaster recovery reinstates all protected data and configuration from the selected backup, returning the environment to its previous state. This approach ensures business continuity and minimizes downtime, but it also replaces current data with the restored backup.

Disaster recovery is intended for large-scale disruptions where partial restoration is not sufficient or feasible.

---

Restore destination

GitProtect allows you to restore your Jira organization in two ways:

1. To a local device — restore the Jira organization to a selected device with the GitProtect worker installed. This option lets you keep Jira backups locally (e.g., for archiving) or manually import them into your Jira organization.

2. To Jira organization — automatically import the Jira backups to the original, or new Jira organization.

The maximum number of restore operations allowed within a single Jira instance is 100. Any attempt to exceed this limit cannot be processed due to Jira API constraints. This limitation is not documented in Atlassian’s official resources but was identified during practical restore testing and operational observations on our side.