Storage on database did not get remove after files moved to fs


  • Used Zammad version: 4.1
  • Used Zammad installation type: package
  • Operating system: Centos 7.9
  • Browser + version: Edge

Expected behavior:

  • After change the storage from database to Filesystem and run the command:
    rails> Store::File.move('DB', 'File')
    The database should no longer keep the files.

Actual behavior:

  • The disk usage increase 50% after the command

Steps to reproduce the behavior:

1.Go to admin>Settings>System>Storage> Storage Mechanism
2. Select Filesystem as the storage and submit
3. Check the disk usage by command df -h
3. login into server and run command rails> Store::File.move(‘DB’, ‘File’)
4. Files are moved to fs folder successfully.
5. Check the disk usage by command df -h

Depending on the database server you’ve chosen the decreasing of database files happens automatically (or not).

If you’re running postgresql it’s vacuum process should trigger a automatic clean up of the database files after some time. That highly depends on the data sizes we’re talking about here.

MySQL usually does not do this automatically and needs a manual vacuum.
Please note that above is out of our scope - please consult the documentation of your fitting database server.

The attachments itself probably are already removed from the tables. It’s just a matter of clearing the databases used space.

Thank you for your help!
I am using Postgresql. It took additional 20G after move files to file system storage. Is there a way to triiger the clean up process manually?

You can trigger this process, but be extremely careful as this could cause tables to be locked for an extensive amount of time. You should probably do this over the weekend or schedule maintenance downtime for your helpdesk. It might even be best to temporarily stop Zammad altogether during this process.

Please read the PostgreSQL documentation on VACUUM beforehand. And perhaps PostgreSQL VACUUM and ANALYZE Best Practice Tips too.

Do NOT blindly run this command on a production server unless you know what you’re doing.

Danger Zone


Thank you @dvanzuijlekom
I ran the command after stopping Zammad. Here is the output of the command

zammad=> VACUUM FULL VERBOSE ANALYZE store_provider_dbs;
INFO:  vacuuming "public.store_provider_dbs"
INFO:  "store_provider_dbs": found 0 removable, 0 nonremovable row versions in 0                                           pages
DETAIL:  0 dead row versions cannot be removed yet.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  analyzing "public.store_provider_dbs"
INFO:  "store_provider_dbs": scanned 0 of 0 pages, containing 0 live rows and 0                                           dead rows; 0 rows in sample, 0 estimated total rows

It took less than 1 second and I got back 20G.

Awesome, however it does seem that the autovacuum daemon has already done most of the work here, freeing up all the dead rows in the background over time, as there seems to have been no real activity judging from the output, other than actually giving the empty space back to the filesystem. Crisis averted :sweat_smile:

Yes, it is nice to see the disk usage chart, thank you for your help!

1 Like

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.