# Process overview

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

***

## Recovery methods

### <mark style="background-color:blue;">Granular recovery</mark>

**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:

* [x] Only a small set of data was lost, corrupted, or changed incorrectly.
* [x] You don’t want to overwrite current data.
* [x] 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.

2. **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**.

### <mark style="background-color:blue;">Disaster recovery</mark>

{% hint style="danger" %}
Due to **Atlassian** API changes taking effect on March 30, 2026, the current disaster recovery backup and restore functionality will no longer be available. **To ensure continued protection of your Jira data, please switch to the granular backup plan.** Data previously protected with disaster recovery backups can still be restored using the granular restore option.
{% endhint %}

**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.

{% hint style="warning" %}
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.
{% endhint %}