nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Disk space issues in the OS where jira is running

Herbert Ncube

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

Accepted answers

Renjith Pillai

https://confluence.atlassian.com/display/JIRAKB/Managing+Attachments+in+JIRA

All comments

Alejandro Conde Carrillo

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.

C.Faysal {CFcon}

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

C.Faysal {CFcon}

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)

i.e.

/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

Nic Brough -Adaptavist-

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

Database size.
Attachments.
Working files.
Backups and exports.
Logs

Now, to rule the main ones out

You can't reduce the size of the database without deleting issues, and even if you do it, it's going to be negligble. We're talking large-scale enterprise sized Jira installs using a few Gb of space.
You can't reduce the size of attachments without deleting the attachments. It is possible to relocate these easily though - dedicated file stores etc.
You can't reduce the size of working files without breaking your application. (Although, I would check if they are cleared properly after stopping the application - there may be some room for clearing them out. Noticably on our installation, some chart.png files seem to lurk on the disks after shutting down. Not huge, so we ignore them, but there may be others in your installation)

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.

C.Faysal {CFcon}

absolutely a good approach if your company isn't forced to keep logs for long time

Naren3

In addition to Nic's answer, you may like to refer this link - https://answers.atlassian.com/questions/119016/can-backups-be-set-to-overwrite. Hope you find it useful.

Renjith Pillai

https://confluence.atlassian.com/display/JIRAKB/Managing+Attachments+in+JIRA

Herbert Ncube

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.

Nic Brough -Adaptavist-

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"