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

Compressing Projects With Very Large Attachments

Hey guys, We are having difficulties managing projects in jira that have very large attachments. Most of the time they are image and video attachments. Is there any way that we can compress this type of project, reducing the occupation of these files on the disks. It was already necessary to carry out an addition of disks due to the very rapid increase in utilization. I used project archiving but it seems to me if I'm not mistaken not to compress the attachments. Just archive the project. If anyone has any tips or guidance on how to work in this specific scenario I would be very grateful for the help.

Thank you very much

2 answers

2 accepted

0 votes
Answer accepted
Craig Castle-Mead
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Apr 13, 2023


I’m not aware of any Jira native methods to compress/optimise attachment size on disc.

a few things to consider though:

  1. limit the maximum attachment file size in Jira itself and implement a method for storing larger files (like video media) in a non-Jira based storage system that has some integration with Jira so they’re easy to reference in the Issues
  2. depending on the OS/file system type, there may be a “transparent file comprsssion” solution you can implement. Jira will see the files as they were uploaded, but the OS/file system implements some logic as the files are written/read that reduces the actual space on disc and as much as possible ( is one random page I found that talks thorough a ZFS style solution). We’ve found on our environment (Jira has > 7TB of attachments and growing), that there are often a number of duplicated files uploaded, so even a file system that de-dupes the storage (save one actual copy and have pointers to the primary file from any of the duplicate paths) could save some space. You should be able to figure out how bad your duplicate problem is by getting the md5 hash of your files, then counting how many of those hashes are not-unique
  3. You’re correct that archiving a project will not do anything with that projects attachments. Archiving makes the project read only and removes the issues from the index (which powers search, boards, etc)
  4. I’m not sure what infrastructure you’re running this application on, but if you have the option of deploying storage that has a lower cost/TB (which will often mean slightly lower performance), then you may be able to move certain projects attachment directories (that could be your archived projects, or projects that need a large number of videos) to the “cheaper” storage and then sym-linking those folders back in to the main attachment directory. We have implemented this in production on AWS, Ubuntu 20.04 application servers and multiple EFS mounts. Our goal was to lower the recovery time objective (RTO) in our disaster recovery process as EFS can take a long time to restore. We now have our “main” attachment EFS that we keep as lean as possible, it gets restored first and once that’s restored we can start Jira and users can start working, but will only be able to see/add attachments for projects on that drive. The secondary EFS volume is then restored, and once that’s done, the attachments will be available for the rest of the projects. While we’ve set this up in production, YMMV, as always, test on a non-prod system first. We have a 4 node DC cluster and ensuring all the nodes have the correct symlinks setup is straight forward for us as we have Puppet Enterprise enforce/handle all the mounts/symlinks.


Points 2 and 4 are also not supported approaches by Atlassian as far as I’m aware, however the goal is that they should be invisible to the application itself. 



Hi @Craig Castle-Mead ,

Thank you very much for the points addressed which were very enlightening for the necessary adjustments.


0 votes
Answer accepted
Florian Bonniec
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Apr 13, 2023


Archiving issue only removed them from the index. Usually I recommand to not store large attachment and limit the size on the system settings. JIRA is a project managment tool, large files should be store somewhere else and a link to this attachment should be added to JIRA.



Hi @Florian Bonniec ,

Thank you for the tip.


Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events