JIRA requires full read/write access to a standard directory tree to store and retrieve attachments.
It does not care if the underlying storage is compressed. So, you can't just zip/rar/tar up the directory - JIRA won't be aware of how to read within it. But if you're using a directory mounted on a disk that compresses on the fly and looks like a normal directory tree, it'll be fine (although this storage is too slow for other stuff in JIRA's home directory - if you do go that way, only do it to attachments, not the rest of the home directory)
JIRA also stores data in the database about attachments - if you start deleting old attachments arbitrarily, you'll find the issues they're attached to still try to present them to the user. This will not make anything fail, other than getting a broken attachment image and an error for the user if they do click on one. JIRA will happily run everything else fine with broken attachments. But, ideally, you should delete them properly, within the issues, so all the data is cleaned up. (Yes, I would use Script Runner to identify and drop old attachments, but there are other approaches - search and delete via the REST API for example)
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs