Disk space usage on otrs

[srto]

Hi,

I am trying to minimize the amount of disk space used by otrs especially by the articles. I store the articles in the FileSystem and I am noticing that approximately 50% of the space is used up by a file called plain.txt which I believe stores the plain text version of the e-mail sent by customer including the attachments.

I've removed the plain.txt from selected tickets and these tickets seem to have been unaffected. These tickets were also returned when I searched for words in their body.

Do you think that it's safe to remove the plain.txt from each ticket?

Thanks,
rsto

[CSL]

I've been trying to find out about this myself. I still use DB storage for articles, and the article_plain table accounts for ~60% of the size of our DB.

OTRS support have told me that they do not recommend removing its contents as it could affect the proper running of the system. This is fair enough, though I think that it's only used to display the 'plain' version of the email when an agent clicks 'Plain Format' in the ticket zoom view.

Can you still download attachments from articles in the ticket after you remove the plain.txt file?

I'm inclined to go along with the official word on this and not remove it. It's there as part of the system, and removing bits of the system to see if breaks isn't good practice. If your install is getting too big, I think it's probably better to look into dumping out older content instead. This could be done by backing up your install, archiving the backup, and then using the generic agent to delete all tickets that have been closed for more than two years, for example.

[crythias]

DB storage for articles, and the article_plain table accounts for ~60% of the size of our DB.

That's where the attachment is stored.

I've removed the plain.txt from selected tickets and these tickets seem to have been unaffected. These tickets were also returned when I searched for words in their body.

Do you think that it's safe to remove the plain.txt from each ticket?

If you promise you never want to go back to db storage ... maybe. I'm talking off the cuff here, but if I understand the importance, it is in case you wish to bring the filesystem storage back to DB.

I haven't verified it to be true, but (to me) it sounds reasonable enough to be the case. This idea is somewhat bolstered by the fact that the attachment exists as a file in the filesystem, right?