How do i resolve the ever high disk space utilisation ,by jira. My database and jira application are in the same os. Which directories or files can i archive, or what can i remove without breaking my Jira. Truely i cannot continue increasing disk space, how about if i have limited resource
first of all i think you adressed your question incorrect.
i don't believe you're hosting onDemand installations.
so lets assume you just missed to click the right button for "Downoad" :P
i'd have a look at your <jira_home>/export folder
jira has a backup service that stores xml exports in that directory.
also check your <where ever your DB files are stored> Directory
good idea would be if they're not on the same mount point
like alex & nic said...
<jira_home>/data <- your issues attachments are located here
<jira_home>/logs <- you could archive old logs
<jira_home>/export <- backups live here (delete older ones you feel safe to live without)
/var/lib/mysql (your jira DB is here)
/var/atlassian/application-data/jira (your jira_home is here)
both are on the same mount....could cause your mentioned problem easily if you're unable to increase the diskspace on /var
i'd suggest do use different mounts and at least some LVM to easily extend&resize filesystems. this will give you some time to mess arrounf with cleaning up old or orphaned files
You don't need to - you've said you're "On Demand".
On the assumption that you've used that label/tag in error though, then you need to look at what it's using. The culprits are a combination of
Now, to rule the main ones out
Now the good news
Logs and backups will simply sit there and grow. Potentially very quickly. These are the ones you want to look at and can probably prune. Have a look in your jira-home under "export" and see what's in there. I recently bjorked a test system because I left the daily backups running after importing a copy of the live data - 2Gb backups, running daily on a VM with a 20Gb disk, you can imagine it went bang quickly...
Logs are a bit more iffy, depends on where you've put them. Simple answer is to look in Jira's system info page, that will tell you where they are going.
Are you really having those problems in an OnDemand instance? If you are please contact Atlassian Support.
If you are using your own server, you could think about migrating the database to another server. You could aslo store attachments in a different partition.
Regarding jira files, I would check if you have any old backups files in the backup folder, or you may want to move them to another location (I would actually recommend you to do this in any case to avoid having problems if the disk fails).
Check also your logs. You may want to shrink their size in the log4j configuration file, but please note that in case of failure, your logs will contain information for a shorter period of time.
Thank you guys for your contributions. Firstly i asked the question in correctly, it was supposed to be download not demand. I have found the culprit, and the is none other than the attachment directory. I have to find a way of managing this directory because its ever increasing: Suggestions: There must be a way of archiving these and they must also be accessed remotely, ie from a seperate machine if possible.
Nope, there is no "archiving". (Yet. Atlassian are working on it)
If you want the attachments to remain useable from the issues in Jira, then you HAVE to have them online on a disk that Jira can read. And write, if you want to continue to add them.
However, I'd also add
You can delete attachments. Jira will throw some horrid errors on the issues they are attached to, but it won't actually break completely. It is, however, still safer to delete the issues, as their attachments will go as well.
There is no reason to keep the attachments on the same machine. Jira just needs somewhere local to store the files, but it doesn't have to know that the "local" disk is actually an NFS mount, a NAS, an external USB driver, a storage blade in another datacentre or whatever.
For your remote access, yes, help yourself, read-only. I know a lot of places that have exposed their Jira attachments directory in several ways. Of course, there's no security - anyone who can read the filestore can read any attachment, even if the Jira issues are hidden from them, and there's no write access (because Jira won't know what's changing and you could hence break the attachments completely if you write)
For what it's worth, my solutions have always been a variation on "stick it on a remote disk"
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