Question about safe cleanup of old attachments and disk usage in Zammad

Technical assistance
1

Hello!

We are currently facing significant storage growth issues in our Zammad instance, mainly caused by ticket attachments. Disk usage is increasing rapidly and we are looking for the safest supported way to clean up old data without risking production instability or data corruption.

At the same time, many customer attachments may contain personal or sensitive data, so we would also like to minimize long-term attachment storage for security and compliance reasons.

Our current setup:

Zammad version: 5.2.1
We are currently unable to upgrade to a newer version
Database: MySQL
Attachments are currently stored in the database
We have a large number of old closed tickets (older than 4 years)

Ideally, we would like to:

keep tickets and ticket history/conversations,
but remove old attachments from them in a safe and supported way.

While researching this topic, we found several discussions on the community forum suggesting unsupported approaches such as:

manually deleting files from storage,
replacing attachment contents,
removing attachments directly through Rails console.

However, we understand that attachments in Zammad are connected to:

database metadata,
checksums,
article/ticket references,
search indexes,
and potentially deduplication mechanisms.

Because of this, we are concerned about possible data inconsistency or corruption if attachments are modified manually.

We would like to ask:

What is the officially recommended and safest way to reduce disk usage caused by old ticket attachments?
Is deleting old tickets via Scheduler considered the correct supported approach?
Is there any supported mechanism for removing old attachments while keeping tickets and articles intact?
After deleting large amounts of tickets, what maintenance steps are recommended for MySQL?
Would migrating attachment storage from Database to Filesystem storage be recommended in our case?

Our main goal is to safely reduce storage usage and minimize long-term storage of customer attachments, while avoiding production instability or future upgrade issues.

Thank you in advance!

2

Using DataPrivacy functions or the scheduler to remove tickets is the recommended way to this.

That being said, some of these features may not be available or buggy in your extremely outdated version. Zammad 6.5.5 is the last Zammad version that supports MySQL/MariaDB - you should at least upgrade to that version. In the end that update is also about security for your clients / customers and data.

I cannot recommend to try anything beside of that. Required steps in MySQL scope depend on the configuration of your system. I won’t be able to give you guidelines here.

Not sure about how much “storage” we’re talking about here, but I’ve seen Zammad installations with roughly 3TB of storage requirement. They were running just fine, so extending storage might also be an option.