Process overview

Learn more about the backup process for Jira.

The Jira backup process outlines the steps Xopero ONE follows to securely back up your Jira organization's data from start to finish.

---

General information

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

To ensure your entire Jira environment is reliably backed up, make sure to include all spaces (projects) along with their related metadata — the best practice is to create a backup plan for critical spaces and metadata that change daily (or even more frequently), for example, using the recommended Grandfather-Father-Son (GFS) rotation scheme.

Additionally, create a separate backup plan for unused spaces that you need to keep for future reference. This type of backup primarily serves Jira archival purposes, and with unlimited retention, you can store your copies for as long as needed — even indefinitely.

You can also delete spaces from your Jira account while keeping a copy in storage, which helps bypass Jira limits.

---

Backup & recovery

After selecting Jira as the backup type, you need to define how Xopero ONE should protect your data. At this stage, you choose between two protection methods: granular backup or disaster recovery. This selection determines the scope of data captured during each backup and the flexibility you will have during restore operations.

Granular backup focuses on individual Jira components, such as issues, projects, or attachments, allowing you to restore specific items when needed.

A granular Jira backup based on rules defined by project name behaves the same way as repositories for GIT-type projects. To create name-based rules, you can use the following wildcards:

1. * represents any number of characters.

2. ? represents a single character.

For example:

1. The rule *git* will match projects with names such as my-git-1, git, git-100, and similar.

2. The rule git will match only the project with the exact name git.

3. The rule git-300? will match projects with names such as git-3001, git-3002, and git-300m.

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. This differs from disaster recovery, where the backup copy covers an entire Jira organization.

Disaster recovery backup strategy captures the entire Jira environment in a single operation, enabling you to restore the full instance in case of a major failure or service disruption (it is also possible to perform granular recovery using a disaster recovery backup copy).

Backup strategy comparison

Granular backup copy compared to a disaster recovery copy:

Action	Granular backup	Disaster recovery
Selecting projects to protect (all, selected, based on rules)	✅	❌
Select individual data to protect*	✅	❌
Exclude Jira issues (work items)**	✅	❌

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

_{**You can exclude Jira issues (work items) during backup plan creation (in Advanced settings).}

---

Adding multiple storage instances

Use different types of storage to replicate backups, minimize 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).

Xopero ONE is a multi-storage system that allows you to store your data:

• In the cloud (Xopero Cloud Storage, AWS S3, Wasabi Cloud, Backblaze B2, Google Cloud Storage, Azure Blob Storage, or any S3-compatible public cloud).

• Locally (NFS, CIFS, SMB network shares, or local disk resources).

• In a hybrid or multi-cloud environment.