Zammad Storage Space Running Full

Infos:

  • Used Zammad version: 5.0.x
  • Used Zammad installation type: package
  • Operating system: Microsoft Windows 10
  • Browser + version: Microsoft Edge

Expected behavior:

  • Storage is going to run full

Actual behavior:

  • Is there any setting to export the DB or any Best Practices to prevent this? Or am I only able to increase the storage space?

Steps to reproduce the behavior:

  • //

What kind of database are you running? If you’ve followed Zammad’s advice and you are running PostgreSQL, you can see where the majority of diskspace is being used. It’ll probably be in the article attachments. You could delete old tickets or spam via the Scheduler, check which ones have unusually big attachments and delete those tickets. You’ll also have to reclaim diskspace in PostgreSQL afterwards though.

Please check the PostgreSQL Wiki on Disk Usage for information on how to see which table contains the most data. It’ll likely be a pg_toast relation, containing the attachments.

For comparison, here is a TEST system, containing barely any data:

zammad=# SELECT nspname || '.' || relname AS "relation",
    pg_size_pretty(pg_relation_size(C.oid)) AS "size"
  FROM pg_class C
  LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
  WHERE nspname NOT IN ('pg_catalog', 'information_schema')
  ORDER BY pg_relation_size(C.oid) DESC
  LIMIT 20;
                              relation                              |  size   
--------------------------------------------------------------------+---------
 public.translations                                                | 18 MB
 public.translations_pkey                                           | 3248 kB
 public.index_translations_on_source                                | 1520 kB
 public.index_translations_on_locale                                | 1320 kB
 pg_toast.pg_toast_2618                                             | 480 kB
 public.histories                                                   | 464 kB
 public.users                                                       | 456 kB
 public.index_active_job_locks_on_active_job_id                     | 320 kB
 public.http_logs                                                   | 272 kB
 public.delayed_jobs_pkey                                           | 264 kB
 public.activity_streams                                            | 264 kB
 public.index_active_job_locks_on_lock_key                          | 248 kB
 public.active_job_locks_pkey                                       | 224 kB
 public.delayed_jobs_priority                                       | 216 kB
 public.channels                                                    | 208 kB
 public.ticket_articles                                             | 184 kB
 public.index_activity_streams_on_permission_id_group_id_created_at | 176 kB
 public.settings                                                    | 176 kB
 pg_toast.pg_toast_2619                                             | 160 kB
 public.sessions                                                    | 152 kB
(20 rows)

The following is from one of our PROD systems, with lots of articles, customers and attachments (the pg_toast relation at the top). We’ll probably need to prune this at some point, as the indices are getting a bit large:

zammad=# SELECT nspname || '.' || relname AS "relation",
zammad-#     pg_size_pretty(pg_relation_size(C.oid)) AS "size"
zammad-#   FROM pg_class C
zammad-#   LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
zammad-#   WHERE nspname NOT IN ('pg_catalog', 'information_schema')
zammad-#   ORDER BY pg_relation_size(C.oid) DESC
zammad-#   LIMIT 20;
                               relation                                |  size   
-----------------------------------------------------------------------+---------
 pg_toast.pg_toast_17090                                               | 41 GB
 public.histories                                                      | 1065 MB
 public.ticket_articles                                                | 780 MB
 public.index_histories_on_value_to                                    | 528 MB
 pg_toast.pg_toast_17090_index                                         | 467 MB
 public.index_histories_on_o_id_and_history_object_id_and_related_o_id | 383 MB
 public.index_histories_on_value_from                                  | 316 MB
 public.index_histories_on_history_attribute_id                        | 286 MB
 pg_toast.pg_toast_17695                                               | 284 MB
 public.index_histories_on_id_from                                     | 283 MB
 public.index_histories_on_related_history_object_id                   | 283 MB
 public.index_histories_on_id_to                                       | 282 MB
 public.index_histories_on_history_object_id                           | 281 MB
 public.index_histories_on_related_o_id                                | 278 MB
 public.index_histories_on_o_id                                        | 274 MB
 public.index_histories_on_created_by_id                               | 264 MB
 public.index_histories_on_history_type_id                             | 228 MB
 public.store_provider_dbs                                             | 223 MB
 public.histories_pkey                                                 | 205 MB
 public.index_histories_on_created_at                                  | 205 MB
(20 rows)

You could migrate the attachments from the database to a directory on disk, for instance on a new disk or dedicated mountpoint. This has both advantages and disadvantages compared to storing the attachments in the database. Read this for more information on storage providers