Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Archiving JIRA information - space considerations

I was looking at this article:

We are currently using about half of our 250Gb allocation for JIRA Software. If we archive old issues, do we recover that portion of usage?

So if we were to archive 100Gb of information, does that mean we are now using only 25Gb?

How much can we archive? Is there a limit to the size of the archive?

Can we download the archived information in XML, CSV or PDF format?

2 answers

2 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 01, 2023

Archiving issues (or projects) will not affect your storage space.  Archiving removes nothing; the data remains on the disk. It's just found differently. 

You're using 125Gb now; if you archive 100Gb worth of issues, you'll use 125Gb afterwards.

To bring disk usage down, you need to delete stuff completely.

Now, most of the issue data (think "fields") is held in the database, which is quite an efficient way to hold data, and if you think about how much data there is on an issue, it is also relatively small.  Imagine you've got 1000 words stored on an issue (including names of people, dates, etc.); the data is probably already smaller than the characters you see.  Some fields are shorter than their displays - for example, an option in a select-list looks like "Mr Flibble says 'time to die'!", but all that has been stored on the issue in the database is a 5-6 digit number, which is a lot smaller than the text (Jira is looking it up for display - the options table is keyed off the 5-6 digit number and contains the text that gets displayed once)

That means that the data on issues is relatively small.  I've seen Jira systems with hundreds of thousands of issues and their entire database storage ticking over on a few gigabytes of storage.

On Server, you can configure Jira to keep all the logs and backups, which means it will happily chew up lots of space as it runs.  The default installs now at least do a bit of a "log rotate" on the logs, and the recommendation to turn off the twice daily XML backups (backup the database instead) solves the other problem (although I tend to stick log rotate on that directory to, only keeping the last 3-5 backups because admins can still run them if they want)

On both Server/DC and Cloud, the one thing that will be eating all your disk space is attachments.

On server/dc, you have the option of doing simple disk space analysis - the attachments are held in a simple directory structure and an admin can easily tell you what projects or even issues have attachments chewing up space.  They can also physically delete the files if you don't mind Jira showing you "file not found" icons when you look at issues that have had their attachments deleted.

You have no OS access on Cloud, so you can't do that.  I'm afraid all you can do is trawl through your issues to look for large attachments and consider whether you can delete them or the issues to which they are attached (for audit reasons, I usually go after deleting the attachments on resolved issues over a certain age, and adding a comment to say "admins deleted attachment (x) because we were low on space)

Oh, and the 250Gb limit is not a "hard" limit on Cloud.  If you stray over it, nothing will stop working, you start getting Atlassian asking you to upgrade to the next tier, so you get the next band of storage allowance.  You can ignore that for a long time, but they will eventually change your subscription to cover it if you carry on growing.

Thanks - I appreciate the additional ideas, I think we'll need to look at this, and I've already mentioned to the team to be strategic when including attachments and removing attachments that don't make sense (like client logos and other images that don't add value to the ticket).

The other thing we could do, I believe, would be for us to perform a bulk export of data and then bulk delete the exported data.

0 votes
Robert Wen_ReleaseTEAM_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 01, 2023

Hello @Mo Bhimji 

Archiving issues can only be done on Data Center.  You can archive projects in Cloud and that may bring your storage usage down.

Storage and their limits really points to how many attachments and avatars you use.

Suggest an answer

Log in or Sign up to answer
Site Admin
AUG Leaders

Atlassian Community Events