Deleting Emails does not reduce mailbox size

Hi @all,
yesterday I cleanup my mailbox. I checked the mailbox usage ~ 900MB.
Than I deleted about 3,4 Mails with over 20 MB, and about 200 Mails with 100KB.
After I clicked on the trash bin and “restore items” - and then marked all of the and clicked on “delete permanently”.
After I check my mailbox usage - still ~ 900MB.

After searching the web, I found this kopano-admin --purge-softdelete 1 -v

#kopano-admin --purge-softdelete 1 -v
Softdelete purge done.

But it has no affect.

Can anyone confirm this issue?
Im running a Debian 8 server with kopano-server 8.4.6.0-0+9.1 and webapp 3.4.5.1202+47.1 .
Connected to an openldap server and mariadb 10.2
best regards
Andy

Were the mails in fact older than 1 day (24 hours)? If not, you would probably need to specify 0 instead.

hi @jengelh ,
yes they’ve been deleted for more than 24 hours.
I just rerun the script with no error but also no result - the mailbox usage is still too big.
best regards

no ideas? Still got this problem (-:

hello @AnotherAndy ,

the purge-softdelete trigger is using the “delete time” not the “receive time” if i remember correctly.
if you click on your mailbox in webapp and select “restore itens” there are 2 dates.

the second thing i remember is, that the space which is used by the store in your db is not cleaned up automaticly.

i use a mysqlcheck command every week to clean this:

/usr/bin/mysqlcheck --all-databases --auto-repair --extended --optimize -u <db-user> -p <pw>

it should return (my db is still named zarafa due to migration):

zarafa.abchanges
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.acl
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.changes
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.clientupdatestatus
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.deferredupdate
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.hierarchy
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.indexedproperties
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.lob
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.mvproperties
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.names
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.object
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.objectmvproperty
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.objectproperty
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.objectrelation
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.outgoingqueue
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.properties
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.receivefolder
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.searchresults
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.settings
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.singleinstances
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.stores
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.syncedmessages
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.syncs
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.tproperties
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.users
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
zarafa.versions
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK

this should clean up the physical space

coffee_is_life

@coffee_is_life said in Deleting Emails does not reduce mailbox size:

i use a mysqlcheck command every week to clean this:

depending on your environment this is really bad advice. For once since since this basically dumps you database and reimports it, your kopano system will need to be offline during the whole procedure. And on the other hand free table space in your innodb databases don’t hurt at all. This is concurrent space on your disks that mysql can freely manage to arrange data and speedup your queries.

The only upside I see in this is if you are running innodb_file_per_table and regularly cut your company size in half and in that process want to get rid of old data.

hello @fbartels,

thanks for this info, we are using this command since old zarafa and mostly needed after the purge-softdelete trigger was bugged after migration. needed to execute this script external and deleted over 1,9 mio elements,
reduced the db from 145 GB to 88 GB :)

indeed im using “innodb_file_per_table=1” in my “/etc/my.cnf.d/kopano.cnf”

should i reduce the usage of this mysqlcheck-command to monthly or just stop using it?
since now its working fine and does its job.

coffee_is_life

@coffee_is_life said in Deleting Emails does not reduce mailbox size:

just stop using it

this.

For the above use case (massively reducing disk usage) it is okay, but in normal day to day usage this will not bring you any advantage.