Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This article describes the process of adding a Jira organization to GitProtect.
Log in to GitProtect Management Service, open the DevOps tab on the left side of the window, and select Jira from the list.
Click the Connect button under Jira Software or Jira Service Management (depending on your needs).
Enter your instance URL (for example, https://mycompanyjira.atlassian.net) and your Jira login, then add or select an from the Password Manager.
Configure your spaces sync and default worker — specify hours for synchronization, or set a time interval for automatic updates. Once done, click Proceed.
Your Jira organization has now been successfully added to GitProtect — click Custom policy to adjust your backup policy settings, or click Run backup to execute the backup immediately using the current policy configuration.
In this article, you will learn how to recover your Jira organization data using the granular restore option.
Get into the restore view using the following method:
Open the Jira tab (DevOps > Jira), then click the Restore button next to the organization whose backup you want to restore.
Next, select the backup plan from which you want to restore data.
Choose the backup version from all the backups that have already been performed — select the desired date and click the Restore button.
Select the available destination for the restore process from the list.
In the next aside, choose the resources you want to include (restore option) and click Next. Then, select data to restore and click Proceed.
In the next aside, specify the restoration path and directory (where applicable). In Default worker section, choose the worker that will be responsible for performing the restoration.
In Restore settings you can set a custom name for the space that will be created during the restore process. You can also decide if you want to restore automation rules, their owners, etc. Visible options will vary depending on the restoration type.
When restoring spaces, you can preserve the original work item keys by enabling the Restore required global resources option and then enabling Restore original work item keys to a custom field.
After defining all parameters, click the Restore button to begin the recovery process. You can monitor its status in the Tasks tab.
Technical requirements for securing Jira organizations with custom domains.
Custom domains in Jira allow organizations to use a branded URL instead of the default *.atlassian.net address. Even if a Jira instance has a custom domain configured, proper protection requires adding the organization to GitProtect using the original Atlassian URL.
Jira instances that use custom domains can be integrated with GitProtect, but must use their original Atlassian URL instead of the custom domain. This limitation results from how Atlassian identifies and authorizes organizations.
Atlassian security and administration APIs are bound to the organization's original Atlassian-managed URL (e.g., yourcompany.atlassian.net), not the custom domain. The custom domain serves as a user-facing alias for access and branding purposes.
Internally, Atlassian recognizes, authenticates, and grants permissions only through the original URL registered in Atlassian Administration (https://admin.atlassian.com). Therefore, GitProtect must use the original Atlassian URL to identify the organization and its applications, authenticate API requests, and enforce security and access controls.
Using the custom domain would prevent proper authorization and could lead to failed connections or incomplete protection, which is why the original Atlassian URL is required even when a custom domain is configured.
You can find organization's original URL in > Apps > App URLs > Custom domains > Actions > Show details.
The original URL is listed in the Details section under Default URL (fallback).
Overview of the Jira backup process in GitProtect, including backup strategy, backup plan creation, and data protection for individual spaces.
The Jira backup process overview outlines the steps GitProtect takes to securely back up your Jira organization's data.
GitProtect is designed to protect DevOps ecosystems, including Jira.
With GitProtect, you can create separate backup plans for critical and non-critical spaces within the same Jira instance. Each plan can use different rotation scheme, ensuring your entire Jira environment is reliably protected.
For example, you can use the recommended Grandfather-Father-Son (GFS) rotation scheme for backup plans protecting critical spaces and metadata that change daily — or even more frequently. For unused spaces that must be retained for future reference, you can create a separate backup plan with a custom rotation scheme. This type of backup primarily serves Jira archival purposes, and with unlimited retention, copies can be stored for as long as needed — even indefinitely.
When creating a backup plan, you define how GitProtect protects your data. For Jira, the default data protection method is granular backup.
Granular backup focuses on individual Jira components, such as work items, spaces, or attachments. In granular backup, each space is handled as an individual task — if an error occurs during execution, only the spaces that were successfully backed up will have a restorable backup available.
The granular data protection method allows you to:
*Select individual data to protect, along with a short description of the dependencies visible in the interface (includes information about object activity history, which is disabled by default because it may affect backup performance).
GitProtect is a multi-storage system that allows you to store your data in the cloud, locally, or in a hybrid/multi-cloud environment. You can use different storage types to replicate backups, reduce the risk of outages or disasters, and comply with the 3-2-1 backup rule — which means having at least three copies of your data on two different storage types, with at least one copy stored in the cloud.
Permissions required to integrate Jira with GitProtect and protect its resources.
A Jira admin is required to back up not only individual spaces but also the broader set of global resources and company-managed spaces that may be accessed or shared by team-managed spaces, including any global resources used by those spaces.
With Jira admin access, GitProtect ensures that all global configurations—such as shared dashboards, filters, and automation rules—are properly protected.
If you only need to protect specific team-managed spaces that do not use global resources, granting your Jira account administrative permissions at the space level is usually sufficient. With access limited to the team-managed space, GitProtect will not have access to global configurations.
The following lists the permissions your Jira account must have for GitProtect to access, download, and back up all attachments in the protected space, based on the space management type.
Permission schemes — to access attachments, your Jira account must have the Browse Projects permission for a specific space, either directly or through a group or role. You can change this permission by editing the scheme assigned to the space or by assigning a different scheme.
Work item access restrictions — if a space uses a work item Issue Security scheme and contains work items with restricted access that include attachments, your account must belong to at least one Security Level assigned to each work item.
Comment restrictions — if an attachment is part of a comment with restricted access, your account must belong to the role or group that has access to this comment.
Space visibility — for spaces with private or limited visibility, you must be a member of the space to access and then back up its attachments. The assigned role and its permission scope are not relevant; space membership alone is sufficient. For all other visibility levels, attachments are accessible to the public and do not require any additional roles or permissions.
Work item access restrictions — if a work item or a comment has an access restriction applied, its attachments are visible only to users who have at least one of the roles specified in the restriction. The role name and permission scope do not matter — your Jira account only needs to be assigned one of the specified roles.
Guide to Jira backup in GitProtect, including plan configuration, scheduling, and protection of spaces, work items, and related data.
Overview of the Jira backup process in GitProtect, including backup strategy, backup plan creation, and data protection for individual spaces.
Overview of protected Jira resources, including spaces, work items, and metadata secured by backup.
Learn how to create a Jira backup plan in GitProtect to configure automated protection for spaces, work items, and related data.
Overview of protected Jira resources, including spaces, work items, and metadata secured by backup.
Jira protected resources define which parts of your Jira environment GitProtect can access, secure, and restore.
The following list includes all Jira resources covered by backup. Resources included in backup only for certain space types are marked accordingly:
CMS: data protection available only for company-managed spaces
TMS: data protection available only for team-managed spaces
Learn how to create a Jira backup plan in GitProtect to configure automated protection for spaces, work items, and related data.
Creating a Jira backup plan in GitProtect enables administrators to define how and when Jira data is protected within the backup environment, including selecting the backup scope and configuring the schedule and retention policy.
Granular backup plan focuses on individual Jira components, such as work items, spaces, and attachments, allowing you to restore specific items when needed.
The following steps demonstrate how to create a Jira granular backup plan using GitProtect Management Service.
Open the Backup tab (Plans > Backup) and click the + Add plan button in the top bar.
Select Jira from the list.
Select the Jira environment you want to include in the backup and how GitProtect will capture the Jira data:
Protect all: protects the entire Jira organization.
Select spaces: protects only selected spaces and their metadata.
Set up a name for your backup plan.
In Data to protect section, click Edit to configure the data that you want to back up. Here, you can also change the default backup agent (worker), which is directly responsible for backing up your Jira data.
Select one of the data stores assigned to your GitProtect instance to use as the backup storage.
Customize the scheduler and specify the retention period for your data.
Adjust the advanced settings, such as encryption, error handling, or bandwidth limits, to meet your organization's requirements.
Encryption: lets you secure your backup copy with encryption.
Compression: lets you compress and reduce copy size.
Review your configuration and click Save to create the backup plan, or Save&Run to start the first backup run immediately.
Set rules: captures data to protect based on the specified rules:
A granular Jira backup based on rules defined by the space name behaves the same way as repositories in Git-type projects. For example, the rule git will match only the space with the exact name git. To create name-based rules, you can use the following wildcards:
* represents any number of characters. For example, the rule *git* will match spaces with names such as my-git-1, git, git-100, and similar.
? represents a single character. For example, the rule git-300? will match spaces with names such as git-3001, git-3002, and git-300m.
Error handling: allows you to specify how to handle potential backup operation errors. Includes an option to skip corrupted work item attachments during backup.
Exclude Jira work items: excludes Jira work items from backup according to defined rules.
Bandwidth limit: allows you to reduce network usage and limit network speed during backup.
Backup scripts: enables configuring pre/post scripts executed during backup.
Task balancing: balances backup speed and CPU load.
Prevent system sleep: prevents your system from suspending while a backup is in progress.
Email notifications: lets you set up email notifications and its recipients.
In this article, you will learn how to recover your Jira organization using the disaster recovery option.
Get into the restore view using the following method:
Open the Jira tab (DevOps > Jira), then click the Restore button next to the organization whose backup you want to restore.
Next, select the disaster recovery backup plan from which you want to restore data.
Choose the backup version from all the backups that have already been performed — select the desired date and click the Restore > Disaster recovery.
Select the available destination for the restore process from the list:
If the restoration destination is a device, you must specify the recovery path. If you want to change the default worker responsible for handling the restore, make sure to do it before selecting the backup copy to restore.
If the restoration destination is Jira, you can change the default worker in the next aside. In
After defining all parameters, click the Restore button to begin the recovery process. You can monitor its status in the Tasks tab.
When you restore a backup to the original organization (the source organization from which it was created) using the disaster recovery method, the GitProtect.io for Jira application is removed from your Jira site and must be reinstalled afterward.
To add the GitProtect app to your Jira site again, go to Apps > Explore more apps and search for GitProtect.io for Jira. On the app page in Atlassian Marketplace, click Try it free and follow the on-screen instructions. The process is the same as when you added the app for the first time, except you do not need to provide a personal access token because GitProtect is already integrated with your Jira account.
Once the app is reinstalled, you can view your backup statistics and use all GitProtect.io for Jira app features.
This article describes Jira recovery process in GitProtect.
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 spaces, work items, attachments, and 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. It’s especially useful when:
Space-level recovery:
A space-level restore in GitProtect is a type of recovery that focuses on a single Jira space. 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.
Jira disaster recovery feature is a full environment restore that brings 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.
GitProtect allows you to restore your Jira organization in two ways:
To a local device — restore the Jira organization to a selected device with the GitProtect agent (worker) installed. This option lets you keep Jira backups locally (e.g., for archiving) or manually import them into your Jira organization.
To Jira organization — automatically import the Jira backups to the original, or new Jira organization.