We are having a production JIRA with issues upto ~3 lacs. The attachment directory specifically is consuming lot of disk space, hence we are planning to move our production JIRA_HOME directory to SAN storage, but that will take some time to implement.
Meanwhile, our short term plan is to move the attachments of the older projects to a secondary server, whose issues are resolved and not updated over an year (criteria decided by our team).
Can I move these attachments for all those projects which fall under above criteria using a scripts or is there any plugin available in JIRA that can help me achieve this.
It would be of great help if anybody can share thoughts on below points -
1. Is this approach feasible enough. Are there any areas to be considered while following such approach
2. How do I go about making the same attachments available to the client upon his request, as the attachments moved are based on above criteria.
3. Is there any alternative approach, to get rid of attachments directory consuming disk space issue.
Any help on above issue much appreciated :)
Yes, this is a good idea. Moving the attachments to another disk with more space will solve the problem.
However, you suggest moving Jira_home to SAN. Do NOT do that without doing a LOT of testing. Jira_home contains other things - working files, plugins and so on. Critically, it contains your index. The index is read and written immensely heavily, and should always be placed on the fastest nastiest disk you can get your hands on. When I tested a SAN on versions 3 and 4 of Jira, the SAN disks were so relatively slow, Jira was utterly crippled. Attachments on the other hand - absolutely fine. It may be that our SAN was slow or old or something, but you really do need to load test if you're going to put the index on it.
I'm not sure what you mean by "make attachments available to the client on their request". The attachments are for Jira, and accessed via Jira. All you need to do is make sure that the directory that they live in is available to the Jira service in the right place. I tend to use symbolic links. If you want other systems to see attachments, that's fine as long as it's read-only (you must not delete attachments outside Jira or change the directory tree), and security is not a concern (the external system won't respect Jira permissions)
Not really. You either want the attachments, in which case you need to keep them on a disk Jira can see. Or you don't, so you can delete them.
Thanks for the answer. Also I would like to know if we can implement some LINUX shell script kind of thing to move the attahments periodically based on the criteria - issues across projects in JIRA inactive (i.e., resolved and not updated) since last 365 days.
Is this feasible approach to implement, as I am not sure how to -
Would be great if you can share your thoughts!
It's feasible, but ugly
As you're using linux, there's a far more simple solution - put ALL the attachments on a remote disk and mount it into the file system. That does all the work without losing the links or needing any scripting.
Yes, it will result in error. Your approach is good to tackle this disk space issue and would try to implement the same.
But assuming that the above mentioned approach by me is the only approach.
What if I read the created date of a directory under /data/attachments/<project_key> through the Linux shell script, and rule out communicating with JIRA for the above mentioned criteria part. And then check whether if it was created a year ago. If yes, then move it to the backup sorage with similar file system hierarchy found in production JIRA /data/attachments directory.
Yes, that will work fine.
I'd do a little more checking thogh - don't just look at the creation date individually on an attachment - I'd look at all of them for the issue and work out the created date of the most recent one before deciding to archive all of them.
That's for neatness mostly. Either an issue has attachments or it'll break consistently on all attachments, so you know they're archived. Without that check, I can imagine people seeing "attachments 1 and 2 throw errors on download, but 3 and 4 are fine", which is confusing. You could still get that situation too - if someone attaches a file to an issue that you've archived the attachments for, but I imagine that would be infrequent, especially if you're using "a year" as the rule.
As an aside, I'm not sure why it's "the only approach" - if your server can reach a filesystem for a simple copy, it's very likely that it can reach it to be used as a remote file system and could be used for attachments!
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
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