By understanding the scope of resources that need protection, you can determine whether full Jira admin access or space-level administration is the appropriate level of permission.

General permissions

Company-managed spaces

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, Xopero ONE ensures that all global configurations—such as shared dashboards, filters, and automation rules—are properly protected.

Team-managed spaces

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, Xopero ONE will not have access to global configurations.

Permissions required to back up attachments

The following lists the permissions your Jira account must have for Xopero ONE to access, download, and back up all attachments in the protected space, based on the space management type.

Company-managed spaces

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

1. Issue 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 issue.

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

Team-managed spaces

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

2. Issue access restrictions — if an issue 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.

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 Xopero ONE using the original Atlassian URL.

General information

Jira instances that use custom domains can be integrated with Xopero ONE, 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, Xopero ONE 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.

Finding the original instance URL

You can find organization's original URL in https://admin.atlassian.com > Apps > App URLs > Custom domains > Actions > Show details.

The original URL is listed in the Details section under Default URL (fallback).

The Jira backup process overview outlines the steps Xopero ONE takes to securely back up your Jira organization's data.

General information

Xopero ONE is designed to protect DevOps ecosystems, including Jira.

With Xopero ONE, 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.

Backup method

When creating a backup plan, you define how Xopero ONE 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 spaces to protect (all, selected, based on rules).

• Select individual data to back up*.

• Exclude Jira work items.

• Skip corrupted work item attachments.

• Restore specific work items, spaces, assets, and other Jira objects without the need to restore the entire Jira organization.

_{*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).}

Backup storage

Xopero ONE 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.

Creating a Jira backup plan in Xopero ONE 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 setup

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 Xopero ONE Management Service.

1

Open the Backup tab (Plans > Backup) and click the + Add plan button in the top bar.

2

Select Jira from the list.

3

Select the Jira environment you want to include in the backup and how Xopero ONE will capture the Jira data:

1. Protect all: protects the entire Jira organization.

2. Select spaces: protects only selected spaces and their metadata.

3. Set rules: captures data to protect based on the specified rules:

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

4

Set up a name for your backup plan.

5

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.

You can deploy multiple agents and assign different agents to each backup plan.

In the Additional data section, under Assets, you can enable including object activity history in the backup.

6

Select one of the data stores assigned to your Xopero ONE instance to use as the backup storage.

7

Customize the scheduler and specify the retention period for your data.

8

Adjust the advanced settings, such as encryption, error handling, or bandwidth limits, to meet your organization's requirements.

1. Encryption: lets you secure your backup copy with encryption.

2. Compression: lets you compress and reduce copy size.

3. Deduplication: allows you to reduce the backup size.

4. Error handling: allows you to specify how to handle potential backup operation errors. Includes an option to skip corrupted work item attachments during backup.

1. Exclude Jira work items: excludes Jira work items from backup according to defined rules.

1. Bandwidth limit: allows you to reduce network usage and limit network speed during backup.

2. Backup scripts: enables configuring pre/post scripts executed during backup.

3. Task balancing: balances backup speed and CPU load.

4. Prevent system sleep: prevents your system from suspending while a backup is in progress.

5. Email notifications: lets you set up email notifications and its recipients.

9

Review your configuration and click Save to create the backup plan, or Save&Run to start the first backup run immediately.

Useful links and items

In Xopero ONE, you can restore your Jira data using granular recovery.

Recovery methods

Granular recovery

Jira granular recovery in Xopero ONE 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:

• 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 types include:

1. Space-level recovery:

A space-level restore in Xopero ONE 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.

Disaster recovery

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.

Restore destination

Xopero ONE 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 Xopero ONE agent (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.

Jira granular recovery enables you to restore selected Jira items such as work items, attachments, or configuration elements, giving you precise control over what is brought back without affecting the rest of your space data.

Recovery process

1

Get into the restore view using the following method:

1. Open the Jira tab (DevOps > Jira), then click the Restore button next to the organization whose backup you want to restore.

You can also use the Explore button to restore your data.

2

Next, select the backup plan from which you want to restore data.

3

Choose the backup version from all the backups that have already been performed — select the desired date and click the Restore button.

If you are restoring data from a disaster recovery backup copy, you must also select the restoration method.

4

Select the available destination for the restore process from the list.

Please note that when you recover Jira data to a device, the amount of data available for recovery will be limited—certain Jira components and metadata are only supported when restoring directly to a Jira instance.

5

In the next aside, choose the resources you want to include (restore option) and click Next. Then, select data to restore and click Proceed.

6

In the next aside, specify the restoration path and directory (where applicable). In Default worker section, choose the agent that will be responsible for performing the restoration.

7

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.

8

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.

Original work item keys are mapped to the GitProtect_Original Key custom field.

9

After defining all parameters, click the Restore button to begin the recovery process. You can monitor its status in the Tasks tab.

Adding Jira organization to Xopero ONE connects your environment to the platform so you can start protecting its data.

Using an API token

1

Log in to XMS, open the DevOps tab on the left side of the window, and select Jira from the list.

2

Click the Connect button under Jira Software or Jira Service Management (depending on your needs).

3

Enter your instance URL (for example, https://mycompanyjira.atlassian.net) and your Jira login, then add or select an API token from the Password Manager.

Xopero ONE can secure organizations that have a custom domain configured, but the organization must be added using its original URL, which can be found in https://admin.atlassian.com > Apps > App URLs > Custom domains > Actions > Show details.

Learn more about custom domains in this article.

4

Configure your spaces sync and default worker — specify hours for synchronization, or set a time interval for automatic updates. Once done, click Proceed.

The account used for the authorization process must have at least site admin permissions.

5

Your Jira organization has now been successfully added to Xopero ONE — click Custom policy to adjust your backup policy settings, or click Run backup to execute the backup immediately using the current policy configuration.

Granular backup is the default policy configuration applied to any new Jira organization you add to Xopero ONE.

Useful links and items

With Jira disaster recovery you can quickly restore your entire Jira organization after a major failure, keeping your spaces, work items, and configuration data available and consistent.

Recovery process

1

Get into the restore view using the following method:

1. Open the Jira tab (DevOps > Jira), then click the Restore button next to the organization whose backup you want to restore.

You can also use the Explore button to restore your data.

2

Next, select the disaster recovery backup plan from which you want to restore data.

3

Choose the backup version from all the backups that have already been performed — select the desired date and click Restore > Disaster recovery.

4

Select the available destination for the restore process from the list.

1. 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 you select a device as the restoration destination, Xopero ONE will recover all protected Jira data included in the selected backup plan as separate, compressed (zipped) folders.

1. If the restoration destination is Jira, you can change the default worker in the next aside. In Restore settings, you can also choose whether you want to restore assets and users.

The disaster recovery process replaces all existing data (except users and assets) in the selected Jira instance, and the backup may not include every item stored in that environment.

Jira enforces several limitations. Atlassian limits the number of Jira backup restores per organization to 100. A restore also affects your Jira usage — the process can take some time, and during this period your Jira instance will not be accessible.

You can choose to preserve the original Jira Asset identifiers during a disaster recovery.

5

After defining all parameters, click the Restore button to begin the recovery process. You can monitor its status in the Tasks tab.

Jira protected resources define which parts of your Jira environment Xopero ONE can access, secure, and restore.

Backup coverage

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