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.
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
VACUUM
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
